Comment configurer SSH et sécuriser l'accès à son VPS Linux

Sécuriser SSH VPS Linux est une priorité absolue pour tout administrateur système hébergeant des données en production. SSH (Secure Shell) constitue la porte d'entrée principale vers votre serveur virtuel : une configuration faible expose votre infrastructure aux attaques par force brute, aux scans automatisés et aux intrusions. Ce guide présente les étapes concrètes pour transformer une installation SSH par défaut en forteresse solide, en combinant authentification renforcée, restrictions réseau et surveillance active.

Lorsque vous déployez un VPS Linux OmegaCloud sous Debian, Ubuntu ou Rocky Linux, le service SSH démarre avec une configuration permissive : authentification par mot de passe activée, port 22 exposé, connexions root autorisées. Cette posture initiale facilite le provisioning rapide, mais devient une cible de choix dès que l'adresse IP publique apparaît dans les scans automatisés. Nous allons durcir chaque couche de cette surface d'attaque.

Désactiver l'authentification par mot de passe et passer aux clés SSH

L'authentification par clé publique/privée élimine 90 % des attaques par dictionnaire. Contrairement à un mot de passe, une clé ED25519 ou RSA 4096 bits ne peut être devinée par force brute dans un délai raisonnable. Commencez par générer une paire de clés sur votre poste local (Linux, macOS, WSL Windows) :

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

Cette commande crée deux fichiers : ~/.ssh/id_ed25519 (clé privée, à ne jamais partager) et ~/.ssh/id_ed25519.pub (clé publique, à déployer sur le serveur). Copiez la clé publique vers votre VPS :

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@IP_VPS

Après avoir vérifié que la connexion par clé fonctionne, modifiez /etc/ssh/sshd_config pour interdire définitivement les mots de passe :

sudo nano /etc/ssh/sshd_config

Repérez et modifiez les lignes suivantes (décommentez-les si nécessaire) :

PasswordAuthentication no
PermitRootLogin prohibit-password
PubkeyAuthentication yes
ChallengeResponseAuthentication no

Relancez le daemon SSH pour appliquer les changements :

sudo systemctl restart sshd

Important : avant de fermer votre session actuelle, ouvrez un second terminal et testez la connexion par clé. Si vous vous êtes trompé dans la configuration, vous gardez un terminal de secours pour corriger avant le verrouillage.

Changer le port SSH et restreindre l'accès par pare-feu

Bien que la modification du port SSH ne constitue pas une défense en profondeur, elle réduit drastiquement le bruit des scans automatisés qui ciblent le port 22. Choisissez un port libre entre 1024 et 65535, par exemple 47822. Éditez à nouveau /etc/ssh/sshd_config :

Port 47822

Avant de redémarrer SSH, configurez le pare-feu ufw (Uncomplicated Firewall) pour autoriser le nouveau port et bloquer l'ancien :

sudo ufw allow 47822/tcp comment 'SSH custom port'
sudo ufw enable
sudo ufw status numbered

Relancez ensuite SSH :

sudo systemctl restart sshd

Testez la connexion avec le nouveau port :

ssh -p 47822 root@IP_VPS

Sur OmegaCloud, l'anti-DDoS volumétrique est déjà actif au niveau datacenter, mais cela ne dispense pas d'une politique de pare-feu locale stricte. Utilisez ufw pour limiter SSH à des plages IP de confiance si votre équipe utilise des adresses fixes :

sudo ufw allow from 203.0.113.0/24 to any port 47822 proto tcp
sudo ufw deny 47822/tcp

Cette règle n'autorise SSH que depuis le subnet 203.0.113.0/24, bloquant tout le reste. Pour les équipes en télétravail ou nomades, un VPN Wireguard ou OpenVPN devient alors le meilleur compromis pour fixer l'origine des connexions.

Mettre en place Fail2Ban pour bloquer les tentatives répétées

