SSH Copy ID Linux : copier ta clé SSH sur un serveur sans mot de passe, proprement

La réponse rapide

Pour copier ta clé publique sur un serveur Linux, la commande la plus simple est généralement ssh-copy-id utilisateur@serveur. Elle ajoute automatiquement ta clé dans ~/.ssh/authorized_keys du compte distant, avec les bonnes permissions. Ensuite, tu peux tester une connexion sans mot de passe, puis durcir SSH côté serveur.

Si tu industrialises ce type d’accès sur plusieurs machines, tu peux aussi t’appuyer sur une prestation d’infogérance serveurs Linux pour entreprise ou sur des services de configuration serveurs pour cadrer la partie durcissement, sauvegarde et supervision.

Pourquoi utiliser ssh-copy-id sur Linux

Beaucoup d’admins débutent avec une connexion SSH au mot de passe, puis bricolent manuellement un fichier authorized_keys. Ça fonctionne parfois, mais c’est aussi la meilleure façon de perdre du temps sur des droits cassés, des clés mal copiées ou des connexions qui refusent de s’ouvrir au mauvais moment.

ssh-copy-id existe précisément pour éviter ça. L’outil pousse ta clé publique vers le bon utilisateur distant, crée le répertoire .ssh si nécessaire, puis applique un cadre cohérent. Pour un serveur Linux exposé sur Internet, cette étape change tout : tu passes d’un accès fragile à une base exploitable pour un vrai hardening.

Dans la vraie vie, cette commande sert surtout dans trois cas : préparer un nouveau VPS, standardiser les accès d’admin sur plusieurs machines, ou remettre de l’ordre après une mise en prod faite un peu trop vite. Ce n’est pas spectaculaire, mais c’est typiquement le genre d’étape qui évite un incident bête à 22h.

Prérequis avant de lancer ssh-copy-id

Avant d’exécuter la commande, vérifie trois points. D’abord, tu dois déjà disposer d’une paire de clés SSH valide sur ta machine locale. Ensuite, le compte distant doit être accessible une première fois, souvent au mot de passe ou via la console du fournisseur. Enfin, tu dois savoir quel utilisateur recevra la clé : root pour une phase initiale très courte, ou mieux, un compte admin dédié avec sudo.

La commande de base pour copier une clé SSH sur un serveur Linux

Dans la majorité des cas, la commande suffit à elle seule :

ssh-copy-id admin@mon-serveur.example.com

Si tu veux cibler une clé précise, par exemple une clé dédiée à l’administration d’infra, utilise l’option -i :

ssh-copy-id -i ~/.ssh/linux-man-baseline.pub admin@mon-serveur.example.com

Si ton serveur écoute sur un port non standard, tu peux aussi passer par SSH avec des options explicites :

ssh-copy-id -i ~/.ssh/id_ed25519.pub "-p 2222 admin@mon-serveur.example.com"

Le but n’est pas de multiplier les options pour faire joli. Le but est d’avoir une commande lisible, facile à rejouer, et cohérente avec ta documentation d’exploitation. Sur un parc de serveurs, cette discipline te fait gagner un temps énorme.

Dans mon repo linux-man/infra-baseline, je pars d’ailleurs d’une logique très simple : poser d’abord la clé SSH d’administration, puis seulement ensuite dérouler le hardening, l’audit Lynis et les protections complémentaires. L’ordre compte plus que la sophistication.

Générer une clé dédiée si nécessaire

Si tu ne veux pas réutiliser ta clé personnelle, crée une clé spécifique pour ce contexte :

ssh-keygen -t ed25519 -f ~/.ssh/linux-man-baseline -C "linux-man-baseline"

Cette approche est propre pour deux raisons. D’abord, tu sépares les usages. Ensuite, tu simplifies la révocation : si cette clé doit disparaître un jour, tu sais exactement où elle est utilisée. C’est particulièrement utile quand plusieurs environnements coexistent entre prod, préprod et lab.

Comment vérifier que la connexion SSH par clé fonctionne vraiment

Après un ssh-copy-id, ne passe pas directement à l’étape suivante. Teste la connexion. Le but est de confirmer que le serveur accepte bien la clé et que tu n’es plus dépendant du mot de passe.

ssh admin@mon-serveur.example.com

Si tu veux voir ce qu’il se passe côté client, ajoute un mode verbeux :

ssh -vvv admin@mon-serveur.example.com

Tu pourras vérifier si la bonne clé est proposée, si le serveur l’accepte, ou s’il refuse l’authentification pour une raison de permissions. C’est ce niveau de validation qui évite les faux positifs du style “la commande a tourné, donc c’est bon”. Non. Tant que la session réelle n’est pas ouverte, ce n’est pas bon.

Une fois le test validé, tu peux passer à un durcissement plus sérieux : changement de port si tu le souhaites, restriction des utilisateurs autorisés, désactivation du mot de passe, ajout de fail2ban, et éventuellement supervision continue. Si tu veux cadrer ce chantier dans le temps, une offre de maintenance serveurs Linux évite de laisser ce genre de base critique en plan entre deux urgences.

Les erreurs les plus courantes avec ssh-copy-id

Passer proprement en production après ssh-copy-id

Une fois la clé validée, le bon réflexe n’est pas de s’arrêter là. Le vrai objectif est d’enchaîner sur une baseline cohérente : compte admin dédié, accès root limité, authentification par mot de passe désactivée, journalisation exploitable, bannissement d’IP abusives, et documentation minimale pour rejouer la procédure sans improviser.

C’est précisément pour ça que je ne traite jamais ssh-copy-id comme une astuce isolée. Dans une exploitation sérieuse, c’est la première marche d’un socle plus large. Une clé bien posée permet ensuite d’automatiser proprement le reste avec Ansible, sans empiler des exceptions à la main machine par machine.

Si tu gères plusieurs serveurs ou si tu veux remettre ton socle d’accès à plat, le bon investissement n’est pas seulement “faire marcher SSH”, mais définir une méthode répétable. C’est là que le sujet devient intéressant pour l’entreprise : moins de dépendance à la mémoire d’un seul admin, moins d’accès bricolés, et moins de surprises lors d’un audit ou d’un départ de collaborateur.

FAQ sur ssh-copy-id Linux

Conclusion

ssh-copy-id linux n’est pas un gadget. C’est une brique simple, mais essentielle, pour construire un accès SSH propre sur un serveur Linux. Si tu veux éviter les connexions bricolées, les mots de passe qui traînent et les erreurs de droits, commence par là, puis enchaîne avec un vrai socle de durcissement.

Et si tu veux cadrer ça proprement sur un serveur existant ou un nouveau parc, mieux vaut poser une méthode solide tout de suite plutôt que de courir après les exceptions plus tard.