Authentification par clé publique et transfert d’agent

L’authentification SSH par clé publique repose sur le fichier authorized_keys, généralement situé à ~/.ssh/authorized_keys sur le serveur. Chaque ligne contient une clé publique au format : algorithm base64-key comment. Le serveur vérifie que le client peut prouver qu’il possède la clé privée correspondante en signant un défi.

La commande ssh-keygen crée des paires de clés pour l’authentification. L’exécution de ssh-keygen -t ed25519 génère une paire de clés Ed25519 moderne. Vous pouvez indiquer un commentaire avec -C pour l’identifier, par exemple votre adresse électronique. Par défaut, l’outil enregistre la clé privée (id_ed25519) et la clé publique (id_ed25519.pub) dans ~/.ssh.

Les clés RSA de 4096 bits sont très compatibles avec les systèmes anciens, mais leur signature est plus lente. ECDSA sur NIST P-256 est plus rapide et produit des signatures plus petites, mais certains cryptographes s’interrogent sur la sélection des paramètres des courbes NIST. Ed25519, fondé sur Curve25519, constitue la meilleure pratique actuelle : clés et signatures rapides et compactes, aucune faiblesse connue et disponibilité dans toutes les implémentations SSH modernes.

Le fichier de clé privée doit être protégé par une phrase secrète. ssh-keygen chiffre la clé privée à l’aide d’une clé dérivée de la phrase secrète (bcrypt pour les clés modernes), de sorte qu’un attaquant qui dérobe le fichier ne puisse pas l’utiliser sans cette phrase secrète. Sans phrase secrète, toute personne ayant accès au fichier peut s’authentifier en votre nom auprès de tout serveur détenant la clé publique correspondante.

Le démon ssh-agent conserve les clés privées déchiffrées en mémoire pendant une session de connexion. Vous chargez une clé avec ssh-add ~/.ssh/id_ed25519, qui vous invite à saisir la phrase secrète une seule fois. Lors des connexions SSH suivantes, le client demande à l’agent de signer les défis sans ressaisir la phrase secrète, conciliant sécurité et commodité.

Lorsqu’un serveur SSH envoie un défi d’authentification, le client SSH délègue la signature à ssh-agent par l’intermédiaire d’un socket Unix. L’agent effectue la signature cryptographique à l’aide de la clé privée conservée en mémoire et ne renvoie que la signature. Les octets de la clé privée ne quittent jamais le processus de l’agent, pas même pour parvenir au client SSH lui-même.

Le transfert de l’agent (ForwardAgent yes ou ssh -A) permet à une session SSH distante d’utiliser votre agent local pour s’authentifier auprès d’autres serveurs. Cette fonction est utile pour passer par des hôtes bastion sans copier les clés privées sur le bastion. Cependant, si le bastion est compromis, un utilisateur root qui s’y trouve peut accéder au socket de votre agent et s’authentifier en votre nom auprès de n’importe quel serveur.

ProxyJump (ssh -J bastion target) est une alternative plus sûre à ForwardAgent pour accéder à un hôte bastion. Il crée un tunnel TCP à travers le bastion sans y exposer le socket de votre agent. Le serveur cible reçoit une connexion directe de votre client local, tandis que le bastion ne fait que transmettre des octets TCP chiffrés, sans pouvoir utiliser vos informations d’authentification.

SSH prend en charge l’authentification par certificat, dans laquelle une autorité de certification (CA) signe les clés publiques d’hôtes et d’utilisateurs. Au lieu de distribuer des clés publiques individuelles à chaque serveur, vous configurez les serveurs pour qu’ils approuvent votre CA. Un certificat utilisateur signé accorde l’accès à tous les serveurs qui approuvent cette CA, avec une date d’expiration et des restrictions d’identité facultatives intégrées au certificat.

L’outil ssh-keyscan se connecte à un ou plusieurs hôtes et récupère leurs clés publiques d’hôte sans authentification. Il est utile pour automatiser le remplissage des fichiers known_hosts dans des scripts de déploiement. La sortie peut être redirigée directement vers un fichier known_hosts : ssh-keyscan -H example.com >> ~/.ssh/known_hosts.

Authentification par clé publique : le client envoie la clé publique, le serveur vérifie authorized_keys, le serveur envoie un défi signé avec l’ID de session, le client (par l’intermédiaire de l’agent) le signe avec la clé privée et le serveur vérifie la signature à l’aide de la clé publique enregistrée. Si elle est valide, l’authentification réussit sans transmettre aucun secret d’authentification.

À retenir : stocker les clés publiques dans authorized_keys, protéger les clés privées avec des phrases secrètes, utiliser ssh-agent pour conserver les clés déchiffrées en mémoire, privilégier le type de clé Ed25519, utiliser ProxyJump plutôt que ForwardAgent pour accéder aux bastions afin d’éviter d’exposer le socket de l’agent et envisager les certificats SSH pour une gestion des accès à grande échelle.