Fail2Ban analyse les journaux système en temps réel et bannit automatiquement les adresses IP qui multiplient les échecs d'authentification. C'est un garde-fou essentiel même après avoir sécurisé SSH VPS par clés. Installez Fail2Ban sur Debian/Ubuntu :

sudo apt update
sudo apt install fail2ban -y

Créez un fichier de configuration local pour éviter que les mises à jour ne l'écrasent :

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

Activez la jail SSH et ajustez les seuils :

[sshd]
enabled = true
port = 47822
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600

Cette configuration bannit toute IP qui échoue 3 fois (maxretry) en 10 minutes (findtime), pour une durée de 1 heure (bantime). Relancez Fail2Ban :

sudo systemctl enable fail2ban
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

La commande status sshd affiche le nombre d'IP bannies en direct. Vous pouvez vérifier les IPs blacklistées avec :

sudo fail2ban-client get sshd banned

Pour débannir manuellement une IP légitime bloquée par erreur :

sudo fail2ban-client set sshd unbanip 203.0.113.42

Fail2Ban s'appuie sur iptables ou nftables selon la distribution. Vérifiez que les règles sont actives via sudo iptables -L -n ou sudo nft list ruleset.

Activer l'authentification à deux facteurs (2FA) avec Google Authenticator

L'ajout d'une couche TOTP (Time-based One-Time Password) renforce la sécurité SSH VPS même en cas de compromission de la clé privée (vol de laptop, backup non chiffré). Le module PAM libpam-google-authenticator intègre cette fonctionnalité sans surcharge logicielle. Installez-le :

sudo apt install libpam-google-authenticator -y

Exécutez la commande en tant qu'utilisateur concerné (jamais en root si vous avez créé un compte admin dédié) :

google-authenticator

Répondez y aux questions proposées pour accepter TOTP, mettre à jour le fichier .google_authenticator et activer les protections contre les réutilisations de codes. L'outil affiche un QR code : scannez-le avec Google Authenticator, Authy ou FreeOTP sur votre smartphone.

Modifiez ensuite /etc/pam.d/sshd pour exiger le code OTP :

sudo nano /etc/pam.d/sshd

Ajoutez cette ligne en haut du fichier, avant @include common-auth :

auth required pam_google_authenticator.so nullok

L'option nullok permet aux utilisateurs n'ayant pas encore configuré 2FA de continuer à se connecter ; retirez-la une fois le déploiement terminé. Modifiez enfin /etc/ssh/sshd_config :

ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive

Cette directive impose clé SSH et code TOTP. Relancez SSH :

sudo systemctl restart sshd

Lors de la prochaine connexion, vous devrez saisir le code à 6 chiffres affiché par votre application mobile après validation de la clé privée. Conservez les codes de secours générés par google-authenticator dans un coffre-fort de mots de passe (KeePassXC, Bitwarden).

Surveiller les connexions et journaux avec auditd

Le daemon auditd enregistre chaque action privilégiée, y compris les connexions SSH et les modifications de fichiers critiques. Installez-le :

sudo apt install auditd audispd-plugins -y
sudo systemctl enable auditd
sudo systemctl start auditd

Créez une règle pour tracer toutes les connexions SSH :

sudo auditctl -w /var/log/auth.log -p wa -k ssh_access
sudo auditctl -w /etc/ssh/sshd_config -p wa -k sshd_config_change

Consultez les événements en temps réel :

sudo ausearch -k ssh_access

Pour une analyse graphique, des outils comme aureport ou l'intégration avec un stack ELK (Elasticsearch-Logstash-Kibana) permettent de corréler les événements. Le panel OmegaCloud offre un monitoring temps réel CPU/RAM/réseau, mais l'analyse des logs système reste côté client.

Une autre pratique recommandée consiste à activer le journaling centralisé avec rsyslog ou journald vers un serveur de logs dédié, isolant les traces d'audit du VPS potentiellement compromis. Cette architecture est documentée dans les guides de l'ANSSI.

