Sécuriser SSH sur un VPS Linux : la check-list de durcissement

1. Mettre à jour le système et activer les mises à jour de sécurité automatiques

Commencez par installer les mises à jour en attente : apt update actualise les listes de paquets et apt upgrade installe les nouvelles versions. [1]

sudo apt update
sudo apt upgrade

Sous Ubuntu, les mises à jour de sécurité s’installent automatiquement grâce au paquet unattended-upgrades, installé par défaut, qui s’exécute une fois par jour. Les deux valeurs du fichier /etc/apt/apt.conf.d/20auto-upgrades doivent être à « 1 », et une exécution à blanc indique ce que l’outil installerait. [1]

cat /etc/apt/apt.conf.d/20auto-upgrades
sudo unattended-upgrade --dry-run -v

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

unattended-upgrades ne redémarre pas le serveur de lui-même, car Unattended-Upgrade::Automatic-Reboot vaut false par défaut : redémarrez donc manuellement quand une mise à jour l’exige. [1] Sous Debian 12, si le paquet ou le fichier est absent, installez unattended-upgrades et créez le fichier avec les deux lignes ci-dessus.

2. Créer un utilisateur sudo autre que root

Effectuez les tâches d’administration avec un compte nominatif et sudo, qui demande le mot de passe de cet utilisateur, et non celui de root. Les membres du groupe sudo obtiennent par ce biais un accès root complet. [2]

sudo adduser deploy
sudo adduser deploy sudo

adduser demande un mot de passe et quelques informations facultatives. [2] Choisissez un mot de passe long : SSH utilisera des clés, mais sudo continuera de le demander. Vérifiez ensuite le compte : sudo whoami doit afficher root.

su - deploy
sudo whoami

Sous Debian 12, si la commande sudo est absente, installez-la d’abord en root avec apt install sudo.

3. Générer une clé ed25519 sur votre ordinateur

Créez la paire de clés sur votre propre ordinateur, pas sur le serveur. Ubuntu recommande le type ed25519, dont les clés sont plus courtes et moins coûteuses en calcul, et ssh-keygen demande une phrase de passe qui protège la clé privée. [3]

ssh-keygen -t ed25519

Gardez le nom de fichier par défaut. La clé privée est ~/.ssh/id_ed25519 ; la clé publique, celle que vous copiez sur les serveurs, est ~/.ssh/id_ed25519.pub. [3]

Sous Windows, lancez la même commande dans PowerShell ; elle enregistre la paire de clés dans le dossier .ssh de votre profil utilisateur. Microsoft déconseille de laisser la phrase de passe vide et prévient que quiconque obtient la clé privée peut se connecter sous votre identité. [4]

ssh-keygen -t ed25519

4. Copier la clé publique sur le serveur

Sous Linux et macOS, ssh-copy-id ajoute votre clé publique à la fin du fichier ~/.ssh/authorized_keys de l’utilisateur sur le serveur. [3]

ssh-copy-id deploy@203.0.113.10

Le guide de Microsoft, lui, copie les clés avec PowerShell ou scp. [4] Pour un serveur Linux, cette ligne ajoute votre clé et rend le dossier et le fichier modifiables par vous seul :

Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub | ssh deploy@203.0.113.10 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Le service sshd vérifie ces droits avant d’accepter une connexion, grâce à l’option StrictModes, activée par défaut. [5] Lancez ensuite ssh deploy@203.0.113.10 dans un nouveau terminal : vous devriez vous connecter sans saisir le mot de passe du compte. Sinon, suivez le journal SSH du serveur pendant que vous réessayez : [3]

sudo journalctl -fu ssh.service

5. Placer vos réglages dans un fichier dédié

