SSH : créer une clé RSA et se connecter à un serveur avec l'agent SSH

Se connecter à un serveur avec un mot de passe, c'est s'exposer aux attaques par force brute, aux mots de passe réutilisés et à l'hameçonnage. L'authentification par clé SSH règle ces trois problèmes d'un coup : aucun secret ne transite sur le réseau, et une clé est impossible à deviner.

Dans cet article, nous allons créer une clé RSA, l'installer sur un serveur, puis la charger dans l'agent SSH pour ne taper sa phrase de passe qu'une fois par session. Les commandes fonctionnent sous Linux, macOS et Windows 10 ou 11, qui intègrent tous le client OpenSSH.

Comment ça marche

Une clé SSH est en réalité une paire de clés liées mathématiquement :

la clé privée (id_rsa) reste sur votre poste. Elle ne doit jamais être copiée ailleurs ni partagée ;
la clé publique (id_rsa.pub) peut être distribuée sans risque. On la dépose sur chaque serveur auquel on veut accéder.

À la connexion, le serveur envoie un défi que seul le détenteur de la clé privée peut signer. Il vérifie la signature avec la clé publique : si elle est valide, vous êtes connecté. Aucun secret n'a circulé.

 Votre poste                                  Serveur
 ───────────                                  ───────
 ~/.ssh/id_rsa      clé privée, ne sort jamais
 ~/.ssh/id_rsa.pub  ──── copiée une fois ────►  ~/.ssh/authorized_keys

 ssh-agent          ◄─── défi à signer ──────── sshd
 (clé déchiffrée    ──── signature ──────────►  vérifiée avec la
  en mémoire)                                   clé publique

Sur le disque, la clé privée est elle-même chiffrée par une phrase de passe : un voleur qui récupérerait le fichier ne pourrait pas s'en servir. L'agent SSH, enfin, garde la clé déchiffrée en mémoire pendant votre session, pour vous éviter de retaper la phrase de passe à chaque connexion.

Étape 1 : générer la paire de clés

ssh-keygen -t rsa -b 4096 -C "moi@mon-portable"

-t rsa : le type de clé ;
-b 4096 : la taille en bits. La valeur par défaut est de 3072 bits depuis OpenSSH 8.1 ; 4096 offre une marge supplémentaire pour un coût négligeable ;
-C : un commentaire libre, ajouté à la fin de la clé publique. Indiquez la machine ou l'usage, pour reconnaître la clé plus tard dans un fichier authorized_keys.

ssh-keygen pose ensuite trois questions :

