Securiser SSH : configuration avancee de sshd_config

Credit : Logo officiel

Securiser SSH : configuration avancee de sshd_config

Dylan D. — Agent Support Technique Serveur SSH 1827 mots 10 min de lecture

Sécuriser SSH : configuration avancée de sshd_config

Quand je provisionne un nouveau VPS chez IONOS, le compteur de tentatives de connexion SSH dépasse 200 dans l'heure qui suit la mise en ligne. Sur un serveur en ligne depuis trois jours sans durcissement, j'ai mesuré 14 000 tentatives sur le port 22, en provenance de 600 IP différentes. C'est la réalité d'Internet en 2026 : les bots scannent en permanence, et la moindre faille dans sshd_config est une invitation.

Voici la configuration que j'applique systématiquement sur Debian 12 avec OpenSSH 9.2. Elle ferme la quasi-totalité des vecteurs d'attaque tout en restant pratique au quotidien.

La règle absolue : ne jamais perdre l'accès

Avant toute modification, je laisse une session SSH ouverte. Toujours. Et je teste les nouveaux paramètres dans une seconde session. Si quelque chose casse, je reste connecté pour réparer. Cette règle m'a sauvé une dizaine de fois.

# Garder cette session ouverte
ssh user@serveur

# Dans un autre terminal, tester la nouvelle config
ssh -p 2222 user@serveur

1. Générer une paire de clés Ed25519

Les clés RSA sont dépassées en 2026. Ed25519 est plus rapide, plus court, plus sûr.

ssh-keygen -t ed25519 -a 100 -C "admin@monsite.fr"

Le -a 100 augmente le nombre de rounds KDF (protection contre une exfiltration de la clé privée). La sortie attendue :

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/admin/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Your identification has been saved in /home/admin/.ssh/id_ed25519
Your public key has been saved in /home/admin/.ssh/id_ed25519.pub

Toujours mettre une passphrase. Si votre laptop est volé, c'est la dernière barrière.

Déployez la clé publique sur le serveur :

ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 22 admin@ip_serveur

Testez la connexion par clé avant de toucher à sshd_config :

ssh -i ~/.ssh/id_ed25519 admin@ip_serveur

2. Durcir sshd_config

Éditez /etc/ssh/sshd_config (sur Debian 12, certaines directives sont dans /etc/ssh/sshd_config.d/ ; je préfère tout centraliser dans le fichier principal).

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
nano /etc/ssh/sshd_config

Voici la configuration complète que j'utilise :

# Port et écoute
Port 2222
AddressFamily inet
ListenAddress 0.0.0.0

# Identités du serveur
HostKey /etc/ssh/ssh_host_ed25519_key

# Authentification
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
PermitEmptyPasswords no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
UsePAM yes

# Restrictions utilisateurs
AllowUsers deployer admin
AllowGroups ssh-users

# Sécurité de session
LoginGraceTime 30
MaxAuthTries 3
MaxSessions 3
MaxStartups 3:30:10
ClientAliveInterval 300
ClientAliveCountMax 2

# Fonctionnalités désactivées
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no
GatewayPorts no
PrintMotd no

# Logging
SyslogFacility AUTH
LogLevel VERBOSE

# Algorithmes modernes uniquement
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,sntrup761x25519-sha512@openssh.com
HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# SFTP
Subsystem sftp /usr/lib/openssh/sftp-server

Validez la syntaxe avant de redémarrer :

sshd -t

Si aucune erreur, redémarrez :

systemctl restart sshd
systemctl status sshd

Dans une seconde fenêtre :

ssh -p 2222 -i ~/.ssh/id_ed25519 deployer@ip_serveur

Si la connexion fonctionne, fermez la première session. Sinon, vous corrigez sans avoir perdu l'accès.

Pourquoi changer le port ?

Le débat fait rage. Mon avis : changer de port n'est pas une mesure de sécurité, c'est une mesure d'hygiène. Les bots scannent prioritairement le port 22. Sur le port 2222 ou 22022, le bruit dans auth.log baisse de 95%. Vous ne devenez pas invisible, mais vous économisez du CPU et facilitez l'analyse des logs.

