Comment utiliser les mêmes clés SSH sur plusieurs ordinateurs

Deux façons de faire

Chaque appareil qui se connecte avec une clé doit avoir une clé privée. Vous pouvez donner à chaque appareil sa propre clé, ou copier la même clé sur tous.

Une clé par appareil est le choix le plus sûr par défaut, et celui de la plupart des équipes. La copie a du sens pour quelques appareils que vous maîtrisez entièrement, quand ajouter des clés sur de nombreux serveurs est la vraie corvée.

Créer une clé sur le nouvel appareil

Sur le nouvel ordinateur, créez une clé avec un commentaire qui nomme l'appareil :

ssh-keygen -t ed25519 -C "me@desktop"

Acceptez le fichier par défaut, ~/.ssh/id_ed25519, et choisissez une phrase de passe. Le commentaire apparaît à côté de la clé dans authorized_keys et dans les listes d'empreintes : c'est lui qui permet de supprimer la bonne ligne plus tard. Le guide pour générer une clé SSH Ed25519 détaille les options.

L'ajouter à vos serveurs

Si le serveur accepte encore un mot de passe, lancez ceci depuis le nouvel appareil :

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@server

Si la connexion par mot de passe est désactivée, ce qui est préférable, passez par un appareil qui se connecte déjà. Apportez-lui le nouveau fichier .pub (il est public, un e-mail ou un message suffit), puis ajoutez-le :

ssh deploy@server "cat >> ~/.ssh/authorized_keys" < desktop.pub

Vérifiez que les deux clés sont présentes, chacune avec son commentaire :

ssh deploy@server "ssh-keygen -lf ~/.ssh/authorized_keys"

256 SHA256:l1AS4F9VRH90JA6uJuQw7/3uRDzrtMafpkeiO7zel84 me@laptop (ED25519)
256 SHA256:LGklWc72FhPwm7in/sLr3pGRujcSZ6a6z4E97qJGkRE me@desktop (ED25519)

Recommencez pour chaque serveur, et ajoutez la clé dans les clés SSH de votre compte GitHub ou GitLab si vous poussez du code depuis cet appareil. Avec beaucoup de serveurs, une petite boucle sur votre liste d'hôtes fait gagner du temps. Le format du fichier est décrit dans le fichier authorized_keys expliqué.

Si vous copiez la clé

Copiez les deux fichiers, id_ed25519 et id_ed25519.pub, par un canal chiffré de bout en bout : une clé USB chiffrée, AirDrop, ou scp entre deux machines qui vous appartiennent. Évitez l'e-mail, les messageries et les dossiers partagés, qui gardent des copies. Ensuite, sur le nouvel appareil :

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

Sans ces permissions, ssh refuse la clé. Si elle n'a pas de phrase de passe, ajoutez-en une maintenant, puisqu'elle se trouve désormais à plusieurs endroits :

ssh-keygen -p -f ~/.ssh/id_ed25519

Pour vérifier que la clé privée et la clé publique vont ensemble, affichez la partie publique à partir de la clé privée et comparez :

ssh-keygen -y -f ~/.ssh/id_ed25519
cat ~/.ssh/id_ed25519.pub

Les deux lignes doivent commencer par la même clé. Plus de détails dans retrouver la clé publique à partir de la clé privée.

Quand un appareil est perdu ou remplacé

Avec une clé par appareil, supprimez la ligne de cet appareil sur chaque serveur. Sauvegardez le fichier, supprimez par commentaire et listez ce qui reste :

sed -i.bak '/ me@desktop$/d' ~/.ssh/authorized_keys
ssh-keygen -lf ~/.ssh/authorized_keys

N'importe qui ayant eu accès peut modifier un commentaire : pour un appareil volé, cherchez plutôt par empreinte, comme expliqué dans révoquer une clé SSH. Retirez aussi la clé de GitHub et des services similaires.

Avec une clé copiée, l'appareil perdu détient la même clé que tous les autres. Créez une nouvelle clé, installez-la partout, retirez l'ancienne clé publique de chaque serveur et service, et copiez la nouvelle clé privée sur les appareils qui vous restent. Tant que ce n'est pas fait, seule la phrase de passe protège l'ancienne.

Garder la même configuration partout

Les clés privées diffèrent selon l'appareil, mais ~/.ssh/config peut être identique, à condition que chaque appareil nomme sa clé de la même façon :

Host *
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host prod
    HostName 203.0.113.10
    User deploy

La configuration ne contient aucun secret : elle peut vivre dans un dépôt de dotfiles ou un dossier synchronisé. Gardez-en à l'écart les fichiers id_* sans .pub. Voir des exemples de fichier ssh config pour les motifs d'hôtes, et un gestionnaire de clés SSH avec coffre chiffré si vous préférez garder clés et serveurs au même endroit.

Questions

Peut-on copier sa clé privée SSH sur un autre ordinateur ?

Oui, cela fonctionne, et OpenSSH ne se soucie pas de l'endroit où la clé a été créée. Le prix se paie plus tard : si une copie fuit ou qu'un appareil est perdu, il faut remplacer la clé sur chaque serveur et sur chaque appareil qui la détient.

Peut-on mettre son dossier .ssh dans Dropbox, iCloud ou un dépôt de dotfiles ?

Gardez-y la configuration et les clés publiques si vous voulez, jamais les clés privées. Un dossier synchronisé ou l'historique Git conservent des copies que vous ne pouvez pas effacer complètement.

Combien de clés authorized_keys peut-il contenir ?

Il n'y a pas de limite pratique. Chaque ligne est une clé, et un commentaire comme me@laptop à la fin permet de les distinguer.

Sources

• ssh-keygen(1), manuel OpenBSD
• sshd(8), AUTHORIZED_KEYS FILE FORMAT
• ssh-copy-id(1), Debian 13
• Adding a new SSH key to your GitHub account, GitHub Docs

Guides associés

• Comment générer une clé SSH ed25519
• Le fichier authorized_keys expliqué
• Comment retrouver une clé publique SSH à partir de la clé privée
• Comment révoquer une clé SSH quand quelqu'un quitte l'équipe
• Le fichier de configuration SSH, avec des exemples

Autres guides : Clés et connexion

• Convertir une clé .ppk en OpenSSH, et inversement
• Comment désactiver la connexion par mot de passe pour SSH
• Comment utiliser une YubiKey ou une clé FIDO2 avec SSH (ed25519-sk)
• Comment ajouter une clé SSH à GitHub
• Comment corriger "Permission denied (publickey)" avec SSH
• Clés SSH RSA ou ed25519 : laquelle choisir ?

Tous les guides