La forteresse SSH : Configurer son accès distant.

Ca 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ésitez pas à me contacter, je mettrai l’article à jour si vos tips me semble pertinant.

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 (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 votre 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. (si c’est pas le cas, tu fais quoi ici ?)
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 : Creation 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 definir le nom de la clé dans mon exemple ~/.ssh/id_ed25519_vps

tu peux ajouter une passphrase elle te serra demander a 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.

le clé se trouve dans ton home dans le 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 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	Si ClientAliveCountMax est activé, ferme la connexion après 3 requêtes sans réponse.
ClientAliveInterval	60	Si le mec ne s’est pas logué en 60 secondes, ciao.

 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 : 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 ficher /etc/ssh/sshd_config.d/ciphers.conf il faut le créer si il n’existe pas

 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 https://ssh-audit.com/ pour voir ta note.

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

“Tu as redémarré le service et tu ne peux plus rentrer ? Pas de panique (enfin, un peu quand même).”

Symptôme : Connection refused. Cause : Tu as oublié d’ouvrir le nouveau port (2222) dans ton pare-feu ! Fix : Verifi chez ton hebergeur ils ont surement une doc il faut que tu 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 chargeront de bannir automatiquement les IPs des petits malins qui insisteraient un peu trop, on le ferra surment dans un autre tuto.

Si tu as d’autre recomendation envois moi un mail ou un pouet sur Mastodon.