Durcir les paramètres cryptographiques SSH

Les versions récentes d'OpenSSH supportent des algorithmes de chiffrement et d'échange de clés performants et résistants aux attaques quantiques en devenir. Désactivez les ciphers obsolètes (3DES, RC4, CBC) et privilégiez ChaCha20-Poly1305 et AES-GCM. Éditez /etc/ssh/sshd_config :

Ciphers [email protected],[email protected],[email protected]
MACs [email protected],[email protected]
KexAlgorithms curve25519-sha256,[email protected],diffie-hellman-group16-sha512
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

Vérifiez la compatibilité de votre client SSH local avec ssh -Q cipher et ssh -Q kex. Redémarrez le daemon :

sudo systemctl restart sshd

Pour aller plus loin, Mozilla publie un guide de configuration OpenSSH révisé régulièrement, référence dans l'industrie.

Automatiser les mises à jour de sécurité

Les vulnérabilités OpenSSH critiques (CVE-2023-38408, CVE-2021-41617) sont corrigées rapidement par les distributions, mais requièrent l'application des patchs. Sur Debian/Ubuntu, activez unattended-upgrades :

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure -plow unattended-upgrades

Configurez les mises à jour automatiques en éditant /etc/apt/apt.conf.d/50unattended-upgrades :

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::AutoFixInterruptedDpkg "true";
Unattended-Upgrade::MinimalSteps "true";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Automatic-Reboot "false";

L'option Automatic-Reboot "false" évite les redémarrages non planifiés, laissant l'administrateur planifier les fenêtres de maintenance. Surveillez les logs dans /var/log/unattended-upgrades/.

Sur les infrastructures VPS Linux OmegaCloud, le snapshot manuel depuis le panel permet de capturer l'état du système avant toute mise à jour critique, offrant un rollback rapide en cas de régression.

Conclusion

Sécuriser SSH VPS Linux repose sur un empilement de défenses : clés cryptographiques fortes, restriction réseau par IP et port, détection d'intrusion avec Fail2Ban, authentification multi-facteurs et journalisation. Aucune mesure isolée ne suffit, mais leur combinaison élève le coût d'une attaque au-delà des capacités des scripts automatisés. Maintenez cette posture en révisant régulièrement les logs, en surveillant les CVE OpenSSH et en testant la restauration de vos snapshots. Une infrastructure cloud sécurisée commence par la porte d'entrée SSH verrouillée.

FAQ

Faut-il vraiment désactiver complètement l'authentification par mot de passe SSH ?

Oui, c'est la recommandation la plus impactante. Les attaques par dictionnaire et credential stuffing ciblent massivement les mots de passe. L'authentification par clé publique élimine ce vecteur tout en simplifiant la gestion automatisée (Ansible, Terraform). Conservez toujours une console KVM de secours (disponible dans le panel OmegaCloud) pour intervenir en cas de perte de clé privée.

Le changement de port SSH suffit-il comme protection ?

Non, c'est une couche d'obscurité (security by obscurity) qui réduit le bruit mais n'empêche pas un attaquant déterminé de scanner tous les ports. Combinez-le obligatoirement avec désactivation des mots de passe, Fail2Ban et restriction IP via ufw ou iptables. Le port non-standard facilite surtout la lecture des logs en éliminant 95 % des scans opportunistes.

Comment récupérer l'accès SSH après une mauvaise manipulation de sshd_config ?

Utilisez la console KVM accessible depuis le panel de gestion de votre hébergeur. Sur OmegaCloud, cliquez sur « Console » dans le dashboard VPS : vous obtenez un accès direct au terminal sans passer par SSH. Connectez-vous en root, corrigez /etc/ssh/sshd_config, relancez systemctl restart sshd et testez depuis un autre terminal avant de fermer la console. Conservez toujours une session SSH ouverte lors des modifications critiques.