Clés SSH (clés cryptographiques SSH)

1. Vue d’ensemble du concept et problème systémique

L’authentification traditionnelle par login et mot de passe sur les serveurs distants présente des failles architecturales critiques : vulnérabilité aux attaques par force brute, interception en cas de compromission du canal (man-in-the-middle) et facteur humain (utilisation de mots de passe faibles ou réutilisés). Dès que le port 22 est exposé à l’internet public, les botnets génèrent des milliers de tentatives de connexion chaque minute.

Les SSH Keys résolvent ce problème grâce à la cryptographie asymétrique. L’utilisateur génère une paire de clés mathématiquement liées :

• Clé privée (Private Key) : Conservée exclusivement sur la machine locale du développeur sous forme chiffrée par une passphrase, elle n’est jamais transmise via le réseau.
• Clé publique (Public Key) : Déployée sur le serveur cible dans le fichier ~/.ssh/authorized_keys.

Lors de la poignée de main (handshake), le serveur génère un challenge aléatoire, le chiffre ou demande une signature au client via la clé privée. L’authentification s’effectue par preuve mathématique de possession de la clé privée, sans jamais révéler le secret lui-même.

+------------------+                    +--------------------+
|  Client local    |                    |  Serveur distant   |
|  (~/.ssh/id_ed)  |                    |  (~/.ssh/auth_keys)|
+--------+---------+                    +---------+----------+
         |                                        |
         |  1. Demande de connexion (User, PubKey)|
         |--------------------------------------->|
         |                                        | 2. Vérification de la présence
         |                                        |    de la clé publique
         |  3. Défi cryptographique (Nonce)       |
         |<---------------------------------------|
         |                                        |
         | 4. Signature du nonce avec la clé      |
         |    privée                              |
         |--------------------------------------->|
         |                                        | 5. Validation de la signature
         |                                        |    avec la clé publique
         |  6. Session ouverte (Authentifiée)     |
         |<---------------------------------------|

2. Taxonomie architecturale et modèle mental

Les algorithmes cryptographiques pour SSH ont évolué parallèlement à la puissance de calcul et aux progrès du cryptanalyse :

1. Ed25519 (Edwards-curve Digital Signature Algorithm) :
   • Le standard de facto actuel de l’industrie.
   • Basé sur la courbe elliptique Curve25519.
   • Longueur de clé : 256 bits.
   • Haute résistance aux attaques side-channel et timing, avec une exécution extrêmement rapide.
2. ECDSA (Elliptic Curve Digital Signature Algorithm) :
   • Utilise les courbes standardisées NIST (par exemple, nistp256 ou nistp521).
   • Présente des risques potentiels de backdoors liés au choix des paramètres par le générateur NIST et une sensibilité critique à la qualité du générateur de nombres aléatoires (RNG) : la répétition de la valeur aléatoire k expose entièrement la clé privée.
3. RSA (Rivest-Shamir-Adleman) :
   • Algorithme classique basé sur la factorisation de grands nombres premiers.
   • Les clés de moins de 2048 bits sont considérées comme compromises. Le minimum sécurisé est de 4096 bits.
   • Clés publiques et privées volumineuses, génération et signature plus lentes.
4. FIDO2 / Hardware Security Keys (ed25519-sk / ecdsa-sk) :
   • Authentification matérielle via des tokens physiques (YubiKey).
   • La clé privée est générée et ne quitte jamais la puce sécurisée du token ; chaque session SSH nécessite une interaction physique.

3. Pipeline technique et mécanique interne

Génération et déploiement d’une clé sécurisée

Génération d’une clé Ed25519 de production avec un nombre accru de rounds de dérivation de clé (KDF) pour protéger contre le cracking GPU de la passphrase :

# Генерація Ed25519 з коментарем та 100 раундами KDF
ssh-keygen -t ed25519 -a 100 -C "admin@production-cluster" -f ~/.ssh/id_ed25519_prod

Copie de la clé publique vers le serveur distant :

