Sécuriser SSH sur un VPS Linux : désactiver le mot de passe et durcir sshd_config

Le daemon SSH est la porte d'entrée principale d'un serveur VPS ou d'un serveur dédié Linux. Sur Ubuntu, Debian, Rocky Linux ou toute autre distribution, la configuration par défaut laisse plusieurs vecteurs d'attaque ouverts : connexion root directe, authentification par mot de passe, et absence de filtrage des utilisateurs autorisés. Ce guide d'administrateurs Linux couvre chaque directive du fichier de configuration /etc/ssh/sshd_config à modifier, la raison de chaque changement et les commandes pour tester avant de recharger le service.

Avant de commencer : sauvegarder et tester en sécurité

Toute modification du fichier de configuration sshd_config sur un serveur distant comporte un risque de perte d'accès si la syntaxe est incorrecte. Un bon admin applique deux précautions systématiques avant de toucher à la configuration du serveur SSH.

Sauvegarder les fichiers de configuration actuels :

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

Valider la syntaxe :

sudo sshd -t

Cette commande ne renvoie rien en cas de succès. Si une erreur est signalée dans le shell, corrigez-la avant de recharger. Rechargez ensuite plutôt que de restarter pour conserver votre session ouverte :

sudo systemctl reload ssh

Sur certaines distributions comme CentOS, RHEL ou Rocky Linux, le service s'appelle sshd et non ssh. Sur Ubuntu et Debian, ssh est le nom courant. Vérifiez avec :

systemctl status ssh sshd 2>/dev/null | head -4

Avant tout rechargement, ouvrez une deuxième session SSH parallèle dans un autre terminal. Si la connexion existante se fige, la deuxième vous permet de corriger la configuration sans perdre l'accès à votre serveur VPS.

Pour afficher toute la configuration du serveur SSH effective, utilisez le mode étendu depuis la ligne de commande :

sudo sshd -T

Cette commande liste tous les paramètres actifs, y compris ceux non écrits dans le fichier de configuration, et s'avère indispensable pour auditer l'état réel du service. SSH utilise le chiffrement asymétrique pour protéger les communications en transit, et le protocole SSH-2 est le seul supporté dans les versions modernes d'OpenSSH.

Désactiver la connexion root directe

La quasi-totalité des tentatives de force brute ciblent le compte root sur l'adresse IP publique de votre serveur. Interdire sa connexion directe oblige l'attaquant à deviner à la fois un nom d'utilisateur valide et ses mots de passe. C'est l'une des premières directives à appliquer dans tout processus de hardening.

Dans le fichier de configuration /etc/ssh/sshd_config, localisez ou ajoutez :

PermitRootLogin no

Si votre processus de déploiement (script Ansible ou pipeline CI/CD) exige un accès root, l'alternative moins restrictive est :

PermitRootLogin prohibit-password

Cette valeur autorise root uniquement avec une clé SSH, en refusant tout mot de passe. Vérifiez l'état actuel en ligne de commande :

sudo sshd -T | grep permitrootlogin

Restreindre les utilisateurs autorisés

La directive AllowUsers établit une liste blanche explicite de connexions. Tout compte absent de cette liste se voit refuser l'accès SSH, même s'il possède un mot de passe valide.

AllowUsers alice deploy

Séparez les logins par des espaces. Si vous gérez plusieurs serveurs avec des équipes différentes, la directive AllowGroups est plus flexible : ajoutez les comptes autorisés dans un groupe Unix dédié, puis indiquez ce groupe dans les fichiers de configuration :

AllowGroups sshusers

Créez le groupe et ajoutez-y vos comptes depuis le shell :

sudo groupadd sshusers
sudo usermod -aG sshusers alice

Confirmez les accès de votre propre session avant d'appliquer cette restriction. Consultez le guide configurer une clé SSH sans perdre l'accès pour sécuriser vos clés avant ce changement.

Désactiver l'authentification par mot de passe

Une fois vos clés SSH en place et testées, désactivez entièrement l'authentification par mot de passe. Cela supprime la surface d'attaque par force brute sur votre serveur VPS ou serveur dédié.

PasswordAuthentication no
PermitEmptyPasswords no

Important : assurez-vous que votre clé publique est présente dans le répertoire ~/.ssh/authorized_keys et que les permissions sont correctes (chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys) avant d'appliquer cette directive. En cas de doute, consultez d'abord le guide configurer une clé SSH.

Vérification en ligne de commande :

sudo sshd -T | grep -E 'passwordauthentication|permitemptypasswords'

Limiter les tentatives d'authentification

La directive MaxAuthTries fixe le nombre maximal de tentatives par connexion. La moitié de cette valeur déclenche la journalisation des échecs dans les logs.

MaxAuthTries 3
LoginGraceTime 30

LoginGraceTime (en secondes) ferme automatiquement la connexion si l'authentification n'aboutit pas dans ce délai. Une valeur de 30 secondes suffit pour une frappe manuelle tout en pénalisant les scripts d'attaque automatiques.

