VPS SSH hardening complet : tutoriel 2026

📍 Article principal du cluster : VPS hardening sécurité 2026 : guide complet
Cet article fait partie du cluster « Sécurité VPS Linux ». Pour la vue d’ensemble, lire d’abord le pilier.

Introduction

Un hôtel boutique de Saint-Louis vient de mettre en ligne son VPS Hetzner pour son nouveau site de réservation directe. Trois jours après ouverture du port 22 sur Internet, les logs /var/log/auth.log affichent plus de 10 000 tentatives d’authentification SSH par jour, dont 90 % depuis des botnets russes, chinois et ukrainiens cherchant des comptes root, admin, ubuntu avec mots de passe faibles. Trois semaines plus tard, sans surveillance, l’un de ces botnets aurait fini par trouver une combinaison qui marche — l’incident moyen sur un VPS non durci se mesure en jours, parfois en heures.

Après application du hardening SSH décrit ci-dessous, les tentatives d’authentification réussies non autorisées sont passées à zéro et les tentatives totales ont été divisées par 100 (l’attaquant abandonne après quelques échecs sur des algorithmes refusés). Ce tutoriel détaille la configuration SSH OpenSSH 9+ recommandée en 2026 pour un VPS Linux exposé : utilisateur dédié sudoers, authentification par clés Ed25519 exclusive, désactivation root, restriction d’algorithmes cryptographiques aux suites modernes, restrictions d’accès par utilisateur, et tests de validation. La méthode est applicable sur Debian 12, Ubuntu 22.04/24.04 LTS, Rocky Linux 9, AlmaLinux 9, et toutes les distributions modernes utilisant openssh-server.

Prérequis

• VPS Linux récent (kernel ≥ 5.10), distribution maintenue (Debian 12, Ubuntu 22.04/24.04 LTS, Rocky/Alma 9)
• OpenSSH 8.0 minimum (vérifier avec ssh -V côté serveur), idéalement 9.0+
• Accès root initial via mot de passe ou clé fournie par l’hébergeur
• Crucial : accès à une console KVM ou un mode rescue chez l’hébergeur (Hetzner Cloud Console, OVH IPMI, Contabo VNC) au cas où une mauvaise configuration SSH bloquerait l’accès distant
• Un poste local avec OpenSSH client (Linux, macOS, Windows 10+ avec OpenSSH intégré, ou WSL)
• Niveau attendu : intermédiaire (compréhension de base de Linux et de SSH)
• Temps estimé : 30 à 45 minutes

Étape 1 — Créer un utilisateur dédié avec sudo

Se connecter directement en root depuis Internet est la première erreur à corriger. Tout VPS exposé doit utiliser un utilisateur applicatif dédié pour les connexions interactives, et n’élever ses privilèges que ponctuellement via sudo. Cela limite la portée d’une compromission, simplifie l’audit dans les logs (chaque action sudo est tracée avec le nom d’utilisateur réel), et permet de désactiver complètement la connexion root à distance par la suite.

# Connexion initiale en root depuis votre machine locale
ssh root@VOTRE_IP_VPS

# Création de l'utilisateur dédié (remplacer "deploy" par le nom voulu)
adduser deploy

# Ajout au groupe sudo (Debian/Ubuntu)
usermod -aG sudo deploy

# Sur Rocky/AlmaLinux, le groupe est "wheel"
# usermod -aG wheel deploy

# Vérifier que sudo fonctionne pour le nouvel utilisateur
su - deploy
sudo whoami   # doit retourner "root" après saisie du mot de passe deploy

L’utilisateur deploy peut maintenant se connecter et exécuter des commandes root via sudo. Le mot de passe demandé est celui de deploy (pas celui de root). Si sudo whoami renvoie une erreur du type « deploy n’est pas dans les sudoers », c’est que l’ajout au groupe n’a pas été pris en compte — il faut se déconnecter et reconnecter via su - deploy pour que le shell rafraîchisse les groupes effectifs.

