7 min read Advanced 6.8k

SSH Hardening avancé : Ed25519, 2FA et port knocking

Published on May 17, 2026 at 11:51 AM

Sécurisez votre accès SSH au-delà du simple changement de port. Ce guide couvre les clés Ed25519 (plus sûres et plus rapides que RSA), l'authentification 2FA TOTP, le port knocking et les bonnes pratiques de durcissement avancé.

Introduction

SSH est la porte d'entrée principale de votre VPS. Un mot de passe, même fort, n'est plus suffisant en 2025 : les bots brute-force constants, les fuites de credentials et l'augmentation de la puissance de calcul rendent toute authentification par mot de passe obsolète.

Ce tuto va au-delà du simple "changer le port et désactiver root" : on construit une authentification SSH avec :

Clés Ed25519 (algorithme moderne)
2FA via TOTP (Google Authenticator)
Port knocking (le port SSH n'est ouvert qu'après séquence secrète)
Limitation par IP + Match groups

Prérequis

VPS Linux avec SSH installé
Accès root ou sudo
Une seconde session SSH ouverte pour ne pas vous verrouiller pendant les tests
Une app TOTP (Google Authenticator, Authy, Bitwarden, etc.)

Étape 1 : Backup de la config SSH actuelle

Crucial : avant de toucher à quoi que ce soit, sauvegardez :

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Et ouvrez une seconde session SSH en parallèle, que vous laissez ouverte. Si vous vous verrouillez, vous gardez un accès.

Étape 2 : Générer une clé Ed25519

Ed25519 remplace RSA : plus sûr, plus rapide, clés plus courtes. Sur votre machine locale (pas le VPS) :

ssh-keygen -t ed25519 -C "[email protected]"

Pressez Entrée pour le chemin par défaut, et mettez une passphrase (renforce la sécurité de la clé privée).

Deux fichiers sont créés :

~/.ssh/id_ed25519 (clé privée — ne jamais partager)
~/.ssh/id_ed25519.pub (clé publique — à copier sur le serveur)

Étape 3 : Copier la clé publique sur le VPS

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@IP_DU_VPS

Ou manuellement :

cat ~/.ssh/id_ed25519.pub | ssh user@IP_DU_VPS "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Testez la connexion par clé :

ssh -i ~/.ssh/id_ed25519 user@IP_DU_VPS

Vous devez vous connecter sans mot de passe (juste la passphrase de la clé locale).

Étape 4 : Désactiver l'authentification par mot de passe

⚠️ Faites cette étape uniquement une fois la clé testée ET avec une seconde session ouverte.

sudo nano /etc/ssh/sshd_config

Modifiez ou ajoutez :

# Désactiver le mot de passe
PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no

# Désactiver login root
PermitRootLogin no

# Forcer protocole 2 (déjà par défaut)
Protocol 2

# Algorithmes modernes uniquement
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256
KexAlgorithms [email protected],curve25519-sha256,diffie-hellman-group16-sha512
Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr
MACs [email protected],[email protected],[email protected]

# Limites
MaxAuthTries 3
MaxSessions 5
LoginGraceTime 30

# Désactiver X11 (rarement nécessaire sur un serveur)
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no

# Logs
LogLevel VERBOSE

Testez la config :

sudo sshd -t

Pas d'erreur ? Rechargez :

sudo systemctl reload sshd

Testez depuis votre seconde session ou ouvrez-en une troisième pour valider.

Étape 5 : Changer le port SSH (optionnel mais recommandé)

Le port 22 reçoit 99% des brute-force. Changer le port casse 99% du bruit (security by obscurity, ne remplace pas le hardening).

sudo nano /etc/ssh/sshd_config

Port 22022

Ouvrez le nouveau port :

sudo ufw allow 22022/tcp

Côté Netrix VeryCloud, autorisez aussi le port custom.

Rechargez :

sudo systemctl reload sshd

Désormais connectez-vous avec :

ssh -i ~/.ssh/id_ed25519 -p 22022 user@IP_DU_VPS

Pour simplifier, ajoutez dans ~/.ssh/config local :

Host monvps
    HostName IP_DU_VPS
    Port 22022
    User user
    IdentityFile ~/.ssh/id_ed25519

Connexion : ssh monvps.

Étape 6 : Ajouter le 2FA TOTP

Installation :

sudo apt install -y libpam-google-authenticator

Sur le user concerné (pas root) :

google-authenticator

Répondez :

Time-based tokens : y
Update ~/.google_authenticator : y
Disallow multiple uses : y
Increase time window : n
Rate limit : y

Un QR code s'affiche. Scannez-le avec votre app TOTP (Google Authenticator, Authy, Bitwarden).

Notez les codes de secours affichés : si vous perdez votre téléphone, ce sont vos seuls moyens de vous reconnecter.

Étape 7 : Configurer PAM pour 2FA SSH

sudo nano /etc/pam.d/sshd

En haut du fichier (avant @include common-auth) :