ssh-copy-id -i ~/.ssh/id_ed25519_prod.pub deploy@vps.internal.net

Structure des permissions du système de fichiers Linux

Des permissions incorrectes sont la cause de 90 % des échecs d’authentification SSH (Permission denied (publickey)) :

# Локальна машина клієнта:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519_prod
chmod 644 ~/.ssh/id_ed25519_prod.pub
chmod 600 ~/.ssh/config

# Віддалений сервер:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

Configuration du client (~/.ssh/config)

Pour éviter de passer de longs flags en ligne de commande, on utilise une configuration client déclarative :

Host prod-node-01
    HostName 198.51.100.24
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_prod
    IdentitiesOnly yes
    ServerAliveInterval 60
    ServerAliveCountMax 3

Host bastion-jumphost
    HostName 203.0.113.10
    User gatekeeper
    IdentityFile ~/.ssh/id_ed25519_bastion

Host internal-db
    HostName 10.0.4.15
    User postgres
    ProxyJump bastion-jumphost
    IdentityFile ~/.ssh/id_ed25519_db

4. Scénarios d’ingénierie pratiques en production

01. Accès sans mot de passe pour les pipelines CI/CD automatisés

Dans les environnements GitHub Actions ou GitLab CI/CD, le déploiement s’effectue automatiquement via une clé SSH technique dédiée. La clé privée est stockée dans les Secrets chiffrés du dépôt, tandis que la clé publique sur le serveur est liée à un shell restreint ou à une commande spécifique via la directive command="..." dans authorized_keys :

command="/usr/local/bin/deploy-webhook.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-ed25519 AAAAC3NzaC1lZDI1NTE5... ci-deploy-key

Même si le secret CI/CD est compromis, l’attaquant ne pourra exécuter que le script de déploiement déterministe, et non des commandes arbitraires dans le terminal.

02. Accès aux nœuds d’infrastructure isolés via Bastion (ProxyJump)

Dans un VPC, les bases de données privées ou les serveurs d’agents AI n’ont pas d’IP publiques. L’ingénieur se connecte via un hôte Bastion intermédiaire sans avoir besoin d’exporter sa clé privée sur le Bastion :

ssh -J gatekeeper@bastion.example.com deploy@10.0.1.50

SSH tunnelise le trafic TCP au niveau socket via le nœud proxy, en chiffrant la session avec la clé finale du serveur cible (ProxyJump ne révèle pas le contenu du trafic au bastion).

03. Clés matérielles FIDO2 pour une infrastructure Zero Trust

Dans les systèmes fintech à forte charge ou régulés, les développeurs sont tenus d’utiliser des tokens matériels YubiKey. Une clé de type ed25519-sk est créée. Chaque action git push ou session SSH nécessite une pression physique sur le capteur du token. Cela neutralise totalement la menace de vol de clés privées par des infostealers ou des logiciels malveillants sur le laptop du développeur.

5. Pièges, erreurs courantes et sécurité

1. Génération de clés sans Passphrase : Stocker une clé privée sans mot de passe robuste crée une menace critique : tout processus malveillant, script ou accès physique à un laptop déverrouillé permet de copier instantanément la clé privée et d’accéder à toute l’infrastructure. Protégez toujours vos clés avec un mot de passe et utilisez ssh-agent.
2. Sprawl incontrôlé dans authorized_keys : Avec le temps, des dizaines de clés d’anciens développeurs ou de contractuels temporaires s’accumulent dans le fichier. L’absence d’audit régulier ouvre des backdoors. Utilisez une gestion centralisée des clés via Ansible, Teleport, HashiCorp Vault ou une Autorité de Certification SSH (CA).
3. Utilisation du SSH Agent Forwarding (-A) : Activer ForwardAgent yes dans la configuration globale permet aux machines distantes d’accéder à votre socket local ssh-agent. Ne jamais activer l’Agent Forwarding globalement ; préférez ProxyJump ou ssh-agent -c pour confirmer chaque utilisation de la clé.