Étape 2 — Mettre en place l’authentification par clés Ed25519

L’authentification par mot de passe est cassable par force brute, surtout face à des botnets distribuant les tentatives sur des centaines d’IPs sources. L’authentification par clés cryptographiques élimine cette catégorie d’attaque : la clé privée ne quitte jamais le poste local, le serveur ne stocke que la clé publique, et la signature cryptographique en jeu (Ed25519) est aujourd’hui inattaquable avec les ressources connues. Ed25519 (Curve25519, Edwards) est préférable à RSA même en 4096 bits : clés plus courtes (68 caractères vs 700+), génération et vérification beaucoup plus rapides, et résistance aux attaques side-channel mieux étudiée.

# Sur votre poste LOCAL (pas sur le VPS) — générer une nouvelle clé
ssh-keygen -t ed25519 -C "deploy@vps-hotel-saint-louis-2026" -f ~/.ssh/id_ed25519_vps

# Saisir une passphrase forte (12+ caractères, mélange) — protège la clé privée si le poste est volé

# Copier la clé publique sur le VPS pour le compte deploy
ssh-copy-id -i ~/.ssh/id_ed25519_vps.pub deploy@VOTRE_IP_VPS

# Tester la connexion par clé (doit demander la passphrase locale, pas le mot de passe deploy)
ssh -i ~/.ssh/id_ed25519_vps deploy@VOTRE_IP_VPS

Si la connexion réussit sans demander le mot de passe Linux du compte deploy (mais bien la passphrase locale qui décrypte la clé privée), l’authentification par clé est opérationnelle. Il est essentiel de garder la session SSH actuelle ouverte pendant qu’on continue à configurer le serveur — c’est l’assurance contre un verrouillage accidentel. Pour rendre la commande plus pratique, ajouter dans ~/.ssh/config côté local :

Host vps-hotel
    HostName VOTRE_IP_VPS
    User deploy
    IdentityFile ~/.ssh/id_ed25519_vps
    IdentitiesOnly yes
    Port 22

Une fois ce bloc en place, la commande ssh vps-hotel suffit pour se connecter. L’option IdentitiesOnly yes empêche SSH d’essayer d’autres clés en cache (utile si l’on a plusieurs serveurs avec des clés différentes — sans cette option, certains serveurs strictement configurés bannissent l’IP après 3 essais de clés non valides).

Étape 3 — Durcir sshd_config

Le fichier /etc/ssh/sshd_config contrôle tout le comportement du serveur SSH. La configuration par défaut sur la plupart des distributions reste permissive (PasswordAuthentication activée, root permis, algorithmes hérités acceptés) pour préserver la rétrocompatibilité. Sur un VPS de production, il faut explicitement restreindre. Avant toute modification, sauvegarder la configuration courante : sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.

# /etc/ssh/sshd_config — configuration durcie 2026
# Édition : sudo nano /etc/ssh/sshd_config

Port 22
# (Optionnel) Changer le port limite le bruit dans les logs mais n'apporte pas de sécurité
# réelle face à un attaquant ciblé. Ne pas considérer comme une mesure de sécurité.

PermitRootLogin no
# Désactivation totale de root SSH. La connexion se fait via deploy puis sudo.

PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
UsePAM yes

PermitEmptyPasswords no
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no
GatewayPorts no
PrintMotd no

# Limites anti-bruteforce (pour les rares clients par clé valide)
MaxAuthTries 3
MaxSessions 5
LoginGraceTime 30

# Timeout d'inactivité — déconnecte les sessions oubliées
ClientAliveInterval 300
ClientAliveCountMax 2

# Restriction stricte des utilisateurs autorisés
AllowUsers deploy admin
# Toute connexion d'un autre utilisateur (root, ubuntu, postgres, www-data) est refusée

# Logs
LogLevel VERBOSE
SyslogFacility AUTH

