Linux / Commande ssh-copy-id : ajouter une clé publique et vérifier l’accès

ssh-copy-id ajoute une clé publique locale à la liste des clés autorisées d’un compte distant, normalement ~/.ssh/authorized_keys. Il prépare l’authentification SSH par clé sans copier votre clé privée sur le serveur. Vous devez déjà disposer d’un moyen autorisé de connexion au compte et vérifier l’identité du serveur avant l’ajout.

Identifier le compte et la clé publique à enregistrer

SSH signifie Secure Shell. L’outil utilise SSH pour vérifier des clés déjà acceptées, puis ajouter celles qui restent. Une connexion par mot de passe est fréquente pour le premier enregistrement, mais un autre moyen d’authentification autorisé peut convenir ; il n’est pas nécessaire d’activer arbitrairement les mots de passe sur le serveur.

Préparez un compte distant précis, l’adresse et le port, le fichier public voulu et la clé privée correspondante. La création de clés avec ssh-keygen et la lecture de leur empreinte explique la différence entre les deux fichiers.

ssh-keygen -lf ~/.ssh/id_ed25519_work.pub

Comparez l’empreinte de la clé à enregistrer avec celle attendue. .pub est une convention de nom ; confirmez qu’il s’agit réellement de la partie publique. Le commentaire aide au classement, mais ne prouve pas que le bon compte ou la bonne clé ont été choisis.

ssh-copy-id [OPTIONS] [UTILISATEUR@]HOTE

Vérifiez man ssh-copy-id et son aide locale. Les options dépendent du script fourni par la distribution. Sans -i explicite, certaines implémentations choisissent les clés d’un agent ou un fichier public par défaut : ne supposez pas qu’une clé particulière sera la seule ajoutée.

Prévisualiser puis ajouter la clé choisie

Les exemples supposent que la clé existe, qu’alice est le compte autorisé et que le serveur est remplacé par votre destination réelle. La forme -n est une prévisualisation lorsqu’elle est prise en charge :

ssh-copy-id -n -i ~/.ssh/id_ed25519_work.pub alice@server.example.com

Elle affiche les clés qui seraient installées au lieu de les ajouter au fichier distant. Ce n’est pas nécessairement une opération sans connexion : la vérification des clés peut tenter des accès SSH. Des journaux, des demandes de phrase secrète et les règles de confiance locales de SSH restent donc pertinents.

Vérifiez le compte, l’hôte, l’empreinte et les clés proposées. Une demande de validation de clé d’hôte doit être comparée à une empreinte obtenue par un canal fiable, comme pour une première connexion SSH. N’ignorez pas une alerte de clé d’hôte modifiée.

Une fois le plan correct, l’ajout se fait avec :

ssh-copy-id -i ~/.ssh/id_ed25519_work.pub alice@server.example.com

Le script vérifie normalement quelles clés sont déjà acceptées et ajoute les autres. Il peut créer le répertoire et le fichier d’autorisation nécessaires. La clé privée peut être utilisée localement pour un essai d’authentification, mais son contenu n’est pas la donnée à installer sur le serveur.

Une sortie possible après l’ajout d’une seule clé est :

Number of key(s) added: 1

Ce nombre est un exemple, pas un résultat garanti. Un message indiquant que les clés sont déjà présentes peut aussi correspondre à un compte qui les accepte déjà. Lire le message ne remplace pas une vérification indépendante du nouvel accès.

Tester réellement l’authentification par la clé

Conservez votre accès administratif existant et ouvrez un autre terminal pour vérifier l’identité locale voulue :

ssh -i ~/.ssh/id_ed25519_work alice@server.example.com

Si vous devez confirmer que la réussite ne provient pas d’un repli sur le mot de passe ou d’une connexion partagée existante, examinez une nouvelle tentative détaillée :

ssh -v -o IdentitiesOnly=yes -o PreferredAuthentications=publickey -o ControlPath=none -i ~/.ssh/id_ed25519_work alice@server.example.com

La méthode demandée est publickey, la connexion partagée n’est pas réutilisée avec ce chemin de contrôle désactivé, et IdentitiesOnly limite les identités offertes aux identités configurées. Si votre configuration ajoute d’autres fichiers d’identité, vérifiez dans les traces l’empreinte effectivement acceptée ; -i seul n’est pas une preuve que cette clé précise a servi.

Une demande de phrase secrète pour votre fichier privé est différente du mot de passe du compte distant. Un agent ayant déjà déverrouillé la clé peut éviter cette demande sans que l’authentification soit devenue une connexion par mot de passe. Relisez les traces avant de les partager, car elles peuvent contenir comptes, hôtes et chemins.

Reprenez le même port et les mêmes conditions de saut si votre serveur n’utilise pas l’accès par défaut. Vérifiez ensuite le compte et les droits obtenus ; un accès restreint ou une commande imposée peut être une politique intentionnelle. Le succès de cet essai ne suffit pas à décider de désactiver les autres méthodes d’accès.

Comprendre les variantes, les échecs et le retrait d’une clé

Le mode habituel exécute des commandes distantes. Avec -s, le script peut télécharger authorized_keys, le modifier localement et le renvoyer par SFTP, SSH File Transfer Protocol. Il faut les droits et le chemin correspondants ; ce mode n’accorde pas une permission que le compte n’a pas.

Un serveur peut consulter un fichier d’autorisation différent ou une source gérée centralement. Dans ce cas, l’emplacement par défaut de ssh-copy-id n’est pas nécessairement la bonne méthode de provisionnement. Confirmez la politique du serveur avant de choisir un autre chemin ou de modifier ses réglages.

Si la clé reste refusée, vérifiez le compte, le port, l’empreinte proposée, le fichier d’autorisation réellement utilisé, ses propriétaires et permissions, puis les journaux du serveur accessibles à l’administrateur. -f ne corrige pas une clé interdite ou un fichier illisible.

Pour retirer une clé ajoutée par erreur, préservez d’abord le fichier d’autorisation et identifiez la ligne exacte par sa clé ou son empreinte. Retirez seulement cette autorisation, en conservant les autres clés et leurs restrictions, puis vérifiez les accès qui doivent rester. Supprimer toute la liste n’est pas un retour arrière approprié.

Le manuel officiel ssh-copy-id précise la sélection des identités, la prévisualisation et le mode SFTP. Les règles du client sont décrites dans le manuel de configuration OpenSSH.