Clé SSH ed25519 : créer la clé et se connecter sans mot de passe

Pour créer une clé SSH ed25519, une seule commande suffit : ssh-keygen -t ed25519. Elle produit 2 fichiers : une clé privée qui reste sur votre ordinateur, et une clé publique que vous déposez sur le serveur. Ensuite, ssh prouve votre identité avec la clé au lieu d'envoyer le mot de passe du compte, que l'étape 6 permet de désactiver. Ce guide vise un serveur Linux (Debian 13 et Ubuntu 24.04), depuis Windows, macOS ou Linux, et va jusqu'à la désactivation du mot de passe sans vous couper l'accès.

En bref

• ssh-keygen -t ed25519 -C "vous@exemple" crée la clé. Gardez -t ed25519 : avant la version 9.5, OpenSSH génère du RSA par défaut.
• Gardez une phrase de passe (passphrase) : elle protège le fichier de clé sur votre disque, et ssh-agent évite de la retaper. Dans Windows PowerShell 5.1, -N "" ne fonctionne pas : laissez ssh-keygen poser la question.
• ssh-copy-id copie la clé publique. Si une autre clé est déjà acceptée, il peut répondre « All keys were skipped » sans rien copier : ajoutez -f. Il n'est pas fourni avec OpenSSH pour Windows (alternative à l'étape 3).
• Si le serveur ignore votre clé, le client affiche seulement Permission denied (publickey). : la raison se lit dans le journal du serveur.
• Pour couper le mot de passe, mettez PasswordAuthentication no et KbdInteractiveAuthentication no, vérifiez avec sshd -T, et gardez une session ouverte.

Prérequis

• Un client OpenSSH : ssh -V affiche sa version. L'installation sous Windows, la première connexion et l'alias ~/.ssh/config sont expliqués dans Se connecter en SSH à un VPS.
• Un accès au serveur déjà fonctionnel (mot de passe ou autre clé), pour y déposer la nouvelle clé.
• 203.0.113.10 est une adresse réservée à la documentation et utilisateur votre compte : remplacez-les.

1. Générer la clé ed25519

Vérifiez d'abord qu'aucune clé du même nom n'existe : ls ~/.ssh/id_ed25519 sous Linux et macOS, Test-Path $HOME\.ssh\id_ed25519 sous PowerShell. « No such file or directory » ou False est le résultat attendu. Si ssh-keygen demande Overwrite (y/n)?, répondez n : l'écraser détruit définitivement l'ancienne clé privée. Pour une seconde clé, ajoutez -f ~/.ssh/id_ed25519_vps et remplacez id_ed25519 par ce nom ensuite. Sous PowerShell, écrivez $HOME\.ssh\… au lieu de ~/.ssh/… : le tilde n'a un sens garanti que pour les commandes de PowerShell, pas pour ssh-keygen.

La commande est la même sur les trois systèmes :

ssh-keygen -t ed25519 -C "vous@exemple"

-C ajoute un commentaire qui repère la clé dans authorized_keys. ssh-keygen demande l'emplacement du fichier (Entrée garde le nom par défaut), puis la phrase de passe, 2 fois. Le manuel recommande 10 à 30 caractères difficiles à deviner ; une phrase perdue ne se récupère pas.

ssh-keygen -lf ~/.ssh/id_ed25519.pub affiche l'empreinte de la clé (256 est sa taille en bits), et cat ~/.ssh/id_ed25519.pub sa ligne publique :

256 SHA256:LwbZ4NAwtnWh9cOtLdC8TsQ0ud3iLj4P4AwdE+mrcas vous@exemple (ED25519)
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKT0lePDFrVkvPu6s/0iYhD+gjIO85Ot64pb9IEvBUdZ vous@exemple

Le fichier id_ed25519 est la clé privée : elle reçoit les droits 600 à la création, et Microsoft la compare à un mot de passe. id_ed25519.pub est la clé publique, qui n'est pas secrète. Ne collez jamais la clé privée dans un ticket ni sur un site en ligne.

Pourquoi garder -t ed25519