Chaque directive a un rôle précis. PermitRootLogin no est non-négociable : un attaquant qui finit par deviner un mot de passe root contourne tout l’effort de hardening. MaxAuthTries 3 coupe la session après trois tentatives ratées, ce qui ralentit massivement les bots qui tentent des dictionnaires de centaines de mots. ClientAliveInterval 300 + ClientAliveCountMax 2 ferme une session inactive après 10 minutes (300s × 2 = 600s) — protection contre les sessions oubliées sur un poste public ou volé. LogLevel VERBOSE double le niveau de détail dans /var/log/auth.log : utile pour Fail2ban et pour les corrélations d’incident dans un SIEM type Wazuh.

Étape 4 — Restreindre aux algorithmes cryptographiques modernes

OpenSSH accepte par défaut une trentaine d’algorithmes pour l’échange de clés (Kex), le chiffrement (Cipher) et l’authentification de paquet (MAC), incluant des suites héritées (3DES, HMAC-SHA1, diffie-hellman-group1) considérées aujourd’hui comme faibles ou compromises. Restreindre explicitement aux algorithmes modernes simplifie l’audit, élimine des vecteurs d’attaque downgrade, et améliore les performances. Cette restriction casse la compatibilité avec des clients SSH très anciens (PuTTY pre-0.68, OpenSSH ≤ 6) — vérifier que tous les opérateurs ont des clients à jour avant d’appliquer.

# À ajouter à la fin de /etc/ssh/sshd_config

# Échange de clés : seulement Curve25519 (rapide, sécurisé, sans dépendance à un nombre premier négocié)
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org

# Chiffrement symétrique : ChaCha20-Poly1305 (préféré, moderne) ou AES-GCM 256 (matériel)
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com

# MAC : Encrypt-then-MAC obligatoire (etm), pas de SHA1
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# Authentification : uniquement Ed25519 et RSA-SHA2 (pas de RSA-SHA1)
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256
PubkeyAcceptedAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

# Clés serveur : ne garder que les clés modernes
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

L’algorithme chacha20-poly1305@openssh.com est préféré pour les clients sans accélération matérielle AES (anciens téléphones, certains routeurs MIPS). Les serveurs avec CPU récent (Intel/AMD AES-NI) utilisent automatiquement aes256-gcm@openssh.com qui est plus rapide grâce aux instructions matérielles. La directive HostKey liste les clés serveur acceptées : on supprime ssh_host_ecdsa_key (NIST P-256/P-384, suspicion d’affaiblissement par la NSA selon les fuites Snowden) et on retire ssh_host_dsa_key (DSA, déprécié depuis OpenSSH 7).

Étape 5 — Restreindre par utilisateur, groupe ou IP source

Sur un VPS qui héberge plusieurs services (PostgreSQL, Nginx, Wazuh agent, Mailcow), des dizaines d’utilisateurs système sont créés automatiquement (postgres, www-data, mysql, ossec, vmail). Aucun de ces comptes ne devrait pouvoir se connecter en SSH, mais sans restriction explicite ils sont théoriquement accessibles. La directive AllowUsers définit une liste blanche stricte : seuls les utilisateurs nommés peuvent se connecter, tous les autres sont refusés au niveau du serveur SSH lui-même (avant même de demander un mot de passe ou une clé).

# Variantes selon votre besoin

# 1. Liste de comptes nommés
AllowUsers deploy admin sysadmin

# 2. Restreindre par groupe (recommandé si plusieurs comptes humains à gérer)
AllowGroups ssh-users

# Création du groupe et ajout
sudo groupadd ssh-users
sudo usermod -aG ssh-users deploy
sudo usermod -aG ssh-users admin

# 3. Restreindre par utilisateur ET IP source (Match block)
Match User deploy Address 41.214.0.0/16,196.0.0.0/8
    PasswordAuthentication no
    PubkeyAuthentication yes

