Désactiver sans risque la connexion SSH par mot de passe et passer aux clés

Pourquoi passer aux clés

Quand la connexion par mot de passe est active, toute personne qui atteint le port SSH de votre serveur peut essayer de deviner. C’est le réglage d’OpenSSH par défaut : le manuel indique que PasswordAuthentication vaut yes par défaut. Les clés sont bien plus difficiles à deviner, et couper les mots de passe bloque aussi les failles de la vérification du mot de passe elle-même. La faille d’OpenSSH sous Alpine Linux de cette semaine en est un exemple : l’avis d’Alpine précise que les serveurs où la connexion par mot de passe est désactivée ne sont pas touchés.

Il vous faut un compte sur le serveur auquel vous pouvez déjà vous connecter, avec le droit d’utiliser sudo ou doas.

1. Créez une clé sur votre ordinateur

Lancez ceci sur votre propre ordinateur, pas sur le serveur :

ssh-keygen -t ed25519

Appuyez sur Entrée pour garder l’emplacement habituel et tapez une phrase de passeun mot de passe qui protège le fichier de la clé lui-même, pour qu’une copie volée du fichier ne suffise pas à se connecter. Vous obtenez deux fichiers dans le dossier .ssh de votre répertoire personnel : id_ed25519, la clé privée, qui ne quitte jamais votre ordinateur, et id_ed25519.pub, la clé publique, qui va sur le serveur.

2. Copiez la clé publique sur le serveur

Sous Linux et macOS :

ssh-copy-id utilisateur@serveur

La commande demande votre mot de passe une dernière fois et ajoute la clé à ~/.ssh/authorized_keys sur le serveur. Si ssh-copy-id n’est pas disponible, par exemple sous Windows, ouvrez id_ed25519.pub, copiez son unique ligne et collez-la dans ~/.ssh/authorized_keys sur le serveur. Le dossier .ssh doit être lisible par vous seul (chmod 700 ~/.ssh et chmod 600 ~/.ssh/authorized_keys).

3. Testez la clé avant de toucher à quoi que ce soit

Gardez la session actuelle ouverte. Dans une nouvelle fenêtre de terminal, lancez ssh utilisateur@serveur. Si la commande demande la phrase de passe de la clé, ou vous connecte directement, la clé fonctionne. Si elle demande le mot de passe du compte, arrêtez-vous et réparez la clé d’abord, sinon vous vous enfermerez dehors à l’étape suivante.

4. Désactivez la connexion par mot de passe

Sur le serveur, ajoutez ces deux lignes à la configuration du serveur SSH, dans /etc/ssh/sshd_config ou dans un nouveau fichier de /etc/ssh/sshd_config.d/ si votre système utilise ce dossier :

PasswordAuthentication no

KbdInteractiveAuthentication no

La seconde ligne ferme l’autre méthode proche du mot de passe, le keyboard-interactiveune méthode de connexion où le serveur pose des questions, en général le mot de passe, par une invite ; l’ancien nom de l’option est ChallengeResponseAuthentication. Pour le compte root, le réglage par défaut d’OpenSSH, PermitRootLogin prohibit-password, bloque déjà la connexion par mot de passe.

Il y a un piège. Le manuel précise que, pour chaque option, « la première valeur obtenue sera utilisée ». Certains systèmes, dont certaines images cloud, installent leur propre fichier dans sshd_config.d avec PasswordAuthentication yes, et si ce fichier est lu en premier, votre ligne reste sans effet. L’étape 6 permet de le repérer.

5. Vérifiez le fichier et redémarrez le service

Lancez sudo sshd -t. La commande vérifie la configuration et n’affiche rien si elle est valide. Redémarrez ensuite le service SSH :

• Debian et Ubuntu : sudo systemctl restart ssh
• Fedora, Red Hat et apparentés : sudo systemctl restart sshd
• Alpine : rc-service sshd restart

Gardez l’ancienne session ouverte jusqu’à la fin de l’étape suivante.

6. Vérifiez que ça a marché

Sur le serveur, lancez :

sudo sshd -T | grep -i -E 'passwordauthentication|kbdinteractiveauthentication'

sshd -T affiche la configuration que sshd utilisera réellement. Les deux lignes doivent se terminer par no. Si l’une indique yes, cherchez dans /etc/ssh/sshd_config.d/ un fichier qui la définit plus tôt.

Depuis votre ordinateur, essayez de forcer une connexion par mot de passe :

ssh -o PubkeyAuthentication=no utilisateur@serveur

Le serveur doit refuser avec « Permission denied (publickey) ». Votre ssh utilisateur@serveur habituel doit continuer à fonctionner avec la clé.

En cas de problème

Si vous perdez l’accès, utilisez la console fournie par votre hébergeur ou par votre logiciel de machine virtuelle, annulez la modification et redémarrez le service SSH. C’est pour cela que l’ancienne session reste ouverte jusqu’au bout. Gardez une copie de votre clé privée en lieu sûr : si vous perdez la seule copie, il vous faudra cette console pour ajouter une nouvelle clé publique.