SSH : comment gérez-vous les clés, l’agent, et ce qu’on ne fait jamais ?

Le modèle, en une phrase

Vous prouvez que vous détenez une clé privée. Le serveur compare la signature à une ligne de authorized_keys du compte visé. Le mot de passe du compte n’entre pas en jeu si PasswordAuthentication est off — et c’est le cas visé en production.

Ce qu’on fait

Une paire par personne ou par automate, pas une clé d’équipe dans un wiki. Ed25519 aujourd’hui, passphrase sur la privée. Côté serveur : ~/.ssh en 700, authorized_keys en 600, propriétaire du compte. SSH refuse ces fichiers trop ouverts : un chmod 777 « pour déboguer » casse la connexion, ce n’est pas un détail.

L’agent (ssh-agent, ou l’agent du gestionnaire d’OS) charge la privée en mémoire sur le poste. ssh-add -l liste. ForwardAgent n’est pas un confort anodin : il permet à un serveur compromis d’utiliser votre agent comme s’il était vous, vers d’autres machines. On l’ouvre seulement vers des hops de confiance, ou on préfère ProxyJump.

Les clés de déploiement vont dans un secret manager ou un runner, avec le droit le plus étroit (command=, from= dans authorized_keys si c’est un compte de job). On ne met pas la privée sur le serveur cible « pour que le serveur puisse SSH ailleurs » sans savoir que cette machine devient alors un point d’exfiltration.

Ce qu’on ne fait jamais

• Commiter une clé privée, la coller dans un ticket, la partager sur Slack.
• PermitRootLogin yes avec mot de passe, ou root + la même clé pour tout le monde.
• Désactiver StrictHostKeyChecking dans un script « pour que ça passe » : vous acceptez un MITM.
• Copier id_rsa sur un bastion et s’y connecter à vingt. Le bastion devient le trousseau.
• Croire que chmod 644 sur une privée est « plus pratique ». ssh refusera, à raison.

La relance

« Comment révoquez-vous l’accès d’une personne ? »

Retirer sa ligne dans authorized_keys (ou la clé dans le IdP / le certificat SSH si vous êtes à ce niveau), pas changer le mot de passe d’un compte partagé qui n’aurait jamais dû exister. Si tout le monde a la même clé, vous ne révoquez personne.

« Password ou clé ? »

Clé (ou certificat). Le mot de passe se brute-force et se rejoue ; la privée avec passphrase et agent ne voyage pas à chaque connexion. Mentionner fail2ban / restriction AllowUsers est un plus, ce n’est pas le cœur : le cœur est identité = clé, surface = authorized_keys, privée nulle part ailleurs.