La forteresse SSH : Configurer son accès distant

Fri, 26 Dec 2025 11:47:00 +0100

Ça fait plusieurs années que j’ai un serveur avec un OpenSSH exposé sur internet, et les premières fois quand je suis allé voir dans les logs, j’ai halluciné devant le nombre de tentatives de connexion. Et oui, il y a des bots sur le net qui passent leur temps à faire du brute-force sur les ports SSH. C’est pour ça que je te propose un petit tuto où je vais t’exposer ma configuration SSH. Je ne suis pas professionnel, mais je pense que c’est le minimum. Si tu as d’autres tips, n’hésite pas à me contacter, je mettrai l’article à jour si tes tips me semblent pertinents.

Pourquoi OpenSSH

Quand on travaille sur un serveur à distance, on a besoin de l’administrer. En général, sur un serveur avec un OS qui mérite de porter ce nom, on peut faire tourner un serveur SSH.

Grâce au serveur SSH, tu pourras te connecter au terminal du serveur distant : cela permet d’administrer le serveur.

La configuration par défaut du serveur SSH installé par défaut sur le serveur Debian 13 (stable depuis le 15 novembre 2025, avec OpenSSH) peut être durcie.

Les mises à jour

Première mesure de sécurité : il faut mettre à jour régulièrement le serveur OpenSSH. C’est l’un des serveurs les plus utilisés, ce qui en fait une cible privilégiée pour les attaquants.

Récemment, plusieurs vulnérabilités ont été découvertes :

CVE-2025-26465 : Cette vulnérabilité permet à un attaquant d’usurper l’identité, ce qui peut conduire à des attaques de type homme-du-milieu. La mise à jour vers la version 9.9p2 a permis de résoudre ce problème.

CVE-2025-26466 : Une faille dans sshd expose OpenSSH à une attaque par déni de service (DoS). La mise à jour vers la version 9.9p2 a permis de résoudre ce problème.

CVE-2024-6387 (RegreSSHion) : Cette vulnérabilité critique, signalée le 1er juillet 2024, affecte les systèmes Linux basés sur glibc et permet l’exécution de code à distance (RCE) non authentifiée en tant que root. La mise à jour vers la version 9.8p1 a corrigé cette vulnérabilité.

Ces exemples illustrent qu’il faut maintenir OpenSSH à jour pour se protéger contre des vulnérabilités critiques. Négliger les mises à jour expose ton infrastructure à des risques majeurs. Il est donc recommandé de surveiller régulièrement les annonces de sécurité et d’appliquer les correctifs dès leur disponibilité.

Les prérequis

Un serveur sous Linux (Debian, Ubuntu, Rocky…) ou OpenBSD.
Un accès root ou sudo sur ce serveur.
Un client SSH sur ton PC (Linux, Mac ou Windows avec WSL/PuTTY).

Avertissement

Exposer un serveur sur Internet n’est jamais anodin. Une mauvaise configuration, c’est la porte ouverte aux bots, aux scripts malveillants et aux maux de tête.

Note bien ceci : Toutes les infos que je vais te transmettre sont basées sur mes configurations personnelles. Je suis un passionné, pas un expert certifié en cybersécurité. Prends ça comme un partage d’expérience, pas comme un audit blindé par l’ANSSI !

Étape 1 : Création d’une clé SSH

Si tu te logues encore avec un mot de passe classique password1234, arrête tout. On va passer aux clés cryptographiques. C’est beaucoup plus robuste.

Sur ton PC local (pas le serveur), ouvre ton terminal préféré et lance :

1

ssh-keygen -t ed25519 -C "jon@doe.fr"

Note : On utilise l’algo ed25519 car il est plus moderne, plus rapide et plus sûr que le vieux RSA.

Tu peux définir le nom de la clé, dans mon exemple ~/.ssh/id_ed25519_vps

Tu peux ajouter une passphrase, elle te sera demandée à chaque utilisation

Info

Mets une passphrase ! Si on te vole ton PC portable non verrouillé, ta clé privée sera compromise. Avec une passphrase, le voleur ne pourra rien en faire.

La clé se trouve dans ton dossier home, dans le sous-dossier .ssh.

Une fois générée, ta clé est dans le dossier .ssh de ton dossier personnel. Il faut maintenant envoyer la partie « publique » sur ton serveur :

1

ssh-copy-id -i ~/.ssh/id_ed25519_vps.pub user@ip-du-serveur

Étape 2 : Configuration d’OpenSSH

Maintenant que ta clé est en place, on passe aux choses sérieuses sur le serveur. Le fichier de config se trouve dans /etc/ssh/sshd_config.

Tu peux l’ouvrir avec ton éditeur favori : vim pour les Jedi, nano pour les Padawans.

Voici les paramètres à changer ou ajouter :

