Comment sécuriser le protocole SSH sur votre serveur Linux en 2026 — 15 étapes essentielles

Votre port SSH est actuellement ouvert. Chaque seconde, des bots parcourent Internet pour tenter de s'y introduire par force brute. Si vous n'avez pas renforcé la sécurité de votre configuration SSH, vous offrez une vulnérabilité extrême. Ce guide vous présente 15 étapes essentielles pour sécuriser le port SSH de votre serveur Linux en 2026 : pratiques, éprouvées et classées par ordre d'importance.

Pourquoi le renforcement de la sécurité SSH reste important en 2026

Le protocole SSH demeure la principale méthode d'accès à distance aux serveurs Linux dans le monde. Malgré l'essor des architectures « zéro confiance » et des modèles d'accès basés uniquement sur un VPN, SSH reste vulnérable sur des millions de machines. Les attaquants le savent. Des outils comme Shodan indexent les ports SSH ouverts en quelques secondes, et des bots automatisés effectuent des milliers de tentatives de connexion par heure sur les configurations par défaut.

Quelques modifications de configuration peuvent réduire votre surface d'attaque de plus de 90 %. Faisons-le correctement.

Étape 1 : Modifier le port SSH par défaut

Le port par défaut 22 est le premier que les scanners vérifient. Utiliser un port non standard pour le SSH (par exemple, 2222 ou 49222) n'arrêtera pas un attaquant déterminé, mais éliminera 99 % des tentatives automatisées.

# /etc/ssh/sshd_config
Port 49222

N'oubliez pas de mettre à jour les règles de votre pare-feu et de vous reconnecter sur le nouveau port.

Étape 2 : Désactiver la connexion root

N'autorisez jamais la connexion directe en tant que root via SSH. Créez un compte utilisateur standard et utilisez sudo pour les tâches privilégiées.

PermitRootLogin no

Étape 3 : Utiliser uniquement l’authentification par clé SSH

Les mots de passe peuvent être piratés par force brute. Les clés SSH, en revanche, ne le peuvent pas (pratiquement). Générez une paire de clés robuste et désactivez complètement l'authentification par mot de passe.

ssh-keygen -t ed25519 -C "your_email@example.com"

# sshd_config
PasswordAuthentication no
PubkeyAuthentication yes

Étape 4 : Utiliser des clés Ed25519 (et non RSA)

Ed25519 est plus rapide, plus compact et plus sûr que RSA-2048. Si vous utilisez encore RSA, migrez vers les clés Ed25519 pour tous les utilisateurs.

Étape 5 : Restreindre l’accès SSH à des utilisateurs spécifiques

Utilisez la directive AllowUsers pour n'autoriser que les utilisateurs qui ont besoin d'un accès SSH.

AllowUsers deploy monitoring

Étape 6 : Configurer le délai d’inactivité

Déconnexion automatique des sessions inactives afin de réduire le risque de piratage des terminaux.

ClientAliveInterval 300
ClientAliveCountMax 2

Cela déconnecte les sessions inactives après 10 minutes (300 s × 2).

Étape 7 : Limiter les tentatives d’authentification

MaxAuthTries 3
MaxSessions 5

Après trois tentatives infructueuses, la connexion est interrompue. Cela ralentit considérablement les attaques par force brute.

Étape 8 : Désactiver les mots de passe vides

PermitEmptyPasswords no

Cette option devrait être désactivée par défaut, mais vérifiez-la explicitement.

Étape 9 : Désactiver le transfert X11

Sauf si vous avez spécifiquement besoin du transfert d'interface graphique, désactivez-le afin de réduire la surface d'attaque.

X11Forwarding no

Étape 10 : Utiliser Fail2Ban

Fail2Ban surveille les fichiers journaux et bloque automatiquement les adresses IP présentant un comportement malveillant (comme des échecs de connexion répétés).

apt install fail2ban
# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = 49222
maxretry = 3
bantime = 3600

Étape 11 : Restreindre l’accès SSH à l’aide d’un pare-feu

Autoriser uniquement les connexions SSH provenant de plages d'adresses IP connues, en utilisant UFW ou iptables.

ufw allow from 203.0.113.0/24 to any port 49222
ufw deny 49222

Étape 12 : Utiliser l’authentification à deux facteurs (2FA)

Ajoutez Google Authenticator ou une application TOTP comme deuxième facteur d'authentification pour les connexions SSH.

apt install libpam-google-authenticator

Configurez ensuite PAM et sshd_config pour exiger à la fois une clé et un code OTP. Il s'agit de la norme de référence pour 2026.

Étape 13 : Désactiver le protocole version 1

SSHv1 est obsolète et défectueux. Les systèmes modernes ne prennent en charge que SSHv2 par défaut, mais il est tout de même conseillé de vérifier.

Protocol 2

Étape 14 : Définir une configuration de chiffrement stricte

Imposer des chiffrements et des MAC modernes et sécurisés :

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

Étape 15 : Surveiller activement les journaux SSH

Activez la journalisation détaillée et acheminez les événements SSH vers votre SIEM ou votre pile de surveillance (Netdata, Grafana, ELK).

LogLevel VERBOSE

Vérifiez régulièrement les blocs de code /var/log/auth.log ou /var/log/secure pour détecter les anomalies.

Bonus : Appliquer la configuration complète

Après chaque modification, testez toujours votre nouvelle configuration avant de redémarrer :

sshd -t  # Test configuration
systemctl reload ssh

Gardez une session active ouverte pendant vos tests pour éviter de vous bloquer l'accès !

Réflexions finales

Le renforcement de la sécurité SSH n'est pas une tâche ponctuelle, mais une pratique continue. Revoyez votre configuration tous les trimestres, changez vos clés annuellement et surveillez les journaux en permanence. Combinez ces mesures avec des contrôles au niveau du réseau (VPN, listes blanches du pare-feu) pour une défense en profondeur.

🔒 Prêt à renforcer la sécurité de votre serveur ? Consultez nos autres articles sur RootPilot consacrés au Zero Trust, à la configuration VPN et à la surveillance des serveurs. Des questions ? N’hésitez pas à les poser dans les commentaires ci-dessous ; nous les lisons tous.