Désactiver login root SSH et connexion par mot de passe sur Linux

Tant que SSH accepte le login root et l’authentification par mot de passe, votre VPS Linux est exposé à des attaques brute force 24h/24 — bots scannent en permanence le port 22. Ce guide montre comment durcir sshd_config proprement, sans risque de vous bloquer dehors, vérifié contre les recommandations OpenSSH, CIS Benchmarks et Tenable.

Pour un VPS chez HebergTonServ, le port SSH est ouvert par défaut et vous avez l’accès root par email — parfait pour suivre ce guide.

⚠️ CRITIQUE — à lire avant de continuer

Avant de désactiver root + password, vous DEVEZ avoir :

1. Un utilisateur sudo créé et testé (guide)
2. Une clé SSH publique copiée dans ~/.ssh/authorized_keys de cet utilisateur
3. Testé la connexion par clé avec succès sur cet utilisateur
4. Une deuxième session SSH ouverte comme backup pendant la modif

Sans ces 4 prérequis, vous risquez de vous bloquer dehors définitivement. Seul un reboot rescue console hébergeur vous récupère alors.

Pourquoi durcir SSH ?

Solution : authentification par clé publique uniquement, login root interdit, brute force devient mathématiquement infaisable.

Étape 1 — Vérifier les prérequis

Tester votre utilisateur sudo

Depuis Windows, ouvrez un nouveau terminal :

ssh jean@votre-ip-vps

Vous devez :

• Vous connecter sans saisir de mot de passe (clé fonctionne)
• Pouvoir exécuter sudo whoami qui retourne root

Si l’un des deux échoue, STOP — corrigez avant de continuer. Voir Se connecter en SSH depuis Windows et Créer un utilisateur sudo Linux.

Garder une session de secours

Ouvrez un deuxième terminal SSH en tant que jean ET laissez-le ouvert pendant toute la procédure. Si la modif sshd_config casse SSH, cette session reste active et vous pouvez réparer.

Étape 2 — Localiser sshd_config

Toujours connecté en jean :

sudo nano /etc/ssh/sshd_config

Sur certains systèmes modernes, des overrides existent dans :

