Clés SSH : configurer la connexion au serveur sans mot de passe

Une clé SSH est une paire de fichiers : la clé privée reste chez vous, la clé publique est déposée sur le serveur. À la connexion, le serveur vérifie que vous possédez la clé privée correspondant à l'une des clés publiques autorisées, et vous laisse entrer sans mot de passe. C'est plus pratique et bien plus sûr qu'un mot de passe : deviner une clé par essais successifs est pratiquement impossible. Voici la configuration des clés SSH, de la génération à la désactivation de la connexion par mot de passe, avec les erreurs sur lesquelles on bute le plus souvent.

Comment fonctionne l'authentification par clé

Les clés sont asymétriques. La clé publique (id_ed25519.pub) peut être montrée à n'importe qui : elle ne permet pas de reconstituer la clé privée. La clé privée (id_ed25519) ne quitte jamais votre machine et n'est jamais transmise sur le réseau.

Lors de la connexion, le client indique au serveur la clé qu'il souhaite utiliser. Le serveur cherche cette clé publique dans le fichier ~/.ssh/authorized_keys de l'utilisateur et, si elle y figure, demande au client de signer les données de la session avec la clé privée. La signature est vérifiée avec la clé publique, et la connexion est autorisée. Aucun mot de passe n'est transmis.

Étape 1. Générer une clé : ssh-keygen

Sur votre ordinateur (Linux, macOS ou Windows 10/11 avec OpenSSH intégré), exécutez :

ssh-keygen -t ed25519 -C "alena@laptop"

L'option -t choisit l'algorithme, -C ajoute un commentaire qui sera placé à la fin de la clé publique et qui permettra plus tard de savoir à qui elle appartient. Ed25519 est l'algorithme moderne recommandé : les clés sont courtes, rapides et robustes. Si le serveur est très ancien et ne prend pas en charge Ed25519, utilisez RSA d'au moins 3072 bits : ssh-keygen -t rsa -b 4096.

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/alena/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/alena/.ssh/id_ed25519
Your public key has been saved in /home/alena/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:Xq3v0m6c1y2pVv8m3N0uYv9yQm0e6dFv5gH2rZt1aBc alena@laptop

Faut-il une phrase de passe

La phrase de passe chiffre la clé privée sur le disque. Si l'ordinateur portable est volé ou si le fichier fuite, la clé est inutilisable sans elle. Pour une clé personnelle, il est recommandé de définir une phrase de passe ; pour ne pas la saisir à chaque connexion, utilisez ssh-agent : il garde la clé déchiffrée en mémoire jusqu'à la fin de la session.

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
ssh-add -l      # liste des clés chargées

Les clés sans phrase de passe se justifient pour l'automatisation, par exemple pour la CI ou un script de sauvegarde. Une telle clé doit être restreinte côté serveur (voir plus bas).

Étape 2. Copier la clé publique sur le serveur : ssh-copy-id

Le plus simple est d'utiliser ssh-copy-id. Il se connecte une dernière fois avec le mot de passe, ajoute votre clé publique à ~/.ssh/authorized_keys sur le serveur et règle les bons droits.

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@203.0.113.10

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/alena/.ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
deploy@203.0.113.10's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'deploy@203.0.113.10'"
and check to make sure that only the key(s) you wanted were added.

Si le serveur écoute sur un port non standard, ajoutez -p 2222.

Si ssh-copy-id n'est pas disponible

Il n'existe pas de ssh-copy-id sous Windows. On peut alors transférer la clé manuellement, avec une seule commande :

cat ~/.ssh/id_ed25519.pub | ssh deploy@203.0.113.10 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Les hébergeurs cloud demandent en général la clé publique dès la création du serveur : elle est alors placée dans authorized_keys via cloud-init.

Étape 3. Tester la connexion

ssh deploy@203.0.113.10

Si le mot de passe n'est plus demandé (ou seulement la phrase de passe de la clé), tout fonctionne. Lors de la première connexion à un nouveau serveur, SSH affiche l'empreinte de la clé de l'hôte et demande si vous lui faites confiance. Après votre réponse yes, l'empreinte est enregistrée dans ~/.ssh/known_hosts et, par la suite, SSH vous avertit si la clé du serveur change.

Pour voir quelles clés le client essaie et pourquoi le serveur refuse, lancez la connexion en mode détaillé :

ssh -v deploy@203.0.113.10

Le fichier ~/.ssh/config : des noms courts pour les serveurs

Lorsqu'on gère plusieurs serveurs, retaper à chaque fois l'utilisateur, l'adresse IP, le port et le chemin de la clé devient fastidieux. Tout cela se décrit dans ~/.ssh/config :

Host prod
    HostName 203.0.113.10
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host bastion
    HostName bastion.example.com
    User alena

Host bdd-interne
    HostName 10.0.0.15
    User admin
    ProxyJump bastion

Host *
    ServerAliveInterval 60
    AddKeysToAgent yes

Désormais, ssh prod suffit, et scp, rsync et Git comprennent aussi ces noms : rsync -av ./site/ prod:/var/www/.

• IdentitiesOnly yes — n'utiliser que la clé indiquée. Sans cette ligne, le client essaie toutes les clés de l'agent, et le serveur peut vous déconnecter pour trop de tentatives avant d'atteindre la bonne.
• ProxyJump — se connecter à un serveur interne à travers un serveur intermédiaire (bastion) en une seule commande.
• ServerAliveInterval — envoyer un « ping » toutes les 60 secondes pour que la connexion ne tombe pas pendant les périodes d'inactivité.