Paramètre	Valeur recommandée	Explication
`PermitRootLogin`	`no`	Indispensable. On ne se connecte jamais directement en root. Tu te connectes avec ton user, puis tu fais `sudo`.
`PasswordAuthentication`	`no`	On désactive les mots de passe. Clés SSH obligatoires !
`Port`	`2222`	Changer le port 22 par défaut réduit considérablement le bruit dans les logs (les bots tapent surtout le 22). Ce n’est pas de la « vraie » sécurité, mais ça soulage.
`PubkeyAuthentication`	`yes`	Assure que l’authentification par clé est active.
`ChallengeResponseAuthentication`	`no` (optionnel selon distro)	Désactive PAM pour limiter l’auth via password.
`AllowAgentForwarding`	`no`	Bloque le relais d’agent (sauf si tu sais exactement pourquoi tu en as besoin).
`PermitTunnel`	`no`	Désactive la possibilité de créer des tunnels réseau via SSH pour limiter les abus.
`X11Forwarding`	`no`	Pas de transfert d’interface graphique (inutile sur un serveur et vecteur d’attaque).
`MaxAuthTries`	`3`	Au bout de 3 essais ratés, on coupe. Pas de temps à perdre.
`ClientAliveCountMax`	`3`	Ferme la connexion après 3 requêtes sans réponse.
`ClientAliveInterval`	`60`	Si la connexion reste sans réponse pendant 60 secondes, elle est coupée.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# --- Sécurisation OpenSSH by Midiland ---

# Port personnalisé
Port 2222

# Authentification
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no

# Restrictions de forwarding
AllowAgentForwarding no
PermitTunnel no
X11Forwarding no

# Tentatives & timeout
MaxAuthTries 3
ClientAliveInterval 60
ClientAliveCountMax 3

Vérification et application

Avant de relancer le service, on vérifie toujours (au risque de tout casser) que la syntaxe est bonne :

1

sudo sshd -t

Si la commande ne renvoie rien, c’est gagné. Si elle râle, corrige les erreurs indiquées.

Ensuite, on redémarre le service :

1

sudo systemctl restart sshd

Attention

Ne ferme JAMAIS ta session SSH actuelle après avoir redémarré le service SSH. Ouvre un nouveau terminal et essaie de te connecter avec ta nouvelle config (nouveau port, clé SSH).

Commande de test :

1

ssh -i ~/.ssh/id_ed25519 -p 2222 user@ip-du-serveur

Si ça marche, bravo ! Si ça échoue, tu as toujours ta première fenêtre ouverte pour corriger le tir sans t’être enfermé dehors.

Configuration des Ciphers et algorithmes pour OpenSSH

Pour ceux qui veulent la ceinture et les bretelles, on peut forcer OpenSSH à n’utiliser que des algorithmes de chiffrement ultra-robustes et récents.

Attention : Cette config peut bloquer la connexion depuis de très vieux clients SSH.

Dans le fichier /etc/ssh/sshd_config.d/ciphers.conf, il faut le créer s’il n’existe pas.

Ce bloc restreint les algorithmes autorisés aux plus modernes et sûrs, selon les recommandations de ssh-audit.com :

KexAlgorithms : échanges de clés (Key Exchange) — on garde les courbes elliptiques récentes (Curve25519, sntrup761) et les groupes Diffie-Hellman solides.
Ciphers : algorithmes de chiffrement symétrique — ChaCha20-Poly1305 et AES en mode GCM/CTR uniquement.
MACs : codes d’authentification de message — HMAC-SHA2 et UMAC en mode « encrypt-then-MAC » (-etm).
HostKeyAlgorithms et PubkeyAcceptedAlgorithms : types de clés de serveur et de client acceptés — Ed25519 en priorité, RSA 3072 bits minimum.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


# Restrict key exchange, cipher, and MAC algorithms, as per sshaudit.com
# hardening guide.
KexAlgorithms sntrup761x25519-sha512,sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,gss-curve25519-sha256-,diffie-hellman-group16-sha512,gss-group16-sha512-,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha256

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-gcm@openssh.com,aes128-ctr

MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com

HostKeyAlgorithms sk-ssh-ed25519-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256

RequiredRSASize 3072

CASignatureAlgorithms sk-ssh-ed25519@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256

GSSAPIKexAlgorithms gss-curve25519-sha256-,gss-group16-sha512-

HostbasedAcceptedAlgorithms sk-ssh-ed25519-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,ssh-ed25519,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256-cert-v01@openssh.com,rsa-sha2-256

PubkeyAcceptedAlgorithms sk-ssh-ed25519-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,ssh-ed25519,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256-cert-v01@openssh.com,rsa-sha2-256

Un petit redémarrage :

1

sudo systemctl restart sshd

Tu peux même aller frimer en testant ton serveur sur ssh-audit.com pour voir ta note.

Dépannage (Oups, je suis bloqué !)

Tu as redémarré le service et tu ne peux plus te connecter ?

Pas de panique (enfin, un peu quand même).

→ Vérifie ton pare-feu : tu as oublié d’ouvrir le nouveau port (2222) ! Chez ton hébergeur, autorise le port 2222/tcp.

Conclusion

Et voilà ! Tu as maintenant un serveur OpenSSH aux petits oignons. La surface d’attaque est réduite drastiquement : plus de mot de passe, plus de root direct, port changé et crypto renforcée. Les bots vont se casser les dents dessus.

C’est une première étape essentielle. Pour aller plus loin, je te conseille d’installer Fail2Ban qui se chargera de bannir automatiquement les IPs des petits malins qui insisteraient un peu trop, on le fera sûrement dans un autre tuto.

Si tu as d’autres recommandations, envoie-moi un mail ou un pouet sur Mastodon.

Sécurité on Blog de Midiland

La forteresse SSH : Configurer son accès distant

Pourquoi OpenSSH

Les mises à jour

Les prérequis

Étape 1 : Création d’une clé SSH

Étape 2 : Configuration d’OpenSSH

Vérification et application

Configuration des Ciphers et algorithmes pour OpenSSH

Dépannage (Oups, je suis bloqué !)

Conclusion