– 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.
–> 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
– 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 :
– Pour cela, nous allons modifier le fichier %(#ff0000)[/etc/ssh/sshd_config] de notre serveur SSH. Editez ce fichier avec votre éditeur préféré :
sudo nano /etc/ssh/sshd_config
– 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
– 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 %(#ff0000)[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.
– 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
– Pour un site sur lequel on travaille, c’est un peu pénible de ne pas pouvoir se connecter en root, on pourrait être tenté d’activer l’accès root mais je le déconseille.
A savoir que si la connexion root vous est nécessaire, elle demeure toutefois une faille de sécurité potentielle.
– 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.
– Dans mon cas, j’ai créé deux utilisateurs en amont :
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
– Il existe un moyen radical de sécuriser notre connexion : en autorisant uniquement la connexion de l’utilisateur « root » à l’aide d’une clé RSA !
On coupe court à toutes les attaques de type « brute force » (type d’attaque qui utilise toutes les combinaisons possibles pour se connecter).
– La clé qu’on va générer, il faut vraiment la voir comme la clé d’une maison : si on ne l’a pas, on ne rentre pas. Donc triple backup, s’il vous plaît, ne la perdez pas !
PS : si jamais vous la perdez quand même, il existe en général une console d’urgence chez votre hébergeur qui permet de retrouver son accès en éditant le fichier de configuration de SSH.
– 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, c’est à dire la machine avec laquelle vous allez vous connecter au serveur :
ssh-keygen -b 8192
– Si la machine utilisée sera sous Windows vous pouvez générer une paire de clé via Putty.
– Une fois le logiciel installé, utilisez l’utilitaire intitulé Puttygen, dans le dossier créé par l’installateur.
– Copiez L’ensemble du texte généré dans la fenêtre du haut, et conservez le dans un fichier texte que vous appellerez public-key.txt. Puis entrer un mot de passe à la ligne Key passphrase.
– Confirmez-le sur la ligne du dessous. Ce mot de passe, il ne faudra pas le perdre : vous en aurez besoin quand vous voudrez charger votre clé privée. Si jamais vous vous faites voler votre clé privée, sans le mot de passe, elle sera tout simplement inutilisable.
– Puis, cliquez sur le bouton Save private key et enregistrez la sur votre ordinateur:
–> Tous ces fichiers doivent être sauvegardés et conservés précieusement, car sans clé, pas de connexion possible.
– 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]
– Si vous avez généré une paire de clé sous Windows, il va falloir la déclarer sur le serveur manuellement.
Cela va se passer au niveau du homefolder du login qui va se présenter soit ici /home/tintin
– Dans ce répertoire du home, il faut qu’un répertoire .ssh existe et qu’il contienne un fichier nommé authorized_keys
– Donc il faut se logger avec le compte pour lequel on veut s’authentifier avec un certificat et créer le répertoire .ssh avec cette commande
mkdir ~/.ssh
– Pour être certain, déplacez vous dans le répertoire:
cd ~
cd /home/tintin
– Modifier les droits du répertoire .ssh avec la commande:
chmod 700 .ssh
– Entrer dans le répertoire .ssh:
cd .ssh
– Il faut ajouter votre clé publique dans un fichier nommé authorized_keys qui n’existe pas forcément.
– Pour cela on va utiliser la commande echo à laquelle on demandera d’ajouter la clé publique dans le fichier authorized_keys.
La commande écho délimite le début et la fin de la clé par " et "
La clé publique doit être en une seule ligne, sans retour à la ligne etc
– Pour copier la clé publique, dans puttygen, faire un clic droit sur cette dernière et choisir Tout sélectionner
– Refaire un clic droit et copier toute la clé publique:
– Côté serveur, coller la clé publique entre les 2 " "
– La commande à adapter avec votre clé publique est donc:
echo "votreclépublique" >> authorized_keys
– Modifiez les droits de authorized_keys avec la commande
chmod 600 authorized_keys
IMPORTANT: Tester le nouvel accès par clé sans couper la connexion SSH déjà ouverte en cas de soucis.
– 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 :
– 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. Ma préférence va à CrowdSec qui est bien plus moderne/efficace et léger.
– Voici deux tutoriels qui devraient vous aider :
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