3. Configurer le pare-feu

UFW est l'outil le plus simple sur Debian. Avant de l'activer, autorisez le nouveau port SSH, sinon vous vous coupez l'accès.

apt install ufw -y
ufw default deny incoming
ufw default allow outgoing
ufw allow 2222/tcp comment 'SSH'
ufw allow 80/tcp comment 'HTTP'
ufw allow 443/tcp comment 'HTTPS'
ufw limit 2222/tcp
ufw enable
ufw status verbose

La directive ufw limit ajoute une règle iptables qui bloque temporairement une IP qui tente plus de 6 connexions en 30 secondes. C'est une première couche avant Fail2ban.

Pour aller plus loin sur iptables, voir Comprendre et configurer iptables sous Linux.

4. Installer Fail2ban

Fail2ban analyse /var/log/auth.log et bannit automatiquement les IP qui multiplient les échecs.

apt install fail2ban -y

Ne modifiez jamais /etc/fail2ban/jail.conf directement (il est écrasé à chaque mise à jour). Créez un override :

nano /etc/fail2ban/jail.local

[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 3
banaction = ufw
ignoreip = 127.0.0.1/8 ::1 203.0.113.50

[sshd]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 86400

L'IP 203.0.113.50 est mon IP fixe maison. Indispensable pour ne jamais se bannir soi-même après une faute de frappe.

systemctl enable fail2ban
systemctl restart fail2ban
fail2ban-client status sshd

Sortie typique après quelques heures :

Status for the jail: sshd
|- Filter
|  |- Currently failed:    2
|  |- Total failed:    412
|  `- File list:    /var/log/auth.log
`- Actions
   |- Currently banned:    18
   |- Total banned:    47
   `- Banned IP list:    91.243.59.X 185.220.101.X ...

Pour Fail2ban en détail, voir Fail2ban : protéger son serveur du brute force.

5. Bannière légale

Une bannière qui s'affiche avant la connexion a une utilité juridique : prouver que l'accès au système était explicitement réservé.

cat > /etc/issue.net << 'EOF'
***************************************************************
ACCES RESTREINT - Toute connexion non autorisee est interdite.
Les activites sont enregistrees et peuvent etre poursuivies
en application de l'article 323-1 du Code penal.
***************************************************************
EOF

Dans sshd_config :

Banner /etc/issue.net

6. Authentification à deux facteurs avec TOTP

Clé SSH + TOTP, c'est la ceinture et les bretelles. Un attaquant qui vole votre clé privée et la passphrase est encore bloqué par le code à 6 chiffres.

apt install libpam-google-authenticator -y
su - deployer
google-authenticator -t -d -r 3 -R 30 -W

Le QR code s'affiche dans le terminal : scannez-le avec Authy, Aegis ou Google Authenticator.

Dans /etc/pam.d/sshd, ajoutez en haut :

auth required pam_google_authenticator.so nullok

Dans /etc/ssh/sshd_config :

KbdInteractiveAuthentication yes
AuthenticationMethods publickey,keyboard-interactive

systemctl restart sshd

7. Surveiller les connexions

# Dernières connexions réussies
last -aiF | head -20

# Tentatives échouées
journalctl -u ssh.service | grep -i "failed\|invalid" | tail -20

# Connexions actives
ss -tnp | grep :2222

# IP bannies
fail2ban-client status sshd

# Statistiques mensuelles
grep "Accepted" /var/log/auth.log | awk '{print $1,$2}' | sort | uniq -c

Pour creuser les logs, voir Logs Linux : où chercher, comment lire.

8. Cas avancés : Match et chroot SFTP

La directive Match permet d'appliquer des règles différentes selon l'utilisateur ou l'IP. Cas typique : un utilisateur SFTP-only enfermé dans un chroot.

Match User backups
    PasswordAuthentication no
    ChrootDirectory /srv/sftp/%u
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no

Préparez le chroot :

mkdir -p /srv/sftp/backups/data
chown root:root /srv/sftp/backups
chmod 755 /srv/sftp/backups
chown backups:backups /srv/sftp/backups/data

Le répertoire racine du chroot doit appartenir à root et avoir les permissions 755, sinon SSH refuse la connexion avec une erreur cryptique.

Autre cas utile : autoriser les mots de passe uniquement depuis votre IP fixe.

Match Address 203.0.113.50
    PasswordAuthentication yes

9. Audit de configuration

Un outil que j'utilise systématiquement après chaque modification : ssh-audit.

pip install ssh-audit
ssh-audit -p 2222 monsite.fr

La sortie classe les algorithmes en trois catégories : (info), (warn), (fail). L'objectif est zéro fail et zéro warn. Avec la configuration ci-dessus, j'obtiens un score parfait.

Extrait de sortie idéale :

# general
(gen) banner: SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u3
(gen) compatibility: OpenSSH 7.3+, Dropbear SSH 2020.79+
(gen) compression: enabled (zlib@openssh.com)

# key exchange algorithms
(kex) curve25519-sha256                       -- [info] available since OpenSSH 7.4
(kex) sntrup761x25519-sha512@openssh.com      -- [info] hybrid post-quantum

10. Bonnes pratiques côté client

Les failles côté serveur sont parfois compensées par des failles côté client. Quelques règles à suivre :

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 644 ~/.ssh/known_hosts
chmod 600 ~/.ssh/config

Côté client, simplifiez vos connexions avec ~/.ssh/config :

Host prod-ionos
    HostName 203.0.113.10
    Port 2222
    User deployer
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes
    ServerAliveInterval 60
    AddKeysToAgent yes

Un simple ssh prod-ionos suffit ensuite. Détails complets dans SSH config : simplifier ses connexions.

Erreurs courantes et leur fix

Permission denied (publickey)

Cause : la clé publique n'est pas dans ~/.ssh/authorized_keys, ou les permissions sont mauvaises.

Solution :

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R deployer:deployer ~/.ssh

Vérifiez aussi que PubkeyAuthentication yes est bien actif (grep -i pubkey /etc/ssh/sshd_config).

Connection refused on port 2222

Cause : le port n'est pas ouvert dans le firewall ou sshd n'écoute pas dessus.

Solution :

ss -tlnp | grep 2222
ufw status | grep 2222

Si ss ne montre rien, vérifiez Port 2222 dans sshd_config et redémarrez le service.

Too many authentication failures

Cause : votre agent SSH propose trop de clés avant la bonne. Le serveur coupe à MaxAuthTries.

Solution : ajoutez IdentitiesOnly yes dans votre ~/.ssh/config côté client, ou utilisez ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519.

sshd: error: kex_exchange_identification: client sent invalid protocol identifier

Cause : un scanner ou un client incompatible se connecte. Habituellement bénin.

Solution : si le bruit est massif, restreignez via AllowUsers et utilisez Fail2ban.

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED

Cause : la clé hôte du serveur a changé (réinstallation OS, ou attaque MITM).

Solution : si vous savez que c'est légitime, ssh-keygen -R [serveur]:2222. Sinon, n'allez pas plus loin.

Pour aller plus loin

Bonus : rotation automatique des clés hôtes

Les clés hôtes du serveur doivent rester stables, mais en cas de compromission soupçonnée, voici comment les régénérer proprement :

rm /etc/ssh/ssh_host_*
ssh-keygen -A
systemctl restart sshd

Vos clients verront une alerte de changement d'hôte. Ils devront mettre à jour leur known_hosts :

ssh-keygen -R "[monsite.fr]:2222"

Le SSH bien configuré, c'est 95% du travail

Une configuration SSH durcie repose sur cinq piliers : clés Ed25519 uniquement, port non standard, restriction d'utilisateurs, firewall actif et détection d'intrusion. Sur tous les VPS IONOS que je gère, cette base couvre l'essentiel des menaces. Le 2FA reste optionnel pour les serveurs de production critiques. Et surtout : gardez toujours une session ouverte pendant les changements. Trois minutes de paranoïa valent mieux qu'une journée à reprovisionner un serveur.

# Articles similaires

Sur les memes sujets et plus loin