Le fichier doit avoir les droits 600, sinon SSH peut refuser de le lire : chmod 600 ~/.ssh/config.

Agent forwarding : quand il est utile et pourquoi il est risqué

Il arrive qu'il faille rebondir depuis un serveur — par exemple pour faire un git pull depuis un dépôt privé. Copier la clé privée sur ce serveur n'est pas une option. On utilise alors ssh -A ou ForwardAgent yes : le serveur accède à votre agent pendant la session. Mais toute personne ayant les droits root sur ce serveur peut aussi utiliser l'agent tant que vous êtes connecté. N'activez donc le transfert que pour des hôtes de confiance ; pour un rebond à travers un serveur intermédiaire, préférez ProxyJump, qui n'ouvre pas l'agent.

Étape 4. Désactiver la connexion par mot de passe

Tant que la connexion par mot de passe est autorisée, le serveur reste une cible pour les attaques par force brute. Une fois que vous êtes sûr de pouvoir vous connecter avec une clé, désactivez les mots de passe. Important : ne fermez pas la session en cours avant d'avoir testé la connexion dans une nouvelle fenêtre, sinon vous risquez de perdre l'accès.

Ouvrez /etc/ssh/sshd_config (ou créez un fichier dans /etc/ssh/sshd_config.d/ si la configuration principale l'inclut avec la directive Include) et définissez :

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

PermitRootLogin no interdit complètement la connexion en root : les administrateurs se connectent avec leur propre compte et élèvent leurs droits avec sudo. Si la connexion en root est indispensable, utilisez PermitRootLogin prohibit-password — uniquement par clé.

Vérifiez la syntaxe et rechargez le service :

sudo sshd -t
sudo systemctl reload ssh      # sous Debian/Ubuntu ; sur les systèmes RHEL — sshd

La commande sshd -t n'affiche rien si la configuration est correcte. Dans un nouveau terminal, vérifiez maintenant que la connexion par clé fonctionne et que le serveur refuse la connexion par mot de passe :

$ ssh -o PubkeyAuthentication=no deploy@203.0.113.10
deploy@203.0.113.10: Permission denied (publickey).

Protection supplémentaire

La désactivation des mots de passe est la mesure principale. Ensuite, on limite l'accès au port 22 avec le pare-feu (ufw allow from 198.51.100.0/24 to any port 22) et on installe fail2ban, qui bloque une adresse IP après une série de tentatives échouées. L'état de la protection SSH s'affiche avec sudo fail2ban-client status sshd.

Une clé utilisée pour l'automatisation peut être restreinte directement dans authorized_keys à l'aide d'options placées devant la clé : par exemple, from="198.51.100.7",no-port-forwarding,no-pty ssh-ed25519 AAAA... backup n'autorise la connexion que depuis une seule adresse et sans shell interactif.

Erreurs courantes et leur correction

Permission denied (publickey)

L'erreur la plus fréquente. Les causes, de la plus courante à la plus rare :

1. Droits incorrects sur le serveur. sshd ignore authorized_keys si le répertoire ou le fichier est accessible en écriture à d'autres. Solution : chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys, et le répertoire personnel ne doit pas être accessible en écriture au groupe ni aux autres.
2. Mauvais propriétaire. Si vous avez créé les fichiers avec sudo, ils appartiennent à root. Solution : sudo chown -R deploy:deploy /home/deploy/.ssh.
3. La clé a été déposée pour le mauvais utilisateur. Vous avez copié la clé pour root, alors que vous vous connectez en tant que deploy, ou l'inverse.
4. Le client propose la mauvaise clé. Regardez ssh -v : les lignes Offering public key montrent les clés essayées. Indiquez la bonne avec -i ou IdentityFile.
5. La clé a été abîmée lors de la copie. La clé publique doit tenir sur une seule ligne. Un retour à la ligne venu du presse-papiers la casse.

La cause du refus côté serveur figure dans le journal : sudo journalctl -u ssh -n 30 (sous RHEL — -u sshd). On y trouve des lignes du type Authentication refused: bad ownership or modes for directory /home/deploy/.ssh.

UNPROTECTED PRIVATE KEY FILE

Le client refuse d'utiliser une clé privée lisible par d'autres utilisateurs. Solution : chmod 600 ~/.ssh/id_ed25519.

REMOTE HOST IDENTIFICATION HAS CHANGED

La clé de l'hôte ne correspond pas à celle enregistrée dans known_hosts. Cela arrive après la réinstallation d'un serveur ou un changement d'adresse IP, mais la situation ressemble aussi à une attaque de type « homme du milieu ». Assurez-vous que le serveur a bien été réinstallé, puis supprimez l'ancienne entrée : ssh-keygen -R 203.0.113.10.

Too many authentication failures

L'agent a proposé trop de clés au serveur, qui a fermé la connexion à cause de MaxAuthTries. La solution : IdentitiesOnly yes et un IdentityFile explicite dans ~/.ssh/config.

Synthèse

La configuration des clés SSH prend cinq minutes : ssh-keygen -t ed25519, ssh-copy-id, test de la connexion, puis PasswordAuthentication no et rechargement de sshd pendant qu'une seconde session reste ouverte. Le fichier ~/.ssh/config évite les commandes à rallonge, et les droits 700/600 règlent la plupart des erreurs « Permission denied ». SSH, rsync ainsi que la protection du serveur par pare-feu et fail2ban sont traités en pratique dans notre cours sur Linux.