Date de la dernière modification de l’article :

Dans ce tutoriel, nous allons voir comment nous pouvons nous servir du service SSH pour lier de manière chiffrée et sécurisée deux appareils étant dans une relation Client-Serveur pour interagir notamment sur des serveurs locaux à distance et interagir avec l’administration de certains services.

Section 1 : Partie Serveur.

Avant tout, il est important de savoir que le répertoire du service OpenSSH se situe dans /etc/ssh. Par défaut, on y trouve plusieurs fichiers essentiels :

  • moduli : Ce fichier contient des informations utilisées pour le chiffrement. Nous reviendrons plus tard sur les algorithmes de chiffrement employés lors des connexions SSH, mais concentrons-nous d’abord sur ce que l’on peut accomplir avec SSH.
  • ssh_config : Il s’agit du fichier de configuration du client OpenSSH (openssh-client). En effet, SSH repose sur une architecture client-serveur, et par défaut, les composants serveur et client sont installés.
  • sshd_config : Ce fichier configure le serveur OpenSSH. C’est lui qui nous intéressera particulièrement dans cette section.
  • ssh_host_* : Ces fichiers contiennent les clés utilisées lors des processus de chiffrement.

Le principal sous-dossier qui nous intéressera tout le long du tuto sera « sshd_config » dans /etc/ssh/sshd_config car nous retrouveront les principaux fichiers de configuration nécéssaires afin de gérer des paramètres essentiels de notre SSH.

A. Installation de OpenSSH :

Pour installer le serveur ssh sur notre machine, il faudra installer le paquet openssh-server avec cette commande :

sudo apt install openssh-server

B. Fonctionnement de base :

Pour établir une connexion à un système distant via SSH, nous utiliseront la commande ssh. La forme la plus basique de cette commande est :

ssh "adresseip"@"hotedistant"

L’ « adresseip_hotedistant » dans cet exemple, il s’agit de l’adresse IP ou du nom de domaine auquel vous tentez de vous connecter.

Cette commande part du principe que votre nom d’utilisateur sur le système distant est le même que votre nom d’utilisateur sur votre système local.
Ex: si vous êtes en utilisateur courant root sur votre système local, alors la commande tentera de se connecter avec le même utilisateur sur le système distant.

Si votre nom d’utilisateur diffère sur le système distant, vous pouvez le préciser en utilisant la syntaxe suivante (Remplacez « id_hotedistant » par l’identifiant de l’hôte distant) :

ssh "id_hotedistant"@"adresseip_hotedistant"

Pour quitter la session ssh et revenir dans votre session shell locale, tapez simplement :

exit

C. Configuration de SSH :

Il faudra s’assurer en amont que le service se lancera à chaque fois au démarrage du système avec cette commande :

sudo systemctl enable --now ssh.service

Ouvrez le fichier de configuration avec l’éditeur de texte nano :

sudo nano /etc/ssh/sshd_config

Il est préférable d’ignorer la plupart des options de ce fichier de configuration. Cependant, certaines méritent peut-être un peu plus d’approfondissement :

Toujours dans le fichier de configuration, cherchez la ligne suivante

#Elle spécifie simplement sur quel port d'écoute sshd écoutera les connexions, #il est recommandé de modifier ce port pour éviter qu'une multitude de bots #viennent scanner ce port pour rechercher une vulnérabilité de sécurité sur #votre service SSH

Port 2222

Sélectionnez un numéro de port supérieur à 1024. Par exemple, le port 2222.

Il faudra créer l’arborescence du ficher temporaire d’override de la socket SSH avec cette commande :

sudo mkdir /etc/systemd/system/ssh.socket.d/

Ensuite, il faudra éditer et écrire dans le fichier de configuration override 

sudo nano /etc/systemd/system/ssh.socket.d/override.conf

[Socket]
ListenStream=
ListenStream=2222

Une fois que vous avez réussi à modifier le fichier, n’oubliez pas de recharger la configuration du service et de redémarrer le service SSH pour appliquer les changements :

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket

Vérifiez aussi que SSH fonctionne toujours après ces modifications :

sudo systemctl status ssh.socket

Vous pouvez aussi utiliser la commande lsof (List Open Files) pour lister les fichiers ouverts par les processus et identifier celui qui utilise le port 2222 et voyez si c’est bien sshd qui est en écoute dessus.

sudo lsof -i :2222

Retournez dans le fichier de configuration « /etc/ssh/sshd_config », cherchez les lignes suivantes :

LoginGraceTime 120

#Empêche la connection par mot de passe, mettez la valeur "no" a #"PermitRootLogin" sinon mettez la valeur "prohibit-password" si vous voulez #n'autoriser que la connexion avec clé de déchiffrement à l'utilisateur root.

