Durcir l'accès SSH sous Linux

SSH est le principal point d'entrée distant de presque tous les serveurs Linux, ce qui en fait la première chose qu'un attaquant sonde et la première que vous devez durcir. L'objectif de ce guide est un serveur qui n'accepte que des clés cryptographiques, n'autorise jamais la connexion directe de root et expose la plus petite surface d'attaque possible.

N'utiliser que l'authentification par clé

Les mots de passe se devinent et se rejouent ; pas les clés. Générez une clé moderne sur votre poste de travail :

ssh-keygen -t ed25519 -a 100 -C "vous@poste"

Copiez la clé publique sur le serveur, puis vérifiez que la connexion fonctionne avant de désactiver les mots de passe :

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@serveur
ssh user@serveur   # confirmez que cela fonctionne sans mot de passe

Verrouiller sshd_config

Modifiez /etc/ssh/sshd_config (ou mieux, un fichier dans /etc/ssh/sshd_config.d/) avec les réglages durcis suivants :

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no
MaxAuthTries 3
LoginGraceTime 20
X11Forwarding no
AllowAgentForwarding no
ClientAliveInterval 300
ClientAliveCountMax 2

Restreignez qui peut se connecter avec une allowlist explicite — cela bloque à lui seul tous les comptes de service et système :

AllowUsers deploy admin

Validez la configuration avant de recharger, pour qu'une faute de frappe ne vous verrouille jamais dehors :

sudo sshd -t && sudo systemctl reload ssh

Restreindre l'échange de clés

Désactivez les algorithmes obsolètes pour qu'une attaque par downgrade ne puisse pas imposer une crypto faible. Sur les OpenSSH récents les valeurs par défaut sont déjà solides, mais les épingler documente l'intention :

KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

Limiter le débit et filtrer

Une authentification durcie reste exposée au bruit du brute force et aux failles 0-day. Placez SSH derrière une allowlist au pare-feu quand c'est possible, et ajoutez fail2ban pour bannir les hôtes qui échouent à répétition. Voir les domaines Réseau & Pare-feu et Détection d'intrusion pour la mise en place complète.

Vérifier votre travail

Après le rechargement, ouvrez un nouveau terminal (gardez votre session actuelle comme secours) et confirmez :

ssh -v user@serveur 2>&1 | grep -i "Authenticated"
sudo grep "sshd" /var/log/auth.log | tail

Vous devez voir la clé acceptée, aucune invite de mot de passe proposée et les connexions root refusées. Avec l'authentification par clé, une allowlist et un pare-feu en amont, SSH cesse d'être la porte d'entrée facile.