Clé SSH Ubuntu - Sécurité et efficacité au quotidien

Mettre en place une authentification par clé SSH sur Ubuntu réduit le risque lié aux mots de passe et simplifie le quotidien entre poste local, serveur et pipeline. Je vais montrer comment créer une paire de clés proprement, choisir l’algorithme adapté, installer la clé publique côté serveur et vérifier que la connexion passe sans friction. J’ajouterai aussi les pièges que je vois le plus souvent en environnement DevOps, parce que c’est là que les déploiements perdent du temps.

Pourquoi la clé SSH change vraiment le quotidien sur Ubuntu

Une paire de clés SSH repose sur une logique simple, mais très efficace : la clé privée ne quitte jamais ta machine, tandis que la clé publique est déposée sur le serveur dans ~/.ssh/authorized_keys. Le serveur ne reçoit donc jamais le secret, il vérifie seulement que tu possèdes bien la clé correspondante. Pour moi, c’est l’un des meilleurs compromis entre sécurité et confort dès qu’on administre plusieurs machines.

En pratique, cela supprime les mots de passe partagés, limite les blocages dans les scripts et rend les accès beaucoup plus propres pour un poste de travail, un bastion, une VM de test ou une machine de production. C’est aussi plus lisible dans un environnement DevOps : on sait quelle machine détient quelle identité, et on peut révoquer un accès sans changer tout le reste. Si le poste est volé, la passphrase sur la clé privée ajoute une barrière utile. Si la passphrase est oubliée, en revanche, il n’existe pas de récupération magique : il faut générer une nouvelle clé et redistribuer la clé publique.

Avec cette base en tête, le choix de l’algorithme devient la première vraie décision à prendre, parce qu’il influence à la fois la sécurité, la compatibilité et la facilité d’exploitation.

Choisir le bon algorithme avant de générer la paire

Sur Ubuntu récent, je pars presque toujours sur Ed25519. La documentation Ubuntu Server le recommande pour son coût de calcul faible et sa clé plus courte, et ssh-keygen le propose même par défaut lorsqu’on ne précise rien sur les versions récentes. En clair : si tu n’as pas de contrainte de compatibilité, c’est le choix le plus propre.

Si je dois parler à un vieux serveur, un équipement réseau ou un service qui n’aime pas Ed25519, je bascule vers RSA 4096. Ce n’est pas mon premier choix, mais c’est encore le plan B le plus réaliste quand la compatibilité prime. Le bon réflexe, ici, n’est pas de sur-optimiser : c’est d’aligner l’algorithme sur le contexte réel. Une fois ce point posé, la génération elle-même reste très simple.

Générer la paire de clés sur Ubuntu pas à pas

La commande la plus directe ressemble à ceci :

ssh-keygen -t ed25519 -C "prenom.nom@poste"

Je garde volontairement le commentaire avec -C, parce qu’il aide à identifier la clé plus tard dans un environnement où plusieurs machines coexistent. Le commentaire n’est pas une protection, mais il évite de se perdre quand on relit une clé ou qu’on audite des accès.

1. Si le répertoire ~/.ssh n’existe pas encore, crée-le et verrouille ses droits avec mkdir -p ~/.ssh puis chmod 700 ~/.ssh.
2. Lance ssh-keygen -t ed25519 -C "prenom.nom@poste" ou, si tu veux un nom explicite, ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_devops -C "devops@laptop".
3. Quand le terminal demande un emplacement, tu peux accepter le chemin proposé ou choisir un nom plus parlant si tu gères plusieurs identités.
4. Ajoute une passphrase solide. Sur un poste de travail, je la mets presque toujours ; je ne la supprime que dans des cas d’automatisation très cadrés.
5. Vérifie ensuite les fichiers créés avec ls -l ~/.ssh/id_ed25519* : tu dois voir la clé privée et la clé publique avec l’extension .pub.