PermitRootLogin no # ou prohibit-password
StrictModes yes

Ces paramètres définissent certaines informations de connexion.

LoginGraceTime spécifie le nombre de secondes pendant lesquelles la connexion reste active sans une authentification réussie. Il est judicieux de fixer ce délai légèrement supérieur au temps qu’il vous faut habituellement pour vous connecter.

PermitRootLogin détermine si l’utilisateur root est autorisé à se connecter. Dans la plupart des cas, il est recommandé de le définir sur « no » une fois que vous avez créé un compte utilisateur avec des privilèges élevés (via su ou sudo) et qui peut se connecter via SSH.

StrictModes est une mesure de sécurité qui refuse une tentative de connexion si les fichiers d’authentification sont accessibles à tous. Cela permet d’éviter les tentatives de connexion lorsque les fichiers de configuration ne sont pas sécurisés.

Encore dans le fichier de configuration, cherchez les lignes suivantes :

X11Forwarding yes
X11DisplayOffset 10

Ces paramètres configurent une fonctionnalité appelée X11 Forwarding, qui permet d’afficher l’environnement graphique (GUI) d’un système distant sur votre système local (inutile si votre hôte distant ne possède aucune composante graphique).

Pour utiliser cette option, elle doit être activée sur le serveur et spécifiée avec le client SSH lors de la connexion en utilisant l’option -X.

ssh -x "id_hotedistant"@"adresseip_hotedistant"

Après avoir apporté vos modifications, enregistrez et fermez le fichier en appuyant sur CTRL+X, puis Y, et enfin ENTER.

Si vous avez modifié des paramètres dans /etc/ssh/sshd_config, n’oubliez pas de redémarrer votre serveur SSH pour appliquer les changements :

sudo systemctl restart ssh

D. Comment se connecter à SSH avec des clés de chiffrement asymétriques :

Bien qu’il soit utile de pouvoir se connecter à un système distant avec des mots de passe, il est bien plus recommandé d’utiliser l’authentification par clé.

L’authentification par clé repose sur la création d’une paire de clés : une clé privée et une clé publique.

La clé privée est conservée sur la machine cliente et doit être gardée secrète et sécurisée.

La clé publique peut être partagée avec n’importe qui ou placée sur n’importe quel serveur auquel vous souhaitez accéder.

Lors d’une tentative de connexion utilisant cette paire de clés, le serveur utilise la clé publique pour générer un message destiné à l’ordinateur client, message qui ne peut être déchiffré qu’avec la clé privée.

L’ordinateur client renvoie ensuite la réponse appropriée au serveur, permettant à ce dernier de vérifier l’authenticité du client.

Ce processus se déroule automatiquement une fois les clés installées.

E. Creation de nos clés SSH :

ssh-keygen -t ed25519 -C "votre_commentaire"

ssh-keygen :

C’est l’outil en ligne de commande utilisé pour générer, gérer et convertir des clés d’authentification pour SSH.

-t ed25519 :

ed25519 : C’est le type de clé que vous souhaitez créer. « ED25519 » est un algorithme de signature numérique basé sur la cryptographie à courbes elliptiques, connu pour sa sécurité et sa performance.
« ED25519 » est principalement utilisé pour la signature numérique et l’authentification. Il est souvent utilisé dans des protocoles comme SSH pour sécuriser les connexions entre les machines.

-t : Cette option spécifie le type de clé à générer.

-C "votre_commentaire" :

-C : Cette option permet d’ajouter un commentaire à la clé générée. Le commentaire est généralement utilisé pour identifier la clé.

F. Processus de génération :

Lorsque vous exécutez cette commande, ssh-keygen vous demandera où enregistrer les clés générées (par défaut, elles seront enregistrées dans ~/.ssh/id_ed25519 et ~/.ssh/id_ed25519.pub), et vous demandera également de définir une phrase secrète, qui est toutefois facultative (passphrase) pour ajouter une couche de sécurité supplémentaire à votre clé privée.

Allons sur mon PC client « PC-SP-ADM02 » pour lui configurer une paire de clés qui serviront à faire la liaison avec mon serveur Zabbix « SRV-SP-ZABBIX » :

Tapez entrée pour qu’il enregistre les clés dans l’emplacement par défaut et choisissez ou non de rentrer une passphrase.

Vous devriez vous retrouver avec une génération de clés qui ressemble à ceci :

Faites les deux commandes suivantes pour vérifier que votre clé publique dispose des bonnes permissions :

cd ~/.ssh

ls -l