Generating public/private rsa key pair.
Enter file in which to save the key (/home/moi/.ssh/id_rsa):
Enter passphrase for "/home/moi/.ssh/id_rsa" (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/moi/.ssh/id_rsa
Your public key has been saved in /home/moi/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:z/vOrluaWoH7hM8NQHr1z10v0hPoEyPJbOKzoTEM3Bs moi@mon-portable

Appuyez sur Entrée pour garder l'emplacement par défaut, puis choisissez une phrase de passe. Ne la laissez pas vide : grâce à l'agent, vous ne la taperez qu'une fois par session. Une suite de quelques mots sans rapport (« agrafe-cheval-batterie-correct ») est à la fois solide et facile à retenir. ssh-keygen affiche ensuite un petit dessin, le randomart, qui représente visuellement l'empreinte de la clé.

Deux fichiers ont été créés, avec des droits bien précis :

$ ls -l ~/.ssh
-rw------- 1 moi moi 3381 oct.  24 18:27 id_rsa
-rw-r--r-- 1 moi moi  742 oct.  24 18:27 id_rsa.pub

La clé privée n'est lisible que par vous (-rw-------, soit 600). C'est indispensable : OpenSSH refuse d'utiliser une clé privée lisible par d'autres utilisateurs. Si vous copiez vos clés d'une machine à une autre, rétablissez les droits :

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

Étape 2 : déposer la clé publique sur le serveur

Le serveur doit connaître votre clé publique. Elle va dans le fichier ~/.ssh/authorized_keys du compte auquel vous vous connectez. La commande ssh-copy-id s'en charge : elle vous demande le mot de passe du serveur une dernière fois, ajoute la clé et règle les droits.

ssh-copy-id -i ~/.ssh/id_rsa.pub deploy@serveur.example.com

Sous Windows, ssh-copy-id n'existe pas. Cette commande PowerShell fait la même chose :

Get-Content $env:USERPROFILE\.ssh\id_rsa.pub |
  ssh deploy@serveur.example.com "umask 077; mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Lors de la toute première connexion à un serveur, SSH affiche son empreinte et demande confirmation :

The authenticity of host 'serveur.example.com (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:Xq3mO1v7…
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Ce n'est pas une formalité : c'est votre protection contre un serveur pirate qui se ferait passer pour le vôtre. Comparez l'empreinte avec celle que fournit votre hébergeur, ou affichez-la depuis la console du serveur avec ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub. Une fois acceptée, elle est mémorisée dans ~/.ssh/known_hosts, et SSH vous alertera si elle change un jour.

Étape 3 : charger la clé dans l'agent SSH

Si vous vous connectez maintenant, SSH vous demande la phrase de passe de la clé à chaque fois. L'agent règle ce problème : on lui confie la clé une fois, il la garde déchiffrée en mémoire et signe les défis à votre place. La version déchiffrée de la clé n'est jamais écrite sur le disque.

Linux

La plupart des environnements de bureau (GNOME, KDE…) démarrent déjà un agent. Vérifiez avec echo $SSH_AUTH_SOCK : si la variable est vide, démarrez-en un dans le terminal, puis ajoutez la clé :

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa

ssh-add demande la phrase de passe, puis confirme : Identity added: /home/moi/.ssh/id_rsa (moi@mon-portable). Pour lister les clés chargées :

$ ssh-add -l
4096 SHA256:z/vOrluaWoH7hM8NQHr1z10v0hPoEyPJbOKzoTEM3Bs moi@mon-portable (RSA)

macOS

Le système lance l'agent automatiquement. L'option --apple-use-keychain enregistre en plus la phrase de passe dans le trousseau macOS : vous n'aurez plus à la taper du tout, même après un redémarrage. Avant macOS 12, cette option s'appelait -K.

ssh-add --apple-use-keychain ~/.ssh/id_rsa

Windows 10 et 11

Le client OpenSSH est intégré à Windows, mais le service ssh-agent est désactivé par défaut. Activez-le une fois pour toutes, dans un PowerShell lancé en tant qu'administrateur :

Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent

Puis, dans une session PowerShell normale :

ssh-add $env:USERPROFILE\.ssh\id_rsa

Sous Windows, l'agent conserve les clés d'un redémarrage à l'autre, protégées par votre session Windows : cette commande ne se lance qu'une fois.

Quelques options utiles

ssh-add -t 8h ~/.ssh/id_rsa : la clé est retirée automatiquement de l'agent au bout de 8 heures ;
ssh-add -d ~/.ssh/id_rsa : retire cette clé de l'agent ;
ssh-add -D : retire toutes les clés, par exemple avant de laisser votre poste sans surveillance.

Étape 4 : se connecter

ssh deploy@serveur.example.com

Plus de mot de passe, plus de phrase de passe : l'agent a signé le défi, vous êtes connecté. Pour ne plus taper l'adresse complète, décrivez le serveur dans le fichier ~/.ssh/config :

Host prod
    HostName serveur.example.com
    User deploy
    IdentityFile ~/.ssh/id_rsa
    IdentitiesOnly yes
    AddKeysToAgent yes

Désormais, ssh prod suffit, et ce raccourci fonctionne aussi avec scp, rsync ou Git (scp sauvegarde.sql prod:/tmp/). Les deux dernières lignes méritent une explication :

IdentitiesOnly yes : SSH ne propose que la clé indiquée, au lieu de toutes celles de l'agent. Cela évite l'erreur « Too many authentication failures » quand l'agent contient beaucoup de clés ;
AddKeysToAgent yes : si la clé n'est pas encore dans l'agent, SSH l'y ajoute automatiquement dès que vous avez tapé la phrase de passe une première fois.

Rebondir par un serveur intermédiaire

Beaucoup d'infrastructures n'exposent qu'un serveur d'accès, appelé « bastion », par lequel on rejoint les autres machines. L'option -J (ProxyJump) fait le saut en une seule commande, et l'authentification sur la machine finale utilise toujours votre agent local :

ssh -J deploy@bastion.example.com deploy@10.0.0.12

Vous croiserez aussi l'option -A (transfert d'agent), qui rend votre agent utilisable depuis le serveur distant. Utilisez-la avec prudence : tant que vous êtes connecté, l'administrateur de ce serveur, ou un attaquant qui en aurait pris le contrôle, peut se servir de vos clés pour se connecter ailleurs. Pour rebondir, -J est plus sûr.