La clé privée s’appelle en général ~/.ssh/id_ed25519, et la clé publique ~/.ssh/id_ed25519.pub. Si tu as choisi un autre nom avec -f, garde exactement la même logique pour la suite. Je conseille aussi de contrôler l’empreinte avec ssh-keygen -lf ~/.ssh/id_ed25519.pub : c’est une vérification simple, rapide et utile quand on veut être sûr de ne pas copier le mauvais fichier. La prochaine étape consiste justement à déposer cette clé publique au bon endroit.

Installer la clé publique sur un serveur ou un dépôt

Quand le serveur autorise encore la connexion par mot de passe, ssh-copy-id reste la méthode la plus rapide et la plus propre. Elle utilise ssh pour se connecter, puis ajoute la clé publique dans ~/.ssh/authorized_keys côté distant. C’est pratique, lisible et très difficile à rater si tu pointes vers le bon utilisateur.

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@serveur

Si le serveur ne laisse pas passer cette méthode, je passe en mode manuel, surtout dans un script ou lors d’un bootstrap minimal :

cat ~/.ssh/id_ed25519.pub | ssh user@serveur 'umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys'

Sur la machine cible, le fichier authorized_keys doit contenir une clé par ligne. Les commentaires et les lignes vides sont ignorés, ce qui simplifie l’audit. Je vérifie aussi systématiquement les permissions : chmod 700 ~/.ssh et chmod 600 ~/.ssh/authorized_keys. C’est l’un des points qui font le plus souvent échouer une authentification pourtant correctement configurée. Une fois la clé installée, il reste à valider que le client l’utilise vraiment.

Vérifier l’accès et corriger les blocages fréquents

Le test le plus direct consiste à cibler explicitement la clé :

ssh -i ~/.ssh/id_ed25519 user@serveur

Si tout est bon, la connexion doit passer sans mot de passe, ou demander seulement la passphrase locale de ta clé privée. Quand ça bloque, je passe immédiatement en mode verbeux pour voir quelle identité est proposée et pourquoi le serveur la refuse :

ssh -v -i ~/.ssh/id_ed25519 user@serveur

Quand je veux éviter de ressaisir la passphrase à chaque session, j’utilise l’agent SSH sur mon poste de travail ; en revanche, sur un runner temporaire ou une machine éphémère, je préfère garder les choses explicites avec -i. Si le problème persiste malgré tout, je regarde aussi la configuration du serveur, parce que AuthorizedKeysFile peut avoir été personnalisé. À partir de là, la question n’est plus seulement technique : elle devient aussi organisationnelle.

Ce que je standardise quand plusieurs machines Ubuntu entrent en jeu

Quand je gère plusieurs environnements, je préfère une clé par machine ou par rôle, pas une clé unique réutilisée partout. C’est plus facile à révoquer, plus simple à auditer et beaucoup plus propre quand un poste est perdu ou qu’un accès doit être coupé rapidement. Pour le nommage, je choisis des fichiers explicites comme id_ed25519_laptop, id_ed25519_prod ou id_ed25519_ci : ce n’est pas décoratif, c’est du temps gagné au moment du support.

Host prod-bastion
  HostName 203.0.113.10
  User ubuntu
  IdentityFile ~/.ssh/id_ed25519_prod
  IdentitiesOnly yes

Ce bloc dans ~/.ssh/config évite qu’OpenSSH essaie une identité au hasard parmi celles déjà chargées. Dans un environnement DevOps, ce détail compte vraiment, parce qu’il réduit les comportements ambigus et les débogages inutiles. Je garde aussi une règle simple : si une clé n’est plus censée servir, je la retire du serveur, je documente sa révocation et je régénère une paire propre si le contexte l’exige. Pour un usage Ubuntu standard, la combinaison la plus saine reste la même : Ed25519, passphrase solide, clé publique correctement déposée et vérification immédiate de l’accès. Quand ces quatre points sont en place, l’authentification SSH devient un outil fiable plutôt qu’une source de frictions.