Comment durcir la configuration de son serveur SSH ?

I. Présentation

Dans ce tutoriel, nous allons voir comment sécuriser le service SSH sous Linux, en respectant quelques best practices en matière de configuration d'un serveur SSH.

Le protocole SSH est recommandé pour la connexion à distance, la réalisation de sauvegardes, le transfert de fichiers à distance via scp ou sftp, et bien plus encore. SSH est parfait pour préserver la confidentialité et l'intégrité des données échangées entre deux machines situées sur des réseaux différents, ou sur le même réseau. Son principal avantage est l'authentification du serveur, grâce à l'utilisation de la cryptographie à clé publique pour l'authentification. (aussi appelée SSH password-less). Sous Linux (et Windows), l'implémentation de ce protocole se fait par le biais du packet OpenSSH.

Depuis quelques années, au grès des mises à jour, OpenSSH a vu sa sécurité durcie, notamment en ce qui concerne les messages d'erreurs (trop verbeux) au départ. Ce guide ne sera pas très long étant donné que les développeurs ont fait un gros effort afin d'éviter que la configuration d'OpenSSH ne soit trop permissive par défaut.

Environnement :

• Client SSH : Kali Linux (2021.3) - 192.168.175.128
• Serveur SSH : Ubuntu 20.04.1 LTS - 192.168.175.129 - Deux utilisateurs : tintin, haddock

Toutes les commandes ci-dessous seront exécutées par l'intermédiaire de l'utilisateur root. 

Avant de commencer, installez SSH sur votre serveur :

sudo apt install openssh-server
# apt utilise aussi l'alias ssh, pour identifier le paquet openssh-server

II. Sécurisation générale de SSH

Quelle que soit la méthode de connexion au serveur SSH, il y a certaines règles communes à respecter afin de brouiller les pistes pour un attaquant :

• Modifier le port et l'interface réseau d'écoute par défaut
• Fixer un Idle timeout pour ne pas avoir de sessions SSH qui restent actives
• Empêcher la connexion de l'utilisateur root (sur les distributions Linux récentes, cette fonctionnalité est désactivée par défaut)
• etc.

Pour cela, nous allons modifier le fichier "/etc/ssh/sshd_config" de notre serveur SSH. Editez ce fichier avec votre éditeur préféré :

sudo nano /etc/ssh/sshd_config

A. Modifier le port et l'interface réseau d'écoute par défaut

Par défaut, le port d'écoute SSH est 22, changez-le afin de brouiller les pistes. Pour cela, modifiez le paramètre "Port" du fichier de configuration :

Port 2021

L'interface d'écoute du protocole SSH est par défaut "Toutes les interfaces" : 0.0.0.0/0. Changez ce paramètre, afin que votre serveur SSH accepte seulement les connexions sur votre interface principale. Si vous n'avez pas plusieurs interfaces réseau (j'entends par la carte réseau) et adresses IP sur votre serveur, vous pouvez vous passer de cette modification.

Pour que SSH écoute seulement sur l'adresse IP "192.168.175.129", voici la configuration :

ListenAddress 192.168.175.129

Puis, redémarrez le service :

systemctl restart ssh

B. Configurer le timeout des sessions SSH

Pour cette troisième modification, nous allons définir un temps maximal d'inactivité pour une session SSH, afin d'éviter que certaines connexions SSH restent actives indéfiniment.