auth required pam_google_authenticator.so

Puis :

sudo nano /etc/ssh/sshd_config

Ajoutez/modifiez :

UsePAM yes
AuthenticationMethods publickey,keyboard-interactive
ChallengeResponseAuthentication yes
KbdInteractiveAuthentication yes

⚠️ AuthenticationMethods publickey,keyboard-interactive force clé SSH ET 2FA (deux méthodes obligatoires).

Rechargez :

sudo systemctl reload sshd

Testez : la connexion demande maintenant clé + code TOTP. Parfait.

Étape 8 : Port knocking (avancé)

Le port knocking masque complètement le port SSH : il est fermé en permanence et ne s'ouvre que pour votre IP après une séquence de "knocks" sur des ports prédéfinis.

sudo apt install -y knockd

Configurez :

sudo nano /etc/knockd.conf

[options]
    UseSyslog

[openSSH]
    sequence    = 7000,8000,9000
    seq_timeout = 5
    command     = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 22022 -j ACCEPT
    tcpflags    = syn

[closeSSH]
    sequence    = 9000,8000,7000
    seq_timeout = 5
    command     = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22022 -j ACCEPT
    tcpflags    = syn

Activez knockd :

sudo nano /etc/default/knockd

START_KNOCKD=1

sudo systemctl enable --now knockd

Côté pare-feu, fermez le port SSH par défaut :

sudo ufw deny 22022/tcp

Maintenant, pour vous connecter (depuis votre machine locale) :

# Installer knock côté client (Linux : apt install knockd, macOS : brew install knock)

# Knock
knock IP_DU_VPS 7000 8000 9000

# Puis SSH
ssh monvps

Pour fermer : knock IP_DU_VPS 9000 8000 7000.

Étape 9 : Restrictions par groupe et IP

Ajoutez à sshd_config :

# Seul le groupe ssh-users peut se connecter
AllowGroups ssh-users

# Whitelist IP pour un user spécifique
Match User admin
    AllowUsers [email protected]

Créez le groupe :

sudo groupadd ssh-users
sudo usermod -aG ssh-users votre_user

Étape 10 : Limiter les tentatives par IP avec ufw

UFW peut limiter les connexions SSH (anti brute-force complémentaire à Fail2ban / CrowdSec) :

sudo ufw limit 22022/tcp

Limite à 6 connexions par 30 secondes par IP. Au-delà, blocage temporaire.

Étape 11 : Auditer la config

sudo apt install -y ssh-audit
ssh-audit localhost -p 22022

L'outil vérifie tous les algorithmes négociés et donne un grade. Objectif : avoir tout en vert.

Dépannage

Verrouillé hors du VPS

Si vous avez gardé une session ouverte, restaurez :

sudo cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config
sudo systemctl reload sshd

Sinon, utilisez le noVNC de l'espace client VeryCloud (la console KVM ne passe pas par SSH).

"Permission denied (publickey)"

Vérifiez :

ls -la ~/.ssh/

Permissions attendues :

drwx------ ~/.ssh
-rw------- ~/.ssh/authorized_keys
-rw------- ~/.ssh/id_ed25519
-rw-r--r-- ~/.ssh/id_ed25519.pub

Si problème :

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

2FA bloque trop souvent

Si l'horloge du VPS est désynchronisée, le code TOTP est invalide :

sudo apt install -y chrony
sudo systemctl enable --now chrony

Commandes utiles

# Tester la config SSH
sudo sshd -t

# Recharger sshd
sudo systemctl reload sshd

# Voir les sessions actives
who
w
last -10

# Voir les tentatives échouées
sudo journalctl -u ssh | grep -i "failed\|invalid"

# Audit SSH
ssh-audit localhost -p 22022

# Désactiver une clé temporairement
mv ~/.ssh/authorized_keys ~/.ssh/authorized_keys.disabled

# Voir les peers TOTP enrôlés
ls -la /home/*/.google_authenticator

Conclusion

Votre SSH est maintenant verrouillé à plusieurs couches :

✅ Clé Ed25519 (cryptographie moderne)
✅ Mot de passe désactivé
✅ Port non-standard
✅ 2FA TOTP obligatoire
✅ Port knocking (port fermé sauf séquence)
✅ Restrictions par groupe/IP
✅ Rate limiting UFW

Même si un attaquant trouve la clé privée, il lui manque le 2FA. Même s'il a tout, le port est masqué par le knocking.

Pour aller plus loin :

Combinez avec CrowdSec ou Fail2ban (ban automatique des IPs malveillantes)
Utilisez un bastion dédié si vous avez plusieurs VPS
Mettez en place des SSH certificate authorities pour de la rotation de clés à grande échelle

Ressources

ssh-audit : https://github.com/jtesta/ssh-audit
Mozilla SSH Guidelines : https://infosec.mozilla.org/guidelines/openssh
Tuto VeryCloud — Configuration clé SSH de base : https://verycloud.fr/docs/article/configure-sshkey-linux