Désactiver l'authentification SSH par mot de passe sans se bloquer dehors

Pourquoi c'est le changement le plus rentable

Presque toute compromission d'un serveur Linux exposé à internet commence par un mot de passe valide — deviné, réutilisé depuis la fuite de quelqu'un d'autre, ou hameçonné. Désactivez l'authentification par mot de passe et toute cette catégorie cesse d'être possible. Pas plus difficile : impossible. Il n'y a pas de mot de passe à deviner.

Rien d'autre sur une liste de durcissement n'en approche pour l'effort demandé. C'est deux lignes de configuration et un rechargement.

On le repousse par crainte de mal le faire, et ce risque est réel : mauvais ordre et vous vous déconnectez d'une machine que vous n'atteignez que par SSH. Le reste de ce guide est cet ordre.

La séquence sûre

Chaque étape ci-dessous est vérifiée avant la suivante, et la session dans laquelle vous êtes reste ouverte tout du long. Ne la fermez qu'à la toute fin.

D'abord, générez une clé si vous n'en avez pas. Ed25519 est le choix par défaut actuel : plus courte, plus rapide et au moins aussi solide qu'une clé RSA de 4096 bits.

# 1. Sur votre propre machine, pas sur le serveur
ssh-keygen -t ed25519 -C "vous@example.com"

# 2. Copier la clé publique sur le serveur (demande votre mot de passe une dernière fois)
ssh-copy-id user@server

# 3. Vérifier depuis un SECOND terminal, sans fermer le premier
ssh -o PreferredAuthentications=publickey -o PasswordAuthentication=no user@server

La configuration qui compte vraiment

Seulement après le succès de l'étape 3, modifiez la configuration du serveur. Sur les distributions modernes, le fichier à modifier n'est peut-être pas sshd_config lui-même : beaucoup fournissent un répertoire /etc/ssh/sshd_config.d/ dont les fichiers sont inclus et peuvent écraser ce que vous écrivez plus haut.

Quatre réglages font le travail :

# /etc/ssh/sshd_config.d/10-hardening.conf   (ou directement sshd_config)
PasswordAuthentication no
KbdInteractiveAuthentication no    # ancien nom : ChallengeResponseAuthentication
PermitRootLogin prohibit-password  # ou 'no' si root ne se connecte jamais directement
PubkeyAuthentication yes

# Testez toujours la configuration avant de recharger — cela attrape les fautes
# de frappe qui empêcheraient sinon sshd de revenir du tout :
sudo sshd -t

# Puis reload plutôt que restart : les sessions existantes survivent
sudo systemctl reload ssh    # ou 'sshd' dans la famille RHEL

Vérifier que c'est bien pris

Ne faites pas confiance au fichier de configuration — demandez à sshd ce qu'il a réellement résolu. sshd -T affiche la configuration effective après toutes les inclusions et surcharges :

sudo sshd -T | grep -iE 'passwordauthentication|kbdinteractiveauthentication|permitrootlogin'
# attendu :
#   passwordauthentication no
#   kbdinteractiveauthentication no
#   permitrootlogin prohibit-password

# Et prouvez-le de l'extérieur : ceci doit maintenant être refusé
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password user@server

Ce que cela ne règle pas

Le tout-clé supprime le risque de devinage. Il ne supprime ni le trafic, ni tous les chemins d'entrée.

Les bots continuent de se connecter. Ils ignorent votre configuration, ils continuent donc de proposer des mots de passe et d'être rejetés — chaque tentative coûtant toujours une connexion TCP, un fork de sshd et une ligne de journal. Votre journal d'authentification se remplit toujours de bruit, et l'événement dont vous aviez besoin disparaît toujours. Quelque chose doit encore bloquer les sources.

Et une clé privée est un fichier. Sur un portable volé, dans un dépôt où quelqu'un l'a committée par erreur, dans l'environnement d'un runner CI. Protégez les clés par une phrase de passe, gardez-les hors des machines partagées et faites-les tourner quand quelqu'un part — une clé fuitée est exactement aussi grave qu'un mot de passe fuité.

Cela ne fait rien non plus contre un sshd non corrigé, un service exposé sur un autre port ou une application vulnérable sur le même hôte. C'est le meilleur changement disponible, et c'est un contrôle parmi plusieurs.

Le complément

Les mots de passe coupés, il reste le volume. SSH Protector lit le même flux d'authentification, bannit les sources qui continuent d'arriver — par sous-réseau, définitivement, restaurées au démarrage — et met votre propre adresse en liste blanche avant tout blocage.

Il détecte le vrai port SSH depuis la configuration de sshd au lieu de supposer 22, un serveur que vous avez déjà déplacé est donc couvert sans rien configurer.

Le tout-clé pour le risque. Le bannissement des sources pour la charge, et pour le journal lisible qui vous laisse remarquer le seul événement qui compte.