Match User admin Address 192.168.1.0/24
    PasswordAuthentication no
    PubkeyAuthentication yes

La variante 3 (Match block par IP) est utile pour les équipes en télétravail avec des plages d’IP connues : un opérateur basé à Dakar peut limiter ses connexions aux plages d’opérateurs sénégalais (41.214.0.0/16 Sonatel, 196.0.0.0/8 Afrique). Combiné avec un VPN d’entreprise (WireGuard sur un autre VPS), on obtient une restriction très forte : SSH n’est accessible que depuis le VPN, lui-même filtré par fournisseur d’accès. Attention : si l’IP du domicile change (CGNAT, panne), seule la console KVM permet de récupérer l’accès.

Étape 6 — Tester la configuration avant de redémarrer

Une erreur de syntaxe dans sshd_config empêche le service SSH de démarrer. Si vous redémarrez sshd avec une mauvaise config et que votre session courante se ferme, le VPS devient inaccessible — récupération uniquement via console KVM ou rescue mode chez l’hébergeur. La commande sshd -t teste la syntaxe sans appliquer ; elle est obligatoire avant tout systemctl restart ssh.

# Test syntaxique (en root ou via sudo)
sudo sshd -t
# Aucune sortie = OK. Tout message d'erreur indique une ligne à corriger.

# Méthode prudente : démarrer un second sshd sur un port temporaire
sudo /usr/sbin/sshd -p 2222 -D &

# Depuis un AUTRE terminal local, tester la connexion sur le port temporaire
ssh -p 2222 deploy@VOTRE_IP_VPS
# Si ça marche, la nouvelle config est bonne. On peut redémarrer le service principal.

# Une fois rassuré, redémarrer le service SSH principal
sudo systemctl restart ssh
# (sur certaines distros : systemctl restart sshd)

# Garder la session courante ouverte ! Tester depuis un troisième terminal
ssh deploy@VOTRE_IP_VPS

Si le test depuis le troisième terminal réussit, fermer le sshd temporaire avec kill %1 ou fg puis Ctrl+C. Si à l’inverse le test échoue, conserver la session courante (qui bénéficie encore de l’ancienne config), corriger le fichier, retester avec sshd -t, puis recommencer. Cette procédure prudente évite 99 % des verrouillages accidentels. Sur les distributions systemd, l’autre option de sécurité est systemctl reload ssh (au lieu de restart) : le rechargement préserve les sessions actives même si la nouvelle config est invalide.

Étape 7 — Vérification finale avec ssh-audit

L’outil open-source ssh-audit (Python, MIT) audite à distance la configuration d’un serveur SSH et liste les algorithmes faibles, manquants ou mal configurés. C’est l’équivalent de SSL Labs pour HTTPS. Un score « A+ » signifie que le serveur n’expose que des algorithmes considérés sécurisés en 2026.

# Installation locale (pip ou apt)
pip3 install ssh-audit
# ou : sudo apt install ssh-audit

# Audit du serveur
ssh-audit VOTRE_IP_VPS

# Sortie attendue après hardening complet :
# (kex) curve25519-sha256                       -- [info] available since OpenSSH 7.4
# (enc) chacha20-poly1305@openssh.com           -- [info] available since OpenSSH 6.5
# (mac) hmac-sha2-512-etm@openssh.com           -- [info] available since OpenSSH 6.2
# Overall security: A+
#
# Avec recommandations additionnelles si applicable.

Si l’audit révèle des algorithmes « warn » ou « fail », repérer la directive correspondante dans sshd_config et corriger. Les warnings courants concernent souvent des HostKey ECDSA non supprimés (commenter HostKey /etc/ssh/ssh_host_ecdsa_key) ou des MACs SHA1 hérités. Relancer ssh-audit après chaque correction pour valider. À documenter dans la fiche de sécurité du VPS : score A+ atteint en date du JJ/MM/AAAA, avec mention des dérogations volontaires si certains clients hérités doivent rester compatibles.