Les notes de la version 9.5 d'OpenSSH indiquent que ssh-keygen génère Ed25519 par défaut. Les versions plus anciennes, comme celle de Debian 12 (9.2p1) ou d'un Windows 10 non mis à jour, peuvent générer du RSA : gardez toujours -t ed25519.

Le piège de Windows PowerShell 5.1 : -N ""

Les tutoriels utilisent -N "" pour une clé sans phrase de passe. Dans Windows PowerShell 5.1, l'argument vide disparaît avant ssh-keygen, qui répond :

option requires an argument -- N

Aucune clé n'est créée. Le plus simple : omettre -N. Pour une clé d'automatisation sans phrase de passe, ceci fonctionne dans Windows PowerShell 5.1 (depuis PowerShell 7.3, le passage des arguments aux programmes externes a changé : -N "" passe directement et cette forme risque de définir "" comme phrase de passe) :

ssh-keygen -t ed25519 -C "vous@exemple" -N '""'

Une clé sans phrase de passe ouvre le serveur à quiconque copie le fichier. Microsoft déconseille une phrase vide, car la phrase et le fichier de clé forment ensemble une authentification à deux facteurs.

2. Phrase de passe et ssh-agent

Sans agent, ssh demande la phrase de passe à chaque connexion. ssh-agent garde la clé privée en mémoire pour ne pas la redemander.

Linux et macOS

Si ssh-add -l indique qu'aucun agent n'est joignable, lancez-en un avec la première commande ci-dessous. ssh-add demande la phrase de passe une fois, et ssh-add -l liste les clés chargées :

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

256 SHA256:LwbZ4NAwtnWh9cOtLdC8TsQ0ud3iLj4P4AwdE+mrcas vous@exemple (ED25519)

ssh-add -t 1h limite la durée de chargement à une heure.