Dans ce cas précis, si le service SSH ne détecte aucune activité sur le flux de connexion (en bref, si aucune commande n'est saisie pendant un laps de temps), alors il terminera automatiquement la connexion.

Si vous souhaitez que le client SSH se ferme (timeout) automatiquement après 10 minutes (600 secondes), modifiez le fichier sshd_config et définissez les deux paramètres suivants comme indiqué ci-dessous.

• ClientAliveInterval - ceci indique le délai d'attente en secondes. Après x secondes, le serveur SSH enverra un message au client demandant une réponse.

• ClientAliveCountMax - ceci indique le nombre total de messages de vérification envoyés par le serveur SSH sans obtenir de réponse du client SSH.

Nous en avons fini avec cette partie. Quelle que soit votre configuration, respectez ces règles. Pour valider ces changements, redémarrez le service SSH :

systemctl restart ssh

Si vous avez modifié le port SSH, il faudra vous reconnecter en utilisant le nouveau port.

C. Empêcher la connexion de l'utilisateur root en SSH

Même si depuis bien des années maintenant, la connexion de l'utilisateur root est désactivée par défaut dans la configuration SSH, il se peut que sur certaines vieilles bécanes, le processus d'authentification du super-utilisateur soit actif. Pour cela, recherchez la ligne suivante, et affectez lui la valeur No :

PermitRootLogin No

III. Sécuriser l'authentification par mot de passe classique

Depuis que l'authentification par clé publique/privée existe, cette méthode est de moins en moins utilisée et déconseillée (car trop sensible aux attaques par brute force si le service SSH est mal configuré).

Toutefois, dans certains cas pour des serveurs n'étant pas hautement stratégiques, et non atteignables depuis internet, nous pouvons garder la méthode d'authentification classique. Dans cette partie, nous allons voir comment sécuriser cette méthode d'authentification.

A. Autoriser seulement la connexion pour un ou plusieurs utilisateurs.

Dans mon cas, j'ai créé deux utilisateurs en amont :

• tintin
• haddock

sudo nano /etc/ssh/sshd_config

Je vais autoriser seulement tintin à se connecter en SSH sur mon serveur. Ajoutez cette ligne :

AllowUsers tintin

Sauvegardez les changements, et redémarrer votre service SSH.

systemctl restart ssh

Tentez une connexion SSH depuis votre machine cliente en précisant l'utilisateur haddock :

Comme l'utilisateur haddock n'est pas présent dans la liste, il se verra automatiquement refuser la connexion.

Vous préférez spécifier un groupe pour l'autorisation de connexion en SSH ? Ajoutez vos utilisateurs à un groupe, et spécifiez celui-ci dans la configuration de SSH. Par exemple :

AllowGroups MonGroupeSSH

IV. Authentification par clés publique/privée

Comme dit précédemment, il est recommandé d'utiliser une authentification basée sur un couple de clés. Pour ce faire, créez la paire de clés en utilisant la commande suivante (à partir de votre machine cliente) :

ssh-keygen -b 8192

Puis, entrez la commande suivante, afin de copier votre clé publique vers le serveur SSH (en écoute sur le port 2021) depuis votre machine cliente :

ssh-copy-id -p 2021 [email protected]

Bien sûr, l'utilisateur tintin devra s'authentifier afin de pouvoir déposer sa clé SSH. Afin de vérifier que votre clé est bien arrivée sur le serveur SSH, exécutez la commande suivante (vous ne devez plus entrer de mot de passe) :

ssh -p 2021 [email protected]

A. Désactivez l'authentification par mot de passe classique

Afin de durcir la sécurité de notre serveur SSH, nous allons autoriser seulement la connexion par clé publique/privée. Décommentez la ligne suivante dans le fichier et changer la valeur du paramètre "PasswordAuthentication" de yes à no :

sudo nano /etc/ssh/sshd_config

PasswordAuthentication no

Puis, redémarrez le service SSH.

sudo systemctl restart ssh

Si vous tentez de vous connecter sans fournir une clé privée, pour le processus d'authentification, une erreur sera retournée. Pour réaliser ce test, je bascule en root sur la machine cliente Kali, et j'essaie de me connecter :

Note : dans certains cas d'utilisation, il se peut que vous deviez mettre en place une authentification 2FA (double authentification). Je vous laisse consulter l'article suivant (en anglais) : SSH - Authentification à deux facteurs.

V. Pour aller plus loin :

Pour aller plus loin, et notamment lutter contre les attaques brutes à destination du service SSH, vous pouvez miser sur Fail2ban ou CrowdSec pour protéger le service. Voici deux tutoriels qui devraient vous aider :

• SSH - Fail2ban
• CrowdSec - Fail2ban

Et si vraiment SSH est un sujet qui vous intéresse et que vous souhaitez apprendre à le configurer plus précisément, je vous invite à lire notre cours sur le SSH : Cours gratuit SSH.

Geoffrey Sauvageot-Berland Ingénieur Cybersécurité

Ingénieur diplômé par l’état en Informatique et Cybersécurité. Généraliste, à l'origine administrateur systèmes et réseaux, j’occupe actuellement un poste d’auditeur en sécurité offensive. J’apprécie également la programmation/automatisation. Fondateur du blog : "Le Guide du SecOps", anciennement "Le Guide du SysOps"

See Full Bio