Erreurs fréquentes

Erreur	Cause	Solution
« Permission denied (publickey) » après restart	Clé publique pas dans ~/.ssh/authorized_keys du nouvel utilisateur, ou permissions ~/.ssh trop ouvertes	chmod 700 ~/.ssh ; chmod 600 ~/.ssh/authorized_keys ; vérifier propriétaire avec ls -la ~/.ssh
VPS inaccessible après modification	Erreur de syntaxe non détectée, ou AllowUsers vide	Console KVM/rescue mode chez l’hébergeur, restaurer sshd_config.bak, redémarrer sshd
« no matching cipher found »	Client SSH trop ancien (PuTTY < 0.68, OpenSSH < 6)	Mettre à jour le client, ou ajouter temporairement un cipher hérité (ex: aes128-ctr) le temps de la transition
Sessions coupées après quelques minutes	ClientAliveInterval trop court combiné avec un NAT ou un proxy qui filtre les keepalive	Augmenter à 600s, ou ajouter TCPKeepAlive yes côté client dans ~/.ssh/config
Logs auth.log très bavards même après hardening	Bots qui essaient des comptes non-existants — refusés mais loggés	Installer fail2ban ou CrowdSec pour blocage automatique des IP suspectes (cf. tutoriel frère)
Connexion lente (5-10s) après hardening	DNS reverse lookup activé sur un VPS sans rDNS configuré	Ajouter UseDNS no dans sshd_config

Adaptation au contexte ouest-africain

Trois aspects pratiques pour les équipes opérant en Afrique de l’Ouest. Premièrement, la connectivité Internet domestique (Sonatel, Orange CI, MTN BJ, Moov SN, Free SN/Yas) souffre régulièrement de coupures de quelques minutes ou variations de latence vers l’Europe (Hetzner, OVH, Contabo). Un ClientAliveInterval trop agressif (60s) coupe les sessions à chaque microcoupure, ce qui frustre les opérateurs. La valeur 300s recommandée est un compromis : assez court pour fermer les sessions oubliées, assez long pour absorber les hoquets réseau. Si l’équipe est en zone très instable, monter à 600s n’est pas déraisonnable.

Deuxièmement, l’accès console KVM via l’interface web de l’hébergeur (Hetzner Cloud Console, OVH Manager, Contabo VPS Manager) reste la seule porte de secours en cas de verrouillage SSH. Vérifier avant tout hardening que cette console fonctionne et que vos identifiants hébergeur sont à jour. Sur Hetzner Cloud, la fonctionnalité s’appelle « Console » dans la fiche du serveur (icône moniteur). Sur OVH VPS, c’est « KVM » via le manager. Tester en se connectant en root via la console juste après l’achat du VPS et en exécutant uname -a — confirme que la voie est ouverte si nécessaire.

Troisièmement, le coût d’un VPN d’entreprise (WireGuard sur un second VPS Hetzner CX11 à 4€/mois) est marginal en comparaison de la sécurité gagnée : SSH ne s’expose plus directement à Internet, mais derrière le VPN, ce qui réduit drastiquement la surface d’attaque. Pour une PME ouest-africaine avec 3-10 collaborateurs nécessitant un accès SSH, c’est un investissement extrêmement rentable. Voir le tutoriel frère sur le déploiement WireGuard pour la procédure complète.

Tutoriels frères

• VPS Fail2ban : configuration complète anti-bruteforce SSH 2026 — bloquer automatiquement les IPs qui multiplient les échecs SSH
• VPS mises à jour de sécurité automatiques avec unattended-upgrades — patches OpenSSH et noyau appliqués sans intervention
• Firewall Hetzner Cloud : sécurisation VPS au niveau réseau — restreindre le port 22 par IP source côté hébergeur
• Installer CrowdSec sur VPS Debian/Ubuntu — alternative communautaire et collaborative à Fail2ban

