Comment désactiver la connexion par mot de passe pour SSH

Vérifiez d'abord qu'une connexion par clé fonctionne et gardez une session ouverte. Créez ensuite /etc/ssh/sshd_config.d/00-no-passwords.conf avec PasswordAuthentication no et KbdInteractiveAuthentication no, exécutez sudo sshd -t, rechargez le service et contrôlez le résultat avec sudo sshd -T. Modifier uniquement sshd_config reste souvent sans effet, car un fichier drop-in antérieur l'emporte.

Mis à jour le . Exécuté sur OpenSSH 10.0 sous Debian 13 avec un client sur macOS, y compris l'écrasement par drop-in, la connexion par mot de passe via keyboard-interactive et l'arrêt de sshd sur un fichier cassé.

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 affiche yes, un autre fichier le définit avant le vôtre : cherchez avec sudo grep -ri passwordauthentication /etc/ssh/.
  • Cherchez un bloc Match. Il peut réactiver les mots de passe pour certains utilisateurs ou adresses, et un simple sshd -T ne 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

Autres guides : Clés et connexion

Tous les guides