Bonus : désactiver les mots de passe sur le serveur

Une fois la connexion par clé vérifiée, vous pouvez interdire les mots de passe : les robots qui testent des milliers de combinaisons n'auront plus aucune chance. Sur Debian ou Ubuntu, créez un fichier de configuration dédié :

# /etc/ssh/sshd_config.d/10-cles-uniquement.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

Le préfixe 10- a son importance : pour chaque option, sshd retient la première valeur qu'il lit, et les fichiers de ce dossier sont lus par ordre alphabétique. Vérifiez la syntaxe, rechargez le service (il s'appelle sshd sur Red Hat et ses dérivés), puis contrôlez les valeurs réellement appliquées :

sudo sshd -t && sudo systemctl reload ssh
sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

Gardez votre session ouverte et testez la connexion dans un autre terminal avant de vous déconnecter. Si quelque chose cloche, vous pourrez encore corriger la configuration au lieu de vous retrouver enfermé dehors.

RSA ou Ed25519 ?

Vous avez peut-être lu qu'il valait mieux utiliser Ed25519. C'est vrai pour une nouvelle clé : plus courte et plus rapide, elle est disponible partout depuis des années (OpenSSH 6.5, en 2014). RSA 4096 reste un excellent choix quand il faut dialoguer avec du matériel ou des systèmes anciens qui ne connaissent qu'elle : vieux équipements réseau, certaines appliances, logiciels d'entreprise.

Une précision qui sème souvent la confusion : depuis OpenSSH 8.8, l'algorithme de signature ssh-rsa, basé sur SHA-1, est désactivé par défaut. Vos clés RSA restent parfaitement utilisables : elles signent simplement avec SHA-2 (rsa-sha2-256 ou rsa-sha2-512). Seuls de très vieux serveurs, qui ignorent SHA-2, peuvent poser problème.

Pour créer une clé Ed25519, seule la première commande change ; tout le reste de l'article s'applique à l'identique :

ssh-keygen -t ed25519 -C "moi@mon-portable"

En cas de problème

Premier réflexe : relancer la connexion en mode bavard avec ssh -v. SSH détaille alors chaque clé proposée et la réponse du serveur.

Message	Cause probable	Solution
`Permission denied (publickey)`	La clé n'est pas dans `authorized_keys`, ou les droits de `~/.ssh` sont trop ouverts côté serveur.	Vérifier le fichier, puis `chmod 700 ~/.ssh` et `chmod 600 ~/.ssh/authorized_keys` sur le serveur.
`UNPROTECTED PRIVATE KEY FILE!`	La clé privée est lisible par d'autres utilisateurs.	`chmod 600 ~/.ssh/id_rsa`
`Could not open a connection to your authentication agent` (ou `Error connecting to agent` sous Windows)	Aucun agent n'est accessible depuis ce terminal.	`eval "$(ssh-agent -s)"` sous Linux, démarrer le service `ssh-agent` sous Windows.
`Too many authentication failures`	L'agent propose trop de clés avant la bonne.	`IdentitiesOnly yes` dans `~/.ssh/config`.
`REMOTE HOST IDENTIFICATION HAS CHANGED!`	L'empreinte du serveur a changé : réinstallation… ou tentative d'interception.	Vérifier auprès de l'hébergeur, puis `ssh-keygen -R serveur.example.com`.

À retenir

La clé privée ne quitte jamais votre poste ; seule la clé publique va sur les serveurs.
Protégez toujours la clé privée par une phrase de passe : l'agent vous évite de la retaper.
ssh-copy-id installe la clé, ssh-add la confie à l'agent, ~/.ssh/config simplifie les connexions.
Vérifiez l'empreinte d'un serveur à la première connexion, et désactivez les mots de passe une fois les clés en place.
Pour rebondir entre serveurs, préférez -J à -A.