Vous avez une clé SSH prête, mais le serveur demande encore un mot de passe. ssh-copy-id ajoute votre clé publique dans le compte distant, à condition de viser le bon hôte et le bon utilisateur. C’est pratique, mais une commande lancée sur le mauvais alias peut déposer une clé sur une machine que vous ne vouliez pas modifier.
Vérifier la clé, le compte et l’hôte
La commande ne copie jamais votre clé privée. Elle envoie le contenu du fichier .pub, souvent ~/.ssh/id_ed25519.pub, dans ~/.ssh/authorized_keys du compte distant. Commencez par voir les clés publiques disponibles :
ls -l ~/.ssh/*.pub
ssh-keygen -lf ~/.ssh/id_ed25519.pubLa seconde commande affiche l’empreinte de la clé. Elle vous aide à confirmer le fichier que vous allez installer. Si vous n’avez pas encore de paire de clés, créez-la avant de continuer avec notre guide pour générer une clé SSH sur Ubuntu.
Ensuite, contrôlez la destination. Un alias défini dans ~/.ssh/config peut cacher un port, une passerelle ou un utilisateur. Cette commande montre ce que le client SSH utilisera réellement :
ssh -G [email protected] | grep -E '^(hostname|user|port|identityfile) 'Remplacez admin et serveur.exemple.net par votre compte et votre machine. Comparez l’adresse obtenue avec votre inventaire, votre console d’hébergement ou la documentation du service. Pour une machine déjà connue, une empreinte hôte inattendue dans known_hosts mérite une vérification, pas une suppression automatique du fichier.
Copier une clé publique avec ssh-copy-id
Quand l’hôte et le compte sont validés, indiquez explicitement la clé à installer. Le serveur demandera le mot de passe du compte distant une dernière fois, ou utilisera une méthode déjà autorisée.
ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]L’option -i évite de laisser l’outil choisir une autre clé publique. Si le serveur SSH écoute sur un port différent, ajoutez -p avec le numéro exact :
ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 2222 [email protected]Le compte distant doit pouvoir se connecter et écrire dans son dossier personnel. Si vous utilisez root, posez-vous d’abord la question du compte d’administration prévu par votre distribution. Installer une clé dans le mauvais authorized_keys ne donne pas un accès au bon utilisateur et complique le diagnostic.
Tester sans couper votre accès actuel
Ouvrez un second terminal. Ne fermez pas la connexion qui fonctionne tant que l’authentification par clé n’est pas confirmée. Forcez la clé attendue et désactivez le mot de passe pour obtenir un résultat net :
ssh -i ~/.ssh/id_ed25519 -o PasswordAuthentication=no [email protected]Si la connexion échoue, relancez avec -v. Cherchez la clé proposée, la ligne Offering public key et le refus éventuel. Côté serveur, l’administrateur peut lire journalctl -u ssh -b sur Debian et Ubuntu, ou journalctl -u sshd -b sur plusieurs distributions RPM.
Vérifiez aussi les permissions sur le serveur. OpenSSH refuse souvent une configuration trop ouverte :
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keysExécutez ces commandes avec le compte concerné. Un chmod lancé en root dans le mauvais répertoire ne réparera pas le compte de connexion.
Quand ssh-copy-id est absent
Sur une machine minimale, l’outil peut manquer. Vous pouvez installer le paquet OpenSSH client de votre distribution, puis reprendre la méthode ci-dessus. Évitez de coller une clé à la main si vous ne savez pas quel compte est ouvert : la commande suivante est un plan B, pas une invite à contourner les contrôles.
cat ~/.ssh/id_ed25519.pub | ssh [email protected] 'umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys'Ce plan B ajoute la clé sans supprimer les entrées existantes. Il reste toutefois moins lisible qu’ssh-copy-id. Si votre clé est protégée par une passphrase, ssh-agent peut la conserver temporairement en mémoire, au lieu de vous la redemander à chaque connexion.
Une fois le test validé, notez l’empreinte de la clé, le compte et le serveur dans votre documentation. Vous saurez alors quelle clé retirer si un poste est remplacé ou compromis.