FAQ

Faut-il changer le port SSH par défaut (22 → 2222 ou autre) ?

Changer le port SSH du 22 vers un port haut (2222, 22000, etc.) réduit considérablement le bruit dans les logs (les bots scannent quasi-exclusivement le port 22) mais n’apporte pas de sécurité réelle face à un attaquant ciblé qui scanne tous les ports avec nmap. C’est un confort opérationnel (« security through obscurity »), pas une mesure de sécurité. Si vous le faites, gardez bien à l’esprit que fail2ban et la console KVM/rescue de l’hébergeur supposent souvent le port 22 — ajuster les configs en conséquence.

Ed25519 vs RSA 4096 : lequel choisir ?

Ed25519 dans tous les cas. Sécurité équivalente à du RSA-3000 environ, clés plus courtes (68 caractères vs 700+), génération et signature beaucoup plus rapides, résistance side-channel mieux étudiée. RSA 4096 reste valable pour la compatibilité avec d’anciens systèmes (HPC en science, anciens routeurs Cisco) mais Ed25519 est supporté par OpenSSH 6.5+, soit toutes les distributions maintenues depuis 2014. Pas de raison de prendre RSA en 2026 sauf contrainte spécifique.

Comment révoquer une clé compromise ?

Éditer ~/.ssh/authorized_keys sur le serveur et supprimer la ligne correspondant à la clé compromise. Si l’utilisateur soupçonne que d’autres comptes utilisent la même clé (mauvaise pratique), le faire sur tous les serveurs concernés via Ansible ou un script de déploiement. Conserver la liste des clés actives quelque part (par exemple dans un dépôt Git privé Forgejo, avec hash SHA256 de chaque clé pour traçabilité) facilite la révocation rapide en cas d’incident.

Mon serveur reçoit toujours des tentatives de connexion après le hardening, est-ce normal ?

Oui, c’est normal et attendu. Les bots scannent en continu Internet et trouveront toujours votre IP. La différence est qu’ils n’arriveront jamais à se connecter : leurs tentatives en mot de passe sont refusées immédiatement (PasswordAuthentication no), leurs comptes « root », « admin » sont refusés (AllowUsers deploy admin), leurs algorithmes hérités sont refusés. L’objectif n’est pas de cacher le serveur, mais de rendre les attaques inopérantes. Compléter avec Fail2ban ou CrowdSec pour bannir les IPs après quelques tentatives ratées et alléger les logs.

Comment auditer périodiquement la configuration SSH ?

Mettre en place un cron mensuel qui relance ssh-audit et envoie le rapport par email à l’équipe sécurité. Combiné avec Wazuh ou un autre SIEM qui surveille les modifications de /etc/ssh/sshd_config via FIM (File Integrity Monitoring), on a une visibilité continue sur la configuration et son évolution. La règle générale : ré-auditer après chaque mise à jour majeure d’OpenSSH (les algorithmes par défaut changent parfois entre versions).

Pour aller plus loin

• 🔝 Retour au pilier : VPS hardening sécurité 2026 : guide complet
• Documentation officielle OpenSSH : openssh.com/manual.html
• Outil ssh-audit : github.com/jtesta/ssh-audit
• NIST SP 800-52 (TLS) et CISA hardening guidelines : cisa.gov/cybersecurity-advisories
• Mozilla OpenSSH Configuration Guide : infosec.mozilla.org/guidelines/openssh (référence sectorielle reconnue)
• Tutoriel suivant suggéré : configurer Fail2ban pour automatiser le bannissement des bots

Mots-clés secondaires : SSH hardening, sshd_config, Ed25519, ssh-audit, OpenSSH 9, sécurité VPS Linux, brute force SSH, AllowUsers, ChaCha20-Poly1305, hardening Hetzner, Afrique de l’Ouest sysadmin.