Sur macOS 10.12.2 et plus, GitHub documente les directives AddKeysToAgent, UseKeychain et IdentityFile (UseKeychain ne sert qu'avec une phrase de passe), et IgnoreUnknown UseKeychain en cas d'erreur « Bad configuration option: usekeychain ». Voici le bloc de ~/.ssh/config adapté à votre VPS :

Host mon-vps
    HostName 203.0.113.10
    User utilisateur
    AddKeysToAgent yes
    IgnoreUnknown UseKeychain
    UseKeychain yes
    IdentityFile ~/.ssh/id_ed25519

Lancez ensuite une fois ssh-add --apple-use-keychain ~/.ssh/id_ed25519.

Windows

Le service ssh-agent est désactivé par défaut. Pour l'activer, ouvrez PowerShell en administrateur et lancez les commandes de la documentation de Microsoft :

Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent
ssh-add $env:USERPROFILE\.ssh\id_ed25519

3. Copier la clé publique sur le serveur

Le serveur lit les clés autorisées dans ~/.ssh/authorized_keys, une par ligne. Si le panneau de votre hébergeur a un champ pour les clés SSH, collez-y la ligne du .pub : selon l'hébergeur, elle n'est installée qu'à la (ré)installation du serveur, et l'étape 5 vous dit si elle est active. Sinon, ou si elle est refusée :

Linux et macOS : ssh-copy-id

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

Selon le manuel, ssh-copy-id se connecte (en général avec le mot de passe du compte) et ajoute la clé à la fin de ~/.ssh/authorized_keys.

Le piège « All keys were skipped ». Avant de copier, ssh-copy-id tente une connexion avec la nouvelle clé et, si elle réussit, la croit déjà installée. Si l'essai passe grâce à une autre clé déjà acceptée (par exemple donnée avec -o IdentityFile=), rien n'est copié, et la commande se termine pourtant avec le code 0 :

/usr/bin/ssh-copy-id: WARNING: All keys were skipped because they already exist on the remote system.
		(if you think this is a mistake, you may want to use -f option)

La connexion avec la nouvelle clé échoue ensuite (Permission denied (publickey).). Ajoutez -f pour forcer la copie sans l'essai :

ssh-copy-id -f -i ~/.ssh/id_ed25519.pub -o IdentityFile=$HOME/.ssh/ancienne_cle utilisateur@203.0.113.10

Remplacez ancienne_cle par le fichier de la clé qui marche déjà (par exemple id_rsa). Avec un simple mot de passe, ce cas ne vous concerne pas : utilisez la commande simple ci-dessus. Relancer -f ajouterait une ligne en double, sans danger mais inutile.

Windows : pas de ssh-copy-id

ssh-copy-id ne figure pas parmi les outils fournis avec OpenSSH pour Windows. La documentation de Visual Studio Code propose une commande PowerShell pour un serveur Linux. Celle-ci en est adaptée : elle ajoute .Trim(), qui retire le retour à la ligne que Out-String ajoute, sinon il se retrouve dans authorized_keys. Lancez-la une seule fois, sans apostrophe dans le commentaire de la clé :

$USER_AT_HOST="utilisateur@203.0.113.10"
$PUBKEYPATH="$HOME\.ssh\id_ed25519.pub"
$pubKey=(Get-Content "$PUBKEYPATH" | Out-String).Trim(); ssh "$USER_AT_HOST" "mkdir -p ~/.ssh && chmod 700 ~/.ssh && echo '${pubKey}' >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Le mot de passe est demandé une fois. Contrôlez ensuite le fichier avec ssh utilisateur@203.0.113.10 "cat -A ~/.ssh/authorized_keys" : chaque clé doit tenir sur sa propre ligne, qui finit par $, sans ^M (retour chariot Windows en trop). Si authorized_keys existait déjà et ne finit pas par un saut de ligne, la commande colle la nouvelle clé à la dernière ligne. Dans ce cas, préférez la variante manuelle : affichez la clé avec Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub, connectez-vous et collez-la sur une nouvelle ligne à la fin du fichier avec nano.

4. Droits de ~/.ssh et authorized_keys

Par défaut, sshd (le serveur SSH) applique StrictModes : il refuse la clé si le dossier personnel, ~/.ssh ou authorized_keys sont modifiables par d'autres utilisateurs ou n'appartiennent pas à votre compte, d'après le manuel de sshd_config. Sur le serveur :

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod go-w ~

N'utilisez jamais chmod 777.

Le client ne dit rien. Avec authorized_keys en 666 (modifiable par tous), il affiche seulement Permission denied (publickey). La cause n'apparaît que dans le journal du serveur (sudo journalctl -u ssh -n 30 --no-pager sur Debian et Ubuntu), où vous lirez :

Authentication refused: bad ownership or modes for file …/authorized_keys

Pour un dossier, le message devient bad ownership or modes for directory.

Côté client, la clé privée doit rester en 600 (ou plus strict). Sinon, ssh affiche WARNING: UNPROTECTED PRIVATE KEY FILE! et ignore la clé. Sous Windows, ssh-keygen.exe crée une clé que ssh accepte telle quelle. Après une copie de fichier, qui peut hériter de droits plus larges, les commandes icacls sont dans l'article sur la connexion SSH (lien en début de guide).

5. Tester la clé avant de toucher au serveur

Ouvrez un nouveau terminal, sans fermer votre session actuelle, et forcez la clé :

ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes -o PreferredAuthentications=publickey -o PasswordAuthentication=no utilisateur@203.0.113.10

IdentitiesOnly=yes empêche ssh de proposer aussi les autres clés de l'agent : sans lui, une autre clé pourrait réussir à sa place. Le client demande la phrase de passe (sauf si l'agent a la clé) et ouvre la session sans demander le mot de passe du compte. Si vous lisez Permission denied (publickey)., ne continuez pas : reprenez les étapes 3 et 4.

6. Désactiver le mot de passe sans se couper l'accès

Ne commencez que si l'étape 5 a réussi. Connectez-vous au serveur (ssh utilisateur@203.0.113.10) et laissez cette fenêtre ouverte : les commandes ci-dessous se tapent ici, sur le serveur, jamais sur votre ordinateur. Faites vos tests dans une autre fenêtre. Le compte doit avoir sudo. Ces commandes valent pour Debian et Ubuntu (service ssh) : ailleurs, vérifiez le nom du service.