Le fichier id_ed25519 est configuré pour être lisible et modifiable uniquement par son propriétaire, ce qui en fait un élément confidentiel. En revanche, le fichier id_ed25519.pub peut être partagé librement, car ses permissions sont adaptées à cette utilisation.

Maintenant transférez votre clé publique vers le serveur distant : « id_hotedistant »@ »adresseip_hotedistant »

Il vous demandera de rentrer le mot de passe utilisateur pour lequel vous avez choisi de copier la clé publique, une fois le mot de passe utilisateur saisi, il vous indiquera qu’une clé à été ajoutée sur la machine distante et qu’il ne vous reste plus qu’a vous connecter avec la commande de base en SSH pour tester la liaison.

G. Désactivation de l’authentification par mot de passe :

Important : Veillez à ce que l’authentification par clé soit opérationnelle avant de désactiver l’authentification par mot de passe.

Si vous avez généré des clés SSH, vous pouvez améliorer la sécurité de votre serveur en désactivant l’authentification par mot de passe seul. Hormis via la console, la seule manière de vous connecter à votre serveur sera d’utiliser la clé privée associée à la clé publique que vous avez installée sur celui-ci.

sudo nano /etc/ssh/sshd_config

Maintenant, trouvez la ligne contenant « Password Authentication », supprimez le premier # pour la décommenter, puis changez sa valeur en « no », puis décommentez aussi la ligne « PubkeyAuthentification » et changez sa valeur en « yes ».

PasswordAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Ensuite relancez le service SSH :

sudo systemctl restart ssh

H. Amélioration de la haute disponibilité de votre liaison SSH :

Timeouts : Le serveur SSH peut être configuré pour fermer les connexions inactives après un certain temps. Vous pouvez ajuster les paramètres ClientAliveInterval et ClientAliveCountMax dans le fichier de configuration du serveur SSH (/etc/ssh/sshd_config) pour éviter cela :

ClientAliveInterval 60
ClientAliveCountMax 3

KeepAlive : Vous pouvez également configurer le client SSH pour envoyer des messages keepalive. Ajoutez les lignes suivantes à votre fichier de configuration client (~/.ssh/config ou /etc/ssh/ssh_config):

ServerAliveInterval 60
ServerAliveCountMax 3

Ensuite relancez le service SSH :

sudo systemctl restart ssh

Section 2 : Connexion côté serveur.

Maintenant, on teste la connexion au serveur. vous verrez que si tout c’est bien déroulé, vous n’aurez pas de mot de passe à rentrer pour accéder à la session distante.

ssh "id_hotedistant"@"adresseip_hotedistant" -p 2222

A. Installer et configurer Fail2ban pour sécuriser SSH :

Après l’installation, il est essentiel de configurer Fail2ban pour sécuriser le service SSH.

Fail2ban est un outil de sécurité qui surveille les journaux de connexion et bloque les adresses IP après un certain nombre de tentatives de connexion échouées, ce qui est particulièrement efficace pour prévenir les attaques par force brute.

sudo apt install fail2ban

Il faudra s’assurer en amont que le service se lancera à chaque fois au démarrage du système avec cette commande :

sudo systemctl enable --now fail2ban.service

Vous allez pouvoir créer une copie du fichier de configuration par défaut (afin de préserver l’original) :

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

Éditez le fichier « jail.local » pour configurer les règles de sécurité SSH :

sudo nano /etc/fail2ban/jail.local

Trouvez la section [sshd] et assurez-vous qu’elle est activée et correctement configurée. Voici un exemple de configuration de base pour sécuriser SSH :

#Vous pouvez personnaliser davantage les règles de bannissement en ajustant #les paramètres
[sshd]
enabled = true
port = 2222  # Assurez-vous que le port est le même que celui défini précédemment
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600

enabled = true : Active la surveillance pour SSH.
port = 2222 : Spécifie le port que Fail2ban doit surveiller (remplacez par votre nouveau port SSH).
maxretry = 3 : Nombre maximal de tentatives de connexion échouées avant que Fail2ban ne bloque l’adresse IP.
bantime = 3600 : Durée du blocage en secondes (ici, 1 heure).

Vérifiez les Permissions du Fichier de Journalisation :

sudo ls -l /var/log/auth.log

Si le fichier n’existe pas ou si les permissions sont incorrectes, vous pouvez les corriger avec les commandes suivantes :

sudo touch /var/log/auth.log
sudo chmod 644 /var/log/auth.log
sudo chown root:adm /var/log/auth.log

Redémarrer Fail2ban pour appliquer les modifications :

sudo systemctl restart fail2ban

Vous pouvez vérifier l’état des jails spécifiquement pour SSH avec la commande suivante:

sudo fail2ban-client status sshd
Steve
Author: Steve