/etc/ssh/sshd_config.d/*.conf

Vérifiez :

ls /etc/ssh/sshd_config.d/

Les fichiers .conf dans sshd_config.d/ prennent priorité sur sshd_config principal. Cherchez vos modifs là-bas si elles ne s’appliquent pas.

Étape 3 — Modifier les directives clés

Dans sshd_config, trouvez (ou ajoutez si absent) ces 3 lignes :

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Variantes pour PermitRootLogin

prohibit-password est acceptable si vous gardez un script automatisé (rsync backup) qui doit se connecter en root via clé. Sinon no est le standard.

Décommenter les lignes

Si une ligne commence par #, retirez le #. Exemple :

Avant :

#PermitRootLogin prohibit-password
#PasswordAuthentication yes

Après :

PermitRootLogin no
PasswordAuthentication no

Renforcer encore (optionnel)

ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
UsePAM yes
PermitEmptyPasswords no
MaxAuthTries 3
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2
Protocol 2

Avec Match blocks, vous pouvez aussi cibler certains users/groups. Exemple : autoriser uniquement le groupe ssh-users à se connecter via AllowGroups ssh-users.

Étape 4 — Valider la syntaxe avant reload

sudo sshd -t

Ne jamais reload sshd sans avoir validé la syntaxe. Une erreur ferait échouer le démarrage du démon → plus aucun SSH possible.

Étape 5 — Recharger sshd

sudo systemctl reload ssh    # Debian / Ubuntu
sudo systemctl reload sshd   # RHEL / CentOS / Fedora

reload (pas restart) : reload applique la nouvelle conf sans couper les sessions existantes. Votre session de backup reste active.

Étape 6 — Tester depuis un nouveau terminal

Sans fermer votre session de backup, ouvrez un 3e terminal et testez :

Test 1 — Tentative root (doit échouer)

ssh root@votre-ip-vps

Sortie attendue :

Permission denied (publickey).

Test 2 — Tentative password (doit échouer)

Ajoutez -o PreferredAuthentications=password pour forcer le mode mot de passe :

ssh -o PreferredAuthentications=password jean@votre-ip-vps

Sortie attendue :

Permission denied (publickey).

Test 3 — Tentative clé sur user sudo (doit réussir)

ssh jean@votre-ip-vps

Connecté ? Le hardening fonctionne.

Si Test 3 échoue, retournez à votre session de backup (toujours ouverte), restaurez sshd_config en remettant PasswordAuthentication yes, reload, et investiguez les permissions de ~/.ssh/authorized_keys.

Workflow récap — sans risque

1. Créer user sudo            → ssh jean@vps fonctionne
2. Copier clé pub dans authorized_keys
3. Tester ssh jean sans mot de passe → OK
4. Garder 2 sessions ouvertes
5. Éditer sshd_config :
   - PermitRootLogin no
   - PasswordAuthentication no
6. sudo sshd -t (valider)
7. sudo systemctl reload ssh
8. Tester depuis 3e terminal
9. Si OK : fermer toutes les sessions
   Si KO : revenir aux sessions backup et corriger

Bonus — bloquer les bots avant qu’ils tentent

Couplez ce hardening avec :

1. Fail2Ban — bannit les IPs après échecs répétés. Voir : Installer Fail2Ban sur Linux
2. Changer le port SSH — divise par 100 le bruit des bots. Voir : Changer le port SSH
3. UFW — limite l’accès SSH à certaines IPs si possible

sudo ufw allow from VOTRE_IP_FIXE to any port 22

FAQ

J’ai cassé sshd_config et plus aucun SSH ne fonctionne, comment récupérer ?

Trois options dans l’ordre de difficulté :

1. Session backup encore ouverte : utilisez-la pour sudo nano /etc/ssh/sshd_config et corriger
2. Console rescue de l’hébergeur (KVM/IPMI/VNC) — accès direct sans SSH
3. Boot rescue mode depuis l’image de réinstallation, montez /, corrigez

Mon hébergeur fournit-il une console de secours ?

La plupart des sérieux oui (HebergTonServ, OVH, Hetzner). C’est une fonctionnalité essentielle d’un VPS pro. Vérifiez avant d’acheter.

Puis-je désactiver root login mais garder les mots de passe ?

Oui : PermitRootLogin no + PasswordAuthentication yes. Sécurité partielle — le brute force ne cible plus root mais peut encore tenter d’autres usernames. Préférez la combo no/no avec clés.

Le port 22 est trop attaqué, dois-je le changer ?

Oui — passe de 1000+ tentatives/jour à <10. Voir : Changer le port SSH. Note : un changement de port n’est pas une mesure de sécurité forte (security through obscurity), c’est une réduction de bruit.

Comment savoir si quelqu’un a tenté de brute force ?

sudo journalctl -u ssh | grep -i "failed\|invalid"
sudo cat /var/log/auth.log | grep -i "failed\|invalid"

Avec Fail2Ban :

sudo fail2ban-client status sshd

Que faire si je perds ma clé privée SSH ?

Si vous avez encore une session ouverte : ajoutez une nouvelle clé publique dans authorized_keys. Sinon, utilisez la console rescue de l’hébergeur pour copier une nouvelle clé. Pour cela, HebergTonServ fournit un accès console KVM.

Conclusion

Désactiver le login root SSH et l’auth par mot de passe transforme votre VPS d’une cible facile en forteresse. Combiné avec une clé ED25519, Fail2Ban et un port SSH custom, votre serveur devient mathématiquement résistant au brute force. Le seul risque : se bloquer dehors par accident — d’où la session de backup obligatoire.

Pour un VPS Linux avec console KVM de secours et accès root par email, HebergTonServ propose des serveurs premium dès quelques euros par mois.

Pour aller plus loin

• Se connecter en SSH à un VPS depuis Windows
• Créer un utilisateur sudo Linux pas à pas
• Changer le port SSH de votre serveur Linux
• Installer Fail2Ban sur Linux pour bloquer les attaques SSH
• VPS Linux haute performance dès quelques €/mois