Avant de continuer, sauvegardez votre clé privée (gestionnaire de mots de passe ou disque chiffré) : une fois le mot de passe coupé, sa perte vous enferme. Ajoutez idéalement une deuxième clé (autre poste), vérifiez que l'accès de secours de votre hébergeur s'ouvre et faites un snapshot (instantané du serveur) s'il en propose.

Deux réglages sont nécessaires : PasswordAuthentication et KbdInteractiveAuthentication valent tous deux yes par défaut, d'après le manuel de sshd_config. Le module Set Passwords de la documentation de cloud-init prévient que PasswordAuthentication no peut ne pas suffire si l'authentification clavier-interactif (le serveur pose des questions au clavier, dont souvent le mot de passe) reste active. Désactivez donc les deux.

Autre piège : sur Debian et Ubuntu, sshd_config inclut d'abord /etc/ssh/sshd_config.d/*.conf, et la première valeur obtenue pour un mot-clé l'emporte. Un fichier de ce dossier peut donc annuler votre modification. Regardez ce qui existe, puis écrivez votre réglage dans un fichier qui passe en premier (ordre alphabétique) :

sudo ls /etc/ssh/sshd_config.d/
sudo grep -ri -E 'PasswordAuthentication|KbdInteractiveAuthentication' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

Collez ensuite ce bloc (lancez d'abord sudo -v) :

sudo tee /etc/ssh/sshd_config.d/00-cles-seulement.conf > /dev/null <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
EOF
sudo sshd -t && sudo systemctl reload ssh
sudo sshd -T | grep -Ei 'passwordauthentication|pubkeyauthentication|kbdinteractive'

sshd -t contrôle la configuration sans l'appliquer : il n'affiche rien si tout va bien, et une faute de frappe donne Bad configuration option: PasswordAuthentification, précédé du fichier et du numéro de ligne, ce qui empêche le rechargement grâce à &&. sshd -T affiche la configuration réellement appliquée, mais pas les réglages réservés à certains utilisateurs ou adresses par des blocs Match : la section « Vérifier » reste la vraie preuve. Vous devez lire :

pubkeyauthentication yes
passwordauthentication no
kbdinteractiveauthentication no

Si passwordauthentication yes s'affiche encore, un fichier lu avant le vôtre impose la valeur. Relancez le grep : le nom de fichier avant : indique d'où vient chaque ligne. Mettez no à cet endroit (ou donnez à votre fichier un nom qui passe avant), puis rechargez.

Marche arrière si vous n'arrivez plus à vous connecter, depuis la session restée ouverte :

sudo mv /etc/ssh/sshd_config.d/00-cles-seulement.conf /etc/ssh/sshd_config.d/00-cles-seulement.conf.off && sudo systemctl reload ssh

Si vous avez aussi mis no dans un autre fichier, remettez-y la valeur d'origine, puis rechargez.

Vérifier que tout fonctionne

1. Dans une troisième fenêtre, ssh utilisateur@203.0.113.10 ouvre une session avec la clé. Ne fermez les autres qu'ensuite.
2. Un essai par mot de passe doit échouer :

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password utilisateur@203.0.113.10

Le serveur ne propose plus que la clé : ssh répond Permission denied (publickey).

Problèmes fréquents

• Le mot de passe est encore demandé, ou Permission denied (publickey). Vérifiez dans l'ordre : le nom d'utilisateur, la clé collée dans le fichier authorized_keys de ce compte, les droits (étape 4, avec le journal du serveur), puis ssh -v, qui montre les clés proposées (Offering public key). Le serveur coupe après MaxAuthTries essais (6 par défaut). Nommez la clé avec -i et ajoutez -o IdentitiesOnly=yes pour que seule cette clé soit proposée, comme l'explique l'article sur la connexion SSH.
• La phrase de passe est redemandée à chaque connexion. La clé n'est pas dans l'agent (étape 2).
• Vous êtes enfermé hors du serveur. Passez par l'accès de secours de l'hébergeur et appliquez la ma