Pour compléter ce filtrage, configurez Fail2ban ou le pare-feu nftables pour bannir temporairement les adresses IP qui multiplient les échecs d'authentification.

Fermer les sessions inactives

Une session SSH restée ouverte sans activité est un vecteur de risque. Les directives ClientAliveInterval et ClientAliveCountMax ferment ces sessions automatiquement et libèrent les ressources du serveur.

ClientAliveInterval 300
ClientAliveCountMax 2

Le daemon SSH envoie un message keepalive toutes les 300 secondes (5 minutes). Si le client ne répond pas après 2 envois consécutifs, la session est fermée. Un serveur dédié de production peut tolérer 600 secondes avant le premier keepalive.

Ces directives agissent au niveau applicatif et fonctionnent même à travers un proxy NAT, contrairement à TCPKeepAlive qui opère à la couche transport. Désactivez TCPKeepAlive pour éviter la redondance :

TCPKeepAlive no

Changer le port SSH (optionnel)

Modifier le port d'écoute réduit le bruit dans les logs en évitant les bots qui scannent l'adresse IP de votre serveur sur le port 22. Choisissez un port entre 1024 et 65535 dans le fichier de configuration :

Port 2222

Vérifiez qu'aucun autre service ne l'occupe :

sudo ss -tlnp | grep 2222

Ouvrez le nouveau port dans votre firewall avant de recharger le daemon SSH. Sur Ubuntu et Debian avec UFW :

sudo ufw allow 2222/tcp comment "SSH custom"
sudo ufw deny 22/tcp

Pour gérer les ports de votre serveur Linux, consultez le guide ouvrir les ports avec UFW.

Désactiver les fonctions inutiles

Plusieurs fonctionnalités SSH ne sont pas nécessaires sur un serveur VPS ou serveur dédié. Un admin Linux les désactive dans le fichier de configuration pour réduire la surface d'attaque :

# Désactiver le forwarding X11 (affichage graphique)
X11Forwarding no

# Ignorer le fichier .rhosts (méthode d'authentification obsolète)
IgnoreRhosts yes

# Interdire l'authentification basée sur l'hôte
HostbasedAuthentication no

# Désactiver l'agent forwarding si non nécessaire
AllowAgentForwarding no

# Désactiver le TCP forwarding si non nécessaire
AllowTcpForwarding no

X11Forwarding ouvre un canal retour vers le client pour l'affichage graphique. Désactivé sur un serveur headless, il supprime un vecteur d'injection de commandes malveillantes. AllowTcpForwarding no est à évaluer selon votre usage : si vous utilisez des tunnels SSH pour accéder à des services internes, conservez yes ou local. Consultez le guide créer un tunnel SSH pour en savoir plus.

Configuration complète recommandée

Voici un bloc récapitulatif pour votre fichier de configuration /etc/ssh/sshd_config (ou dans un fichier dédié sous /etc/ssh/sshd_config.d/hardening.conf, disponible sur Ubuntu 22.04+ et Debian 12+). Adaptez AllowUsers à vos comptes réels. Cette configuration du serveur convient à un serveur VPS, un serveur dédié ou tout serveur Unix/Linux exposé sur internet.

# --- Hardening SSH ---
Port 22                      # Votre port personnalisé si besoin
PermitRootLogin no
AllowUsers votre-utilisateur
PasswordAuthentication no
PermitEmptyPasswords no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2
TCPKeepAlive no
X11Forwarding no
IgnoreRhosts yes
HostbasedAuthentication no
AllowAgentForwarding no
AllowTcpForwarding no
PrintLastLog yes

Après chaque modification, validez la syntaxe avec sudo sshd -t puis rechargez avec sudo systemctl reload ssh (ou restart si reload n'est pas disponible). Installez si nécessaire les paquets OpenSSH depuis la ligne de commande :

# Ubuntu / Debian
sudo apt install openssh-server

# Rocky Linux / CentOS
sudo dnf install openssh-server

Surveillez les connexions suspectes dans les logs :

sudo journalctl -u ssh --since "1 hour ago" | grep -i "failed\|invalid\|error"

Pour analyser ces échecs en détail, consultez le guide analyser les échecs de connexion SSH dans les logs Linux.

Vérifier l'efficacité du hardening

Une fois les fichiers de configuration appliqués, vérifiez l'ensemble des paramètres actifs du daemon SSH en ligne de commande :

sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|maxauthtries|port|allowusers|x11forwarding|allowtcpforwarding'

Pour sécuriser davantage l'accès réseau à votre serveur VPS ou serveur dédié depuis une adresse IP de confiance, configurez un pare-feu nftables ou déployez Fail2ban pour bannir automatiquement les tentatives répétées. Si vous administrez un serveur de jeu Linux, pensez également à configurer un service systemd pour que votre serveur redémarre automatiquement.

Le hardening SSH est une bonne pratique fondamentale pour tout admin de serveur VPS Linux exposé sur internet. Combiné à un firewall nftables, à Fail2ban et au chiffrement par clé asymétrique, il réduit considérablement la surface d'attaque sans impacter l'administration quotidienne.