Sous Ubuntu, /etc/ssh/sshd_config commence par Include /etc/ssh/sshd_config.d/*.conf, et OpenSSH retient la première valeur qu’il lit pour la plupart des paramètres : les fichiers de ce dossier l’emportent donc sur le fichier principal. [3] Les fichiers inclus sont lus dans l’ordre lexicographique et, pour chaque mot-clé, c’est la première valeur obtenue par sshd qui s’applique [5] : nommez donc le vôtre 00-hardening.conf.

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
AllowUsers deploy

D’après la page de manuel de sshd_config :

• PermitRootLogin no empêche root de se connecter en SSH. La valeur par défaut, prohibit-password, refuse les mots de passe pour root mais accepte toujours les clés. [5]
• PasswordAuthentication no désactive les connexions par mot de passe, autorisées par défaut. [5]
• KbdInteractiveAuthentication no désactive l’authentification interactive au clavier (keyboard-interactive), une méthode distincte, elle aussi active par défaut ; l’option s’appelait auparavant ChallengeResponseAuthentication. [5]
• AllowUsers deploy (facultatif) ne laisse se connecter que les utilisateurs indiqués. Contrairement à la plupart des mots-clés, chaque ligne AllowUsers s’ajoute à la liste. [5] Vérifiez bien l’orthographe du nom, sinon personne ne pourra se connecter.

Désormais, protégez le compte sudo avec le même soin que root : les notes du paquet openssh d’Ubuntu considèrent tout compte qui permet de passer root comme équivalent à root face aux attaques extérieures. [6] Sous Debian 12, vérifiez d’abord la présence de la ligne Include avec grep -n Include /etc/ssh/sshd_config.

6. Rechercher les fichiers qui réactivent les mots de passe

Comme la première valeur l’emporte, tout fichier qui précède le vôtre dans l’ordre de tri a la priorité sur lui. Examinez le dossier :

ls /etc/ssh/sshd_config.d/
sudo grep -riE 'passwordauthentication|kbdinteractive|permitrootlogin|allowusers' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

Sur les images cloud, cloud-init écrit les paramètres SSH qu’il gère dans /etc/ssh/sshd_config.d/50-cloud-init.conf dès lors que sshd_config inclut ce dossier. [7] Si ce fichier contient PasswordAuthentication yes, il l’emporte sur tous les fichiers classés après lui : c’est pourquoi le nom du vôtre commence par 00. Remplacez-y aussi la valeur par no, pour que les fichiers concordent.

7. Tester la configuration et redémarrer SSH

Testez les fichiers avant de redémarrer : un paramètre erroné peut empêcher sshd de démarrer, et SSH est peut-être votre seule porte d’entrée. [3]

sudo sshd -t
sudo systemctl restart ssh.service

Corrigez d’abord tout ce que signale sshd -t. Après le redémarrage, gardez votre session ouverte et testez depuis un deuxième terminal :

ssh deploy@203.0.113.10
ssh root@203.0.113.10

La première connexion doit réussir et la seconde doit être refusée. Si votre connexion échoue, annulez la modification dans la session restée ouverte et consultez le journal SSH vu à l’étape 4. [3]

8. Changer le port sous Ubuntu 24.04 (facultatif)

Sous Ubuntu 24.04, c’est ssh.socket qui écoute sur le port 22, grâce à l’activation par socket de systemd. Un générateur convertit les lignes Port de sshd_config et de ses fichiers inclus en paramètres du socket : après un changement de port, il faut donc recharger systemd et redémarrer ssh.socket. [6]

Comme sshd accepte plusieurs lignes Port, [5] gardez le 22 le temps de tester le nouveau port :

Port 22
Port 2222

sudo sshd -t
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket

Testez le nouveau port depuis un deuxième terminal. Supprimez ensuite Port 22, relancez les trois commandes et utilisez le port 2222 aux étapes 9 et 10.

ssh -p 2222 deploy@203.0.113.10

Sous Debian 12, vérifiez d’abord si le socket est utilisé. S’il est inactif, il suffit de redémarrer le service pour appliquer la modification.

systemctl is-active ssh.socket
sudo systemctl restart ssh.service

9. Autoriser SSH dans UFW, puis l’activer

UFW est installé mais désactivé et, une fois activé, il refuse par défaut le trafic entrant. Sa page de manuel prévient que ufw enable peut couper les connexions SSH : ajoutez donc d’abord la règle SSH. [8]

Pour SSH, utilisez limit plutôt que allow. Une règle limit autorise bien les connexions, mais refuse celles d’une adresse qui tente d’en ouvrir 6 ou plus en 30 secondes. N’ajoutez pas les deux règles, car UFW applique la première règle qui correspond. [8]

sudo ufw limit 22/tcp
sudo ufw enable
sudo ufw status verbose

UFW demande une confirmation quand vous l’activez depuis une session SSH. [8] Si vous avez changé le port SSH, limitez plutôt 2222/tcp. Sous Debian 12, installez d’abord UFW si la commande est absente. Pour ne plus exposer SSH du tout sur Internet, n’y accédez que par un réseau privé WireGuard. Pour une protection plus en amont, consultez notre check-list de protection DDoS pour l’hébergement VPS.

10. Ajouter Fail2ban et sa jail sshd

Sous Ubuntu 24.04, le paquet fournit /etc/fail2ban/jail.d/defaults-debian.conf, qui active la jail sshd, définit backend = systemd et bannit via nftables. [9] Le backend systemd lit le journal de systemd : la jail n’a donc besoin d’aucun fichier journal distinct. [10]

sudo apt install fail2ban
cat /etc/fail2ban/jail.d/defaults-debian.conf

Le jail.conf d’origine de Fail2ban bannit une adresse pendant 10 minutes dès qu’elle cumule 5 échecs en 10 minutes, et vous demande de ne pas modifier ce fichier : placez vos changements dans jail.local. [10]

[sshd]
enabled = true
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h
ignoreip = 127.0.0.1/8 ::1 198.51.100.7

Remplacez 198.51.100.7 par votre propre adresse fixe, ou supprimez-la. La jail par défaut utilise port = ssh : ajoutez donc port = 2222 si vous avez changé le port SSH. [10] Sous Debian 12, gardez ici backend = systemd et installez python3-systemd, la bibliothèque Python de systemd qu’utilise ce backend. [10] Redémarrez ensuite Fail2ban et vérifiez qu’il fonctionne :

sudo systemctl restart fail2ban
sudo systemctl status fail2ban

11. Vérifier les autres services à l’écoute

Chaque port ouvert est une porte d’entrée de plus. La liste des ports en écoute fournie par UFW indique chaque port TCP en écoute et chaque port UDP ouvert, avec son adresse (* signifie toutes les interfaces), le programme associé et les règles qui s’appliquent. [8]

sudo ufw show listening

Un service qui écoute sur 127.0.0.1 n’est joignable que depuis le serveur lui-même. Désactivez les services exposés dont vous n’avez pas besoin avec systemctl disable --now, comme le font les notes openssh d’Ubuntu pour ssh.socket. [6]

sudo systemctl disable --now SERVICE_NAME