Avant de changer quoi que ce soit
Prouvez qu'une clé fonctionne. Cette commande n'essaie que les clés, donc un mot de passe ne peut pas masquer un problème :
ssh -o PreferredAuthentications=publickey user@server
Pas encore de clé ? Générez une clé SSH Ed25519 et placez-la d'abord sur le serveur.
Vérifiez que ce compte peut utiliser sudo, et gardez une session connectée ouverte jusqu'à la dernière étape. Dans notre test, les sessions existantes ont continué après un rechargement : cette session est donc votre voie de retour si les nouveaux réglages vous enferment dehors. Si votre hébergeur propose une console web, repérez-la dès maintenant.
Voir ce qui s'applique aujourd'hui
sudo sshd -T | grep -iE '^(passwordauthentication|kbdinteractiveauthentication|usepam|permitrootlogin) '
sshd -T affiche les valeurs que sshd utilise réellement après avoir lu tous ses fichiers. Fiez-vous à cela, pas à ce que vous lisez dans sshd_config.
Pourquoi modifier sshd_config ne change souvent rien
Pour la plupart des réglages, sshd retient la première valeur trouvée. Sur les Debian et Ubuntu actuelles, la ligne Include /etc/ssh/sshd_config.d/*.conf se trouve près du début de sshd_config : les fichiers drop-in sont donc lus en premier, dans l'ordre de leur nom. Vérifiez chez vous :
grep -n Include /etc/ssh/sshd_config
ls /etc/ssh/sshd_config.d/
Les images cloud fournissent souvent un fichier comme 50-cloud-init.conf contenant PasswordAuthentication yes. Nous avons testé ce cas : avec ce fichier en place, mettre PasswordAuthentication no dans sshd_config laissait sshd -T afficher yes.
Un fichier dont le nom arrive en premier dans l'ordre alphabétique l'emporte sur tous les autres, c'est pourquoi le nom ci-dessous commence par 00. S'il n'y a pas de ligne Include, comme sur les serveurs antérieurs à OpenSSH 8.2 ou avec un fichier personnalisé, mettez les réglages dans sshd_config lui-même, au-dessus de tout bloc Match, et supprimez les lignes précédentes qui les définissent.
Créer le fichier drop-in
sudo tee /etc/ssh/sshd_config.d/00-no-passwords.conf >/dev/null <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
EOF
KbdInteractiveAuthentication doit aussi être désactivé. Avec seulement PasswordAuthentication no et ce réglage activé, notre serveur de test acceptait encore le mot de passe du compte, car PAM le demande via keyboard-interactive. Avant OpenSSH 8.7, l'option s'appelait ChallengeResponseAuthentication, et l'ancien nom fonctionne toujours comme alias.
UsePAM peut rester à yes. PAM gère aussi les contrôles de compte et l'initialisation de la session, et avec les deux lignes ci-dessus il ne propose plus de saisie de mot de passe. Certaines distributions déconseillent de le désactiver : laissez-le tel quel.
PermitRootLogin prohibit-password autorise root à se connecter uniquement avec une clé. Utilisez no si personne ne doit se connecter en root. Jusqu'à OpenSSH 10.0, sshd -T affiche prohibit-password sous son ancien nom, without-password.
Tester le fichier, puis recharger
sudo sshd -t
sudo sshd -T | grep -iE '^(passwordauthentication|kbdinteractiveauthentication) '
sshd -t n'affiche rien quand la configuration est valide. Ne sautez pas cette étape : nous avons envoyé le signal de rechargement à un sshd dont un fichier drop-in contenait une ligne invalide, et il s'est arrêté, ne laissant aucun service à l'écoute des nouvelles connexions.
sudo systemctl reload ssh # Debian, Ubuntu
sudo systemctl reload sshd # RHEL, Fedora, Arch
Préférez reload à restart. Un reload demande seulement au sshd en cours de relire sa configuration, et notre session ouverte y a survécu. Sur Debian 13, le fichier de service exécute aussi sshd -t avant d'envoyer le signal, donc un fichier cassé y bloque le rechargement, mais ne comptez pas sur toutes les distributions pour le faire.
Confirmer depuis un autre terminal
Ne touchez pas à la session ouverte, et essayez une connexion par mot de passe depuis votre propre machine :
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password,keyboard-interactive user@server
Le résultat doit être Permission denied (publickey). sans invite de mot de passe. Vérifiez ensuite que votre clé vous laisse toujours entrer avec une nouvelle connexion. Ce n'est qu'alors que vous pouvez fermer l'ancienne session.
Si une invite de mot de passe apparaît encore
- Relancez
sudo sshd -T. S'il afficheyes, un autre fichier le définit avant le vôtre : cherchez avecsudo grep -ri passwordauthentication /etc/ssh/. - Cherchez un bloc
Match. Il peut réactiver les mots de passe pour certains utilisateurs ou adresses, et un simplesshd -Tne le montre pas. Passez les détails de la connexion pour l'évaluer :sudo sshd -T -C user=user,host=example.com,addr=203.0.113.10 | grep -i ^passwordauthentication - Vérifiez que vous atteignez bien ce serveur et ce port, et pas une autre machine derrière le même nom.
- Une invite pour la phrase secrète d'une clé n'est pas une invite de mot de passe. Elle vient de votre propre machine et déverrouille votre clé.
Questions
PasswordAuthentication no suffit-il ?
Pas toujours. Avec KbdInteractiveAuthentication actif, PAM peut encore demander le mot de passe via keyboard-interactive. Désactivez les deux.
Pourquoi sshd_config dit no mais les mots de passe marchent encore ?
Un fichier de /etc/ssh/sshd_config.d est lu en premier et l'emporte. Vérifiez la valeur appliquée avec sudo sshd -T.
Faut-il mettre UsePAM no ?
Non. PAM gère aussi les contrôles de compte et les sessions. Avec les deux réglages désactivés, il ne demande plus de mot de passe.
Sources
- sshd_config(5), manuel OpenBSD
- sshd(8), manuel OpenBSD
- Notes de version d'OpenSSH 8.2, Include dans sshd_config
- Notes de version d'OpenSSH 8.7, KbdInteractiveAuthentication