Étape 1 : assurez-vous d'avoir une autre voie d'accès
Connectez-vous en utilisateur normal avec votre clé, dans une fenêtre que vous gardez ouverte, et vérifiez que sudo fonctionne :
ssh user@server
sudo -v
Si vous n'avez pas encore un tel compte, voir comment créer un utilisateur SSH avec sudo. Faites-le d'abord. C'est la seule étape qui vous protège d'un blocage.
Étape 2 : cherchez les réglages déjà présents
sudo grep -ri permitrootlogin /etc/ssh/sshd_config /etc/ssh/sshd_config.d/
Pour la plupart des réglages de sshd, la première valeur lue l'emporte, pas la dernière. Sur Debian et Ubuntu, sshd_config a Include /etc/ssh/sshd_config.d/*.conf près du début : les fichiers de ce dossier sont donc lus en premier, dans l'ordre de leur nom. Dans notre test, avec 00-cloud.conf contenant PermitRootLogin yes et 10-no-root.conf contenant no, root restait autorisé.
L'image d'un hébergeur peut placer un fichier de ce genre : supprimez ou modifiez toute ligne de ce type. Sans ligne Include, modifiez PermitRootLogin dans sshd_config lui-même.
Étape 3 : ajoutez le réglage
echo 'PermitRootLogin no' | sudo tee /etc/ssh/sshd_config.d/10-no-root.conf
Étape 4 : vérifiez avant de recharger
sudo sshd -t
sudo sshd -T | grep -i permitrootlogin
sshd -t n'affiche rien quand tout va bien. Une faute de frappe donne un message comme unsupported option "maybe", et vous devez la corriger avant de continuer. sshd -T montre la valeur que le serveur utilisera réellement :
permitrootlogin no
Étape 5 : rechargez
# Debian and Ubuntu
sudo systemctl reload ssh
# Red Hat, Fedora and similar
sudo systemctl reload sshd
Un rechargement s'applique aux nouvelles connexions, et votre session ouverte continue. Nous l'avons confirmé : une session ouverte avant le changement a continué à tourner, et une nouvelle connexion a suivi la nouvelle règle.
Étape 6 : testez depuis une nouvelle fenêtre
ssh root@server
Vous devriez voir Permission denied, même avec la bonne clé. Le journal du serveur indique :
ROOT LOGIN REFUSED FROM 203.0.113.10 port 41288
Connectez-vous ensuite avec votre utilisateur normal depuis une autre nouvelle fenêtre, et exécutez de nouveau sudo -v.
Ce que fait chaque valeur
| Valeur | Mot de passe | Clé | Clé avec commande forcée |
|---|---|---|---|
yes | Autorisé | Autorisé | Autorisé |
prohibit-password | Refusé | Autorisé | Autorisé |
forced-commands-only | Refusé | Refusé | Autorisé |
no | Refusé | Refusé | Refusé |
La valeur par défaut est prohibit-password, depuis OpenSSH 7.0. Sur un système qui ne l'a pas changée, root ne peut donc pas se connecter avec un mot de passe, mais une clé root fonctionne. without-password est un ancien nom pour la même valeur. sshd -T a affiché without-password sur notre serveur OpenSSH 10.0 quand le réglage était prohibit-password. La version 10.1 a changé cela pour afficher le nom actuel.
Une commande forcée désigne command="..." dans authorized_keys. forced-commands-only convient à une tâche de sauvegarde qui a vraiment besoin de root pour une commande fixe.
Exceptions avec Match
Pour autoriser les clés root uniquement depuis une adresse d'administration, ajoutez ceci au même fichier, sous la première ligne :
Match Address 203.0.113.10
PermitRootLogin prohibit-password
Un simple sshd -T ne montre pas l'effet d'un bloc Match. Utilisez -C pour décrire une connexion et voir ce qui s'appliquerait. Ces deux commandes ont donné des réponses différentes dans notre test :
sudo sshd -T -C user=root,host=server,addr=203.0.113.10 | grep -i permitrootlogin
sudo sshd -T -C user=root,host=server,addr=198.51.100.7 | grep -i permitrootlogin
Si vous vous retrouvez quand même enfermé dehors
Utilisez la console de votre hébergeur, qui ne passe pas par SSH. Supprimez le fichier que vous avez ajouté et rechargez sshd.
Questions
Quelle différence entre PermitRootLogin no et prohibit-password ?
no refuse root de toutes les façons. prohibit-password, la valeur par défaut, refuse le mot de passe de root mais accepte encore une clé root.
Recharger sshd ferme-t-il ma session ouverte ?
Non. Un rechargement s'applique aux nouvelles connexions, et les sessions déjà ouvertes continuent.
Et si je me retrouve bloqué après avoir désactivé root ?
Utilisez la console web de votre hébergeur, qui ne passe pas par SSH. Supprimez le fichier ajouté et rechargez sshd.