Durcir un accès SSH exposé : les six réglages qui comptent

Testé le 4 septembre 2026 Sur Debian 13 (trixie), OpenSSH 10.0p1 (version par défaut) À revoir avant septembre 2027

Un serveur SSH exposé sur Internet reçoit des tentatives de connexion en continu, dès la première heure suivant sa mise en ligne. Ce ne sont pas des attaques ciblées : ce sont des robots qui essaient des couples identifiant/mot de passe connus, en boucle, sur toutes les adresses qu'ils trouvent. Tant que le mot de passe est accepté comme moyen d'entrée, il suffit qu'un seul compte ait un secret faible ou déjà fuité.

Ce pas à pas ferme cette porte et restreint qui peut se connecter. Il vise un serveur Linux dont vous avez déjà l'accès administrateur.

En résumé

Un serveur SSH exposé reçoit des tentatives de connexion dès la première heure suivant sa mise en ligne. Tant que le mot de passe est accepté, il suffit qu'un seul compte ait un secret faible ou déjà fuité.
La règle qui évite l'incident : on ne ferme jamais l'authentification par mot de passe avant d'avoir vérifié, depuis un autre terminal, que la connexion par clé fonctionne.
Six réglages comptent : interdire la connexion directe de root, fermer le mot de passe et l'authentification interactive, n'autoriser qu'un groupe nommé, limiter les essais et le délai d'attente, désactiver le renvoi X11.
Passer par un fichier dédié dans sshd_config.d plutôt que d'éditer le fichier principal : les réglages survivent aux mises à jour du paquet et se retirent en supprimant un seul fichier.
Le détail qui coûte des heures : dans la configuration de sshd, c'est la PREMIÈRE occurrence d'un mot-clé qui l'emporte. Si le fichier principal définit un réglage avant la ligne Include, votre fichier dédié sera ignoré.
Le contrôle qui prouve : sshd -T affiche la configuration effective après résolution de tous les fichiers inclus. Ne jamais se fier au contenu d'un fichier.
Le changement de port réduit le bruit dans les journaux, il ne protège de rien : un balayage le trouve en quelques secondes.

Ce qu'il vous faut

Un accès sudo sur le serveur.
Un poste client depuis lequel vous vous connectez habituellement.
Une seconde session SSH ouverte pendant toute l'opération. Ce n'est pas une précaution de confort : c'est ce qui vous évitera de rester dehors si vous vous trompez.

La règle qui évite l'incident

On ne ferme jamais l'authentification par mot de passe avant d'avoir vérifié, depuis un autre terminal, que la connexion par clé fonctionne. L'erreur classique consiste à tout configurer, redémarrer le service, fermer sa session - et découvrir que la clé n'était pas au bon endroit. Sur une machine distante sans accès console, cela se termine par un ticket chez l'hébergeur.

1. Créer une clé, si vous n'en avez pas

Sur votre poste client, pas sur le serveur :

ssh-keygen -t ed25519 -a 100 -C "prenom@poste-de-travail"

ed25519 est l'algorithme à préférer aujourd'hui : clés courtes, rapides, robustes. L'option -a 100 augmente le coût de dérivation de la phrase de passe, ce qui ralentit une attaque hors ligne si le fichier de clé privée vous est volé. Mettez une phrase de passe : une clé privée sans phrase, c'est un mot de passe écrit en clair dans un fichier.

2. Déposer la clé publique sur le serveur

ssh-copy-id -i ~/.ssh/id_ed25519.pub utilisateur@serveur

Puis, depuis un nouveau terminal, vérifiez que la connexion par clé aboutit :

ssh -o PreferredAuthentications=publickey utilisateur@serveur

L'option force l'usage de la clé et interdit le repli sur le mot de passe. Si cette commande vous connecte, la suite est sans risque. Si elle échoue, arrêtez-vous ici et corrigez avant d'aller plus loin.

3. Écrire la configuration dans un fichier dédié

Sur les distributions récentes, /etc/ssh/sshd_config contient une directive Include qui charge les fichiers de /etc/ssh/sshd_config.d/. Passez par là plutôt que d'éditer le fichier principal : vos réglages survivent aux mises à jour du paquet, et se retirent en supprimant un seul fichier.

/etc/ssh/sshd_config.d/99-durcissement.conf

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AllowGroups ssh-users
MaxAuthTries 3
LoginGraceTime 20
X11Forwarding no

Ce que fait chaque ligne, et pourquoi :

PermitRootLogin no - personne ne se connecte directement en root. On passe par un compte nominatif puis sudo, ce qui laisse une trace de qui a fait quoi. C'est aussi le compte que tous les robots essaient en premier.
PasswordAuthentication no et KbdInteractiveAuthentication no - la vraie mesure. La seconde ferme un chemin détourné qui laisse parfois passer une demande de mot de passe alors qu'on croyait l'avoir fermée.
AllowGroups ssh-users - seuls les membres de ce groupe peuvent se connecter. On passe d'une liste d'interdits à une liste d'autorisés : un compte de service créé plus tard par un paquet n'ouvre pas d'accès par accident.
MaxAuthTries 3 et LoginGraceTime 20 - limitent les essais par connexion et le temps d'attente avant authentification. Cela ne remplace pas un outil de bannissement, mais réduit le coût des tentatives en masse.
X11Forwarding no - fonctionnalité rarement utile sur un serveur, et surface d'attaque en moins.

Créez le groupe et ajoutez-y vos comptes avant de recharger, sinon AllowGroups refusera tout le monde :

sudo groupadd -f ssh-users
sudo usermod -aG ssh-users utilisateur

Un détail qui coûte des heures

Dans la configuration de sshd, c'est la première occurrence d'un mot-clé qui l'emporte, pas la dernière. Si le fichier principal définit déjà PasswordAuthentication yes avant la ligne Include, votre fichier dédié sera ignoré. Vérifiez où se trouve l'Include : sur les distributions qui le placent en tête, tout va bien ; ailleurs, il faut modifier le fichier principal.

4. Tester la configuration AVANT de recharger

sudo sshd -t

Cette commande valide la syntaxe sans rien appliquer. Elle ne dit rien en cas de succès. Si elle affiche une erreur, ne rechargez pas - le service refuserait de redémarrer et vous perdriez l'accès.

5. Recharger, sans couper les sessions en cours

sudo systemctl reload ssh

Le nom du service varie : ssh sur les distributions dérivées de Debian, sshd sur celles dérivées de Red Hat. reload est préférable à restart : il applique la nouvelle configuration sans fermer les connexions existantes - dont la vôtre.

6. Vérifier ce qui s'applique réellement

Ne vous fiez pas au contenu du fichier : demandez au service ce qu'il a retenu.

sudo sshd -T | grep -Ei 'permitrootlogin|passwordauthentication|kbdinteractive|allowgroups'

sshd -T affiche la configuration effective, après résolution de tous les fichiers inclus et de l'ordre de priorité. C'est le seul contrôle qui prouve que vos réglages sont bien ceux qui s'appliquent. Puis, depuis un nouveau terminal, confirmez qu'un mot de passe est bien refusé :

ssh -o PreferredAuthentications=password utilisateur@serveur

La connexion doit être rejetée. Si elle aboutit, un réglage n'a pas pris - reprenez le point 3.

Ce que ce durcissement ne fait pas

Il ferme l'entrée la plus utilisée, pas toutes les autres. Restent à traiter : la protection des clés privées sur les postes clients (une clé volée vaut désormais l'accès), le bannissement des adresses insistantes, la journalisation envoyée ailleurs que sur la machine elle-même, et la question de savoir si ce port doit être exposé publiquement plutôt que placé derrière un accès distant contrôlé.

Sur le changement de port, souvent cité : il réduit le bruit dans les journaux, il ne protège de rien. Un balayage de ports le trouve en quelques secondes. À faire éventuellement pour le confort de lecture, jamais comme mesure de sécurité.

Besoin d'aller plus loin

Kenawek durcit les accès distants dans le cadre de missions complètes - inventaire de ce qui est réellement exposé, priorisation, mise en œuvre. Parlons-en.

Durcir un accès SSH exposé : les six réglages qui comptent.