Configuration d'un serveur SSH

SSH, ou Secure Shell, est un protocole permettant d’établir une communication chiffrée, donc sécurisée qui permet aux administrateurs d’accéder à distance à des serveurs.

SSH (Secure Shell) opère principalement dans la couche application du modèle OSI (Open Systems Interconnection) et utilise le protocole TCP (Transmission Control Protocol) au niveau de la couche transport pour établir une connexion fiable et sécurisée entre le client et le serveur.

Histoire

L’histoire de SSH (Secure Shell) remonte au milieu des années 1990 et est étroitement liée à l’évolution de la sécurité Internet. Voici un aperçu de son développement :

1. Origines (1995) : SSH a été créé par Tatu Ylönen, un chercheur en sécurité informatique de l’Université de Technologie d’Helsinki, en réponse à une attaque par écoute (“sniffing attack”) sur le réseau de son université. Cette attaque a mis en évidence les vulnérabilités des protocoles de connexion à distance existants, comme Telnet et Rlogin, qui ne chiffraient pas leurs communications.

2. SSH-1 (1995) : La première version de SSH (SSH-1) a été développée pour remplacer ces protocoles non sécurisés. Elle offrait un cryptage des communications, empêchant ainsi l’interception des données transmises entre l’hôte et le client. SSH-1 est rapidement devenu populaire dans les communautés universitaires et scientifiques.

3. SSH-2 (1996) : Une nouvelle version, SSH-2, a été introduite pour corriger des vulnérabilités de sécurité dans SSH-1. SSH-2 n’était pas rétrocompatible avec SSH-1, mais apportait des améliorations significatives, notamment une architecture plus modulaire et un cryptage plus robuste.

4. Commercialisation (1996) : Tatu Ylönen a fondé SSH Communications Security pour commercialiser le protocole SSH. La société a développé des versions propriétaires de SSH, mais la version originale est restée open-source.

5. OpenSSH (1999) : Face à la version propriétaire de SSH, la communauté open-source a créé OpenSSH, un fork gratuit et open-source de SSH développé par le projet OpenBSD ↗. OpenSSH est devenu la version la plus utilisée de SSH et est intégré dans de nombreuses distributions Linux et systèmes Unix.

6. Évolution Continue : SSH continue d’évoluer, avec des améliorations constantes en matière de sécurité et de fonctionnalités. De nouvelles méthodes d’authentification, des algorithmes de cryptage plus robustes et des fonctionnalités avancées comme le tunneling et le port forwarding sont régulièrement ajoutés.

Installation de SSH

L’installation de SSH varie légèrement selon la distribution Linux que vous utilisez. Voici les étapes pour les distributions les plus courantes.

Sur Debian et Ubuntu

Ouvrez votre terminal et exécutez la commande suivante pour installer le serveur SSH :

sudo apt update
sudo apt install openssh-server fail2ban

Une fois l’installation terminée, le service SSH devrait démarrer automatiquement.

Sur Fedora et CentOS

Ouvrez votre terminal et exécutez la commande suivante pour installer le serveur SSH :

sudo dnf install openssh-server fail2ban

Sur OpenSuse

Ouvrez votre terminal et exécutez la commande suivante pour installer le serveur SSH :

sudo zypper update
sudo zypper install openssh-server fail2ban

Gestion du service sshd

1. Démarrer et Activer le Service SSH : Une fois installé, vous devez démarrer le service SSH et l’activer pour qu’il démarre automatiquement lors du démarrage du système. Utilisez les commandes suivantes :

   sudo systemctl start sshd
   sudo systemctl enable sshd

2. Vérifier le Statut du Service : Pour vous assurer que le service SSH fonctionne correctement, vérifiez son statut avec :

   sudo systemctl status sshd
    ● ssh.service - OpenBSD Secure Shell server
        Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
        Active: active (running) since Sat 2023-12-02 13:52:08 CET; 2 days ago
          Docs: man:sshd(8)
                man:sshd_config(5)
        Process: 656 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
      Main PID: 678 (sshd)
          Tasks: 1 (limit: 21485)
        Memory: 15.7M
            CPU: 12.151s
        CGroup: /system.slice/ssh.service
                └─678 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"
   
    déc. 04 14:25:31 internal sshd[53852]: pam_unix(sshd:session): session opened for user bob(uid=1000) by (uid=0)
    déc. 04 14:25:31 internal sshd[53852]: pam_unix(sshd:session): session closed for user bob
    déc. 04 16:20:17 internal sshd[78083]: Accepted publickey for bob from 172.31.208.1 port 55470 ssh2: RSA SHA256:i/cP6dWYgNI419VoENjOZr0yRuPwXVsDN3/9UEV6yt4
    déc. 04 16:20:17 internal sshd[78083]: pam_unix(sshd:session): session opened for user bob(uid=1000) by (uid=0)
    déc. 04 16:20:22 internal sshd[78157]: Accepted publickey for bob from 172.31.208.1 port 55511 ssh2: RSA SHA256:i/cP6dWYgNI419VoENjOZr0yRuPwXVsDN3/9UEV6yt4
    déc. 04 16:20:22 internal sshd[78157]: pam_unix(sshd:session): session opened for user bob(uid=1000) by (uid=0)
    déc. 05 08:00:02 internal sshd[78345]: Accepted publickey for bob from 172.31.208.1 port 55553 ssh2: RSA SHA256:i/cP6dWYgNI419VoENjOZr0yRuPwXVsDN3/9UEV6yt4
    déc. 05 08:00:02 internal sshd[78345]: pam_unix(sshd:session): session opened for user bob(uid=1000) by (uid=0)
    déc. 05 08:19:24 internal sshd[82354]: Accepted publickey for bob from 172.31.208.1 port 56798 ssh2: RSA SHA256:i/cP6dWYgNI419VoENjOZr0yRuPwXVsDN3/9UEV6yt4
    déc. 05 08:19:24 internal sshd[82354]: pam_unix(sshd:session): session opened for user bob(uid=1000) by (uid=0)
    bob@internal ~/Projects/perso/my-blog dev* ❯                                                                                                            08:31:19

Astuce

Pour en apprendre plus sur la gestion des services Linux, c’est par là !

Configuration de ssh

Après avoir installé SSH, il est important de le configurer correctement pour assurer une sécurité optimale, c’est ce qu’on appelle le durcissement. Voici les étapes pour configurer SSH sur votre serveur Linux.

Astuce

Pour vous entrainer à configurer le serveur ssh je vous conseille d’utiliser des serveurs de tests que vous aurez par exemple provisionnées avec Vagrant. Pour vous connecter, il faudra plutôt utiliser la commande ssh vagrant@ip que vagrant ssh. Le mot de passe par défaut est vagrant.

Accès au Fichier de Configuration

Le fichier de configuration principal pour SSH est /etc/ssh/sshd_config.

Astuce

Par contre, une meilleure pratique est de créer un fichier dans le répertoire /etc/ssh/sshd_config.d.

L’utilisation d’une structure de répertoires *.d pour la configuration de SSHD offre plusieurs avantages, notamment en termes de modularité, de maintenabilité et d’évolutivité :

1. Modularité :

   • Simplicité de Gestion : Les configurations sont plus faciles à gérer et à comprendre car elles sont réparties en fichiers plus petits et plus ciblés.
   • Personnalisation Facile : Permet d’ajouter, de modifier ou de supprimer des paramètres spécifiques sans avoir à parcourir un long fichier de configuration.

2. Maintenabilité :

   • Moins de Conflits lors des Mises à Jour : Diminue le risque de conflits lors des mises à jour du package SSH, car le fichier principal sshd_config est moins susceptible d’être modifié directement.
   • Facilité de Suivi : Les changements individuels sont plus faciles à suivre et à documenter lorsqu’ils sont isolés dans des fichiers séparés.

3. Évolutivité :

   • Déploiement Automatisé : Simplifie le processus de réplication des configurations sur plusieurs systèmes, ce qui est particulièrement utile dans les environnements DevOps et pour la gestion centralisée des configurations.
   • Adaptabilité : Permet une adaptation rapide aux nouvelles exigences ou changements, en ajoutant ou en modifiant simplement un fichier spécifique sans perturber l’ensemble de la configuration.

Pour le créez, ouvrez le avec un éditeur de texte en tant que root, par exemcréer

sudo vi /etc/ssh/sshd_config.d/hardening.conf

Si vous n’êtes pas à l’aise avec l’éditeur vi, remplacez le par nano.

Paramètres Importants à Configurer

Note

Nous ne verrons ici que les paramètres les plus importants. Vous pouvez consulter cette documentation sur pour aller plus loin dans ce durcissement d’OpenSSH.

Pour des raisons de sécurité, il est recommandé de désactiver l’accès SSH direct pour l’utilisateur root. Ajoutez la ligne PermitRootLogin no.

L’authentification par clé publique est plus sécurisée que l’authentification par mot de passe. Ajoutez la ligne PubKeyAuthentication yes.

Ce qui donne :

PermitRootLogin no
PubkeyAuthentication yes

Après avoir effectué les modifications, sauvegardez le fichier et quittez l’éditeur de texte. Pour que les changements prennent effet, redémarrez le service SSH :

sudo systemctl reload sshd

Vérification de l’application des paramètres

Pour afficher les paramètres actifs, il suffit d’utiliser la commande suivante :

sudo sshd- T
port 22
addressfamily any
listenaddress [::]:22
listenaddress 0.0.0.0:22
usepam yes
logingracetime 120
x11displayoffset 10
maxauthtries 5
maxsessions 10
clientaliveinterval 0
clientalivecountmax 2
...

permitopen any
permitlisten any
permituserenvironment no
pubkeyauthoptions none

Sécurisation Avancée de SSH

Après avoir configuré le service SSH, il est essentiel d’adopter des mesures de sécurité avancées pour renforcer la protection de votre serveur. Voici comment utiliser les pare-feu firewalld ou ufw pour sécuriser votre serveur SSH.

Configuration du Pare-feu avec UFW (Uncomplicated Firewall)

UFW est un outil de gestion de pare-feu convivial pour les systèmes basés sur Debian et Ubuntu.

Activation de UFW

Activez UFW avec la commande suivante :

sudo ufw enable

Configuration des Règles pour SSH

Autorisez les connexions SSH (sur le port 22 par défaut ou un autre si vous avez modifié le port SSH) :

sudo ufw allow 22/tcp

Ou, si vous avez changé le port SSH :

sudo ufw allow [port]/tcp

Ou si vous voulez restreindre l’accès à des adresses IP spécifiques :

sudo ufw allow from [adresse_ip] to any port [port]

Remplacez [adresse_ip] par l’adresse IP spécifique. Répétez cette commande pour chaque adresse IP autorisée.

Application des Règles

Pour appliquer les modifications, redémarrez UFW :

sudo ufw reload

Configuration du Pare-feu avec firewalld

firewalld est un outil de gestion de pare-feu flexible utilisé sur les distributions Linux à base de Red Hat.

Règles de Base pour SSH

Pour autoriser les connexions SSH (sur le port 22 par défaut), utilisez :

sudo firewall-cmd --zone=public --add-service=ssh --permanent

Ou si vous avez changé le port SSH :

sudo firewall-cmd --zone=public --add-port=[port]/tcp --permanent

Pour appliquer cette régle :

sudo firewall-cmd --reload

Configuration de fail2ban

Le service SSH (Secure Shell) est souvent la cible principale des attaques par force brute, où des assaillants tentent de deviner les identifiants de connexion par des essais répétés. Pour contrer ces menaces, une solution de sécurité robuste et proactive est indispensable. C’est ici que Fail2Ban, un outil de prévention des intrusions, entre en jeu.

Fail2Ban est un logiciel de sécurité qui surveille les journaux de votre système à la recherche de signes d’activités suspectes, en particulier des tentatives de connexion SSH répétées et infructueuses. Lorsqu’un schéma d’attaque est détecté, Fail2Ban intervient automatiquement pour “bannir” l’adresse IP de l’attaquant, en la bloquant temporairement de l’accès au service SSH. Cette action réduit considérablement le risque d’une intrusion réussie, décourageant l’attaquant et protégeant le système contre les accès non autorisés.

Configuration de Base de Fail2Ban

Attention

À manipuler avec précaution ! Pour apprendre je vous conseille de le faire une VM provisionné avec vagrant.

Il est recommandé de ne pas modifier directement le fichier de configuration par défaut jail.conf de Fail2Ban, car il peut être écrasé lors des mises à jour. Créez plutôt un fichier jail.local pour vos configurations personnalisées :

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

Ajoutez les lignes suivantes en adaptant à vos besoins dans la section [sshd]:

[sshd]
enabled = true
ignoreip = 127.0.0.1 192.168.1.0/24
bantime = 180
maxretry = 3

Où :

• ignoreip : Adresses IP à ignorer.
• bantime : Durée du bannissement.
• findtime : Intervalle de temps pendant lequel les échecs sont comptés.
• maxretry : Nombre de tentatives de connexion échouées avant bannissement.

Démarrage et Test de Fail2Ban

Après avoir configuré Fail2Ban, redémarrez le service pour appliquer les changements :

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Vérifier le Statut de Fail2Ban :

Utilisez la commande suivante pour vérifier que Fail2Ban fonctionne correctement :

sudo fail2ban-client status

Status
|- Number of jail:      1
`- Jail list:   sshd

Pour voir les détails de la prison SSH, utilisez :

sudo fail2ban-client status sshd

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     3
|  `- File list:        /var/log/auth.log
`- Actions
   |- Currently banned: 0
   |- Total banned:     1
   `- Banned IP list:

Connexion au Serveur SSH

Une fois SSH installé et configuré sur votre serveur, la prochaine étape est de se connecter à ce serveur à partir d’un client SSH. Voici comment procéder.

Connexion Basique avec mot de passe

Pour établir une connexion SSH de base, utilisez la commande suivante dans le terminal de votre client (remplacez utilisateur, adresse_ip et port par vos propres valeurs) :

ssh utilisateur@adresse_ip -p port

Par exemple :

ssh bob@192.168.1.10 -p 22

Utilisation de la Clé Publique pour l’Authentification

Pour une sécurité optimale dans SSH, les types de clés recommandés ont évolué au fil du temps avec l’avancement de la technologie cryptographique. Actuellement, les types de clés les plus sécurisés sont :

1. Ed25519 : C’est un type de clé basé sur l’algorithme de signature numérique EdDSA utilisant Curve25519. Il est reconnu pour sa performance et sa sécurité robuste, tout en ayant une taille de clé relativement petite, ce qui le rend rapide.
2. RSA : Les clés RSA restent largement utilisées et sont considérées comme sûres avec une longueur de clé suffisante. Actuellement, une clé RSA devrait être d’au moins 2048 bits, bien que 4096 bits soient souvent recommandés pour une sécurité accrue.

Voici une liste des paramètres les plus importants de la commande ssh-keygen:

• -t : Spécifie le type de clé à générer (par exemple, rsa, dsa, ecdsa, ed25519).
• -b : Définit le nombre de bits dans la clé, utilisé pour augmenter la sécurité de la clé (par exemple, 2048, 4096).
• -C : Permet d’ajouter un commentaire à la clé, généralement utilisé pour l’adresse e-mail ou l’identifiant de l’utilisateur.
• -f : Spécifie le nom du fichier dans lequel enregistrer la clé générée.
• -N : Permet de définir une nouvelle passphrase (mot de passe) pour la clé.
• -p : Change la passphrase d’une clé privée existante.
• -q : Mode silencieux, ne génère pas de sorties non nécessaires.
• -y : Lit une clé privée et produit une clé publique correspondante.

Il est important de noter que d’autres types de clés comme DSA et ECDSA sont également disponibles, mais Ed25519 et RSA avec une longueur de clé suffisante sont généralement privilégiés pour une meilleure sécurité.

Génération d’une clé

Sur votre machine cliente, générez une paire de clés (publique et privée) en utilisant :

ssh-keygen -t ed25519 -C "your_email@example.com" -N ""

Suivez les instructions à l’écran pour spécifier un emplacement de fichier et créer éventuellement un mot de passe pour la clé. Si vous indiquez un mot de passe, notez-le soigneusement, car vous en aurez besoin à chaque connexion.

Copie de la Clé Publique sur le Serveur

Pour copier votre clé publique sur le serveur, utilisez la commande ssh-copy-id :

ssh-copy-id -i ~/.ssh/id_ed25519.pub utilisateur@adresse_ip -p port

Cela ajoutera votre clé publique au fichier ~/.ssh/authorized_keys de l’utilisateur sur le serveur.

Connexion avec la Clé Publique

Maintenant, lorsque vous vous connectez via SSH, le serveur vérifiera votre clé publique. Si elle correspond à la clé privée sur votre client, vous serez connecté sans avoir besoin d’un mot de passe.

Astuce

À présent que vous avez copié votre clé sur le serveur distant, vous pouvez désactiver la connexion par mot de passe sur le serveur. Pour cela, procédez comme précédemment en changeant la ligne PasswordAuthentication yes en PasswordAuthentication no. Redémarrer le service une fois terminé.

Configuration du client

Lorsque vous êtes amené à vous connecter à de nombreux serveurs, chacun avec ses propres paramètres, ou si vous avez besoin d’effectuer des connexions en cascade, il peut rapidement devenir difficile de se souvenir de tous les détails nécessaires. Dans ces situations, il est recommandé d’utiliser le fichier .ssh/config pour une gestion efficace de ces informations. Ce fichier réside dans un dossier .ssh se trouvant dans votre répertoire personnel.

Syntaxe de base

Typiquement, sur des systèmes Linux ou macOS, vous le trouverez sous /home/votre_nom_utilisateur/.ssh/config, tandis que sur Windows, le chemin correspondant est C:\Users\votre_nom_utilisateur\.ssh\config.

La structure de base du fichier est simple : chaque bloc de configuration commence par le mot-clé Host, suivi du nom de l’hôte ou d’un alias que vous définissez pour le serveur. Ce nom est celui que vous utiliserez dans la commande ssh pour initier une connexion.

Par exemple :

Host serveurweb
    HostName serveurweb.exemple.com
    User admin

Host datalab
    HostName 192.168.1.100
    User admin

Dans cet exemple, serveurweb est l’alias que vous utilisez pour la connexion. HostName spécifie l’adresse réelle du serveur et User définit le nom d’utilisateur à utiliser pour la connexion.

Il est important de noter que .ssh/config est sensible à la casse et doit être correctement formaté pour fonctionner comme prévu. Les espaces et l’indentation (généralement des espaces) sont utilisés pour distinguer les directives appartenant à chaque hôte.

Utilisation des jokers

L’astérisque * dans le fichier .ssh/config permet de spécifier des paramètres de configuration de manière globale. Cela signifie que les options définies sous un bloc Host * seront appliquées à toutes les connexions SSH, à moins qu’elles ne soient explicitement redéfinies dans des blocs Host spécifiques.

Exemple de Configuration Globale :

Host *
    Compression yes
    ServerAliveInterval 60
    ForwardX11 no

Dans cet exemple, plusieurs options sont définies pour s’appliquer à toutes les connexions SSH :

• Compression : L’activation de la compression (Compression yes) est utile pour des connexions plus rapides, en particulier sur des liaisons avec des débits limités ou des latences élevées.
• ServerAliveInterval : Cette option (ServerAliveInterval 60) configure l’envoi d’un message au serveur toutes les 60 secondes. C’est un moyen efficace de maintenir des connexions inactives ouvertes, évitant ainsi les déconnexions automatiques dues à l’inactivité.
• ForwardX11 : En définissant ForwardX11 no, le transfert X11 est désactivé par défaut pour toutes les connexions. Le transfert X11 peut être activé pour des hôtes spécifiques si nécessaire.

L’autre joker est ? qui représente un seul caractère. Par exemple, Host ?.example.com correspondra à a.example.com, b.example.com, mais pas à ab.example.com.

La négation

L’utilisation de la négation dans le fichier de configuration client SSH (~/.ssh/config) est une fonctionnalité qui vous permet d’exclure spécifiquement certains hôtes des règles générales définies dans le fichier. Cela est souvent utilisé en combinaison avec des configurations globales pour appliquer des exceptions à ces règles.

Dans le fichier ~/.ssh/config, vous pouvez définir des règles générales pour tous les hôtes en utilisant Host * et ensuite utiliser la négation pour exclure certains hôtes de ces règles. La syntaxe pour la négation est Host !<nom_du_hôte>.

Voici un exemple pour illustrer l’utilisation de la négation :

# Configuration globale pour tous les hôtes
Host *
    Compression yes
    ForwardX11 no

# Exclusion pour un hôte spécifique
Host !serveursensible.exemple.com

Dans cet exemple, la compression et la désactivation du transfert X11 sont appliquées à toutes les connexions, sauf celles effectuées vers serveursensible.exemple.com. Lorsque vous vous connectez à serveursensible.exemple.com, SSH ignore les configurations sous Host * et utilise uniquement les configurations spécifiques définies pour serveursensible.exemple.com (si elles existent) ou les valeurs par défaut.

Commande à Exécuter sur le Serveur Distant

L’une des fonctionnalités avancées du fichier .ssh/config est la possibilité de spécifier une commande à exécuter immédiatement après la connexion au serveur distant. Cette fonctionnalité, désignée par la directive RemoteCommand, offre un moyen d’automatiser les tâches et de simplifier les processus répétitifs.

Utilité de RemoteCommand :

• Automatisation : Permet d’exécuter automatiquement des scripts ou des commandes spécifiques dès que la connexion SSH est établie.
• Gain de Temps : Élimine le besoin de saisir manuellement des commandes fréquemment utilisées après chaque connexion.
• Personnalisation : Offre la possibilité de personnaliser l’environnement de travail en fonction des besoins spécifiques de l’utilisateur ou du serveur.

Configuration de RemoteCommand : Pour utiliser RemoteCommand, ajoutez la directive dans le fichier de configuration SSH du client avec la commande souhaitée. Par exemple :

Host serveurweb
    HostName exemple.com
    User admin
    RemoteCommand cd /var/www && ls

Dans cet exemple, lorsque vous vous connectez au serveurweb, SSH exécutera automatiquement la commande cd /var/www && ls, vous amenant directement dans le répertoire du serveur web et listant son contenu.

Points à Considérer :

• Compatibilité : Toutes les versions de SSH ne supportent pas RemoteCommand. Assurez-vous que votre client et serveur SSH sont compatibles avec cette fonctionnalité.
• Sécurité : Soyez prudent avec les commandes que vous configurez pour s’exécuter automatiquement. Évitez les commandes qui pourraient compromettre la sécurité ou l’intégrité du système.
• Flexibilité : RemoteCommand est exécutée dans le contexte de la session SSH, ce qui signifie que vous pouvez utiliser toutes les variables et paramètres disponibles dans cette session.

Lecture du fichier par le client

Lorsque vous lancez une commande SSH, le client SSH commence par ouvrir et parcourir le fichier .ssh/config, le lisant de manière séquentielle, de haut en bas. Il recherche les blocs Host qui correspondent au nom d’hôte spécifié dans la commande. Ce processus implique une correspondance de motifs, où le client SSH compare le nom d’hôte utilisé dans la commande avec les motifs définis sous les différentes entrées Host dans le fichier .ssh/config.

Si une correspondance est trouvée, SSH applique les configurations définies dans ce bloc. Dans le cas où plusieurs blocs correspondent (par exemple, un bloc avec un joker * et un autre avec le nom d’hôte spécifique), SSH applique la première configuration correspondante trouvée. Cependant, en cas de surcharge, où les paramètres pour un hôte spécifique sont définis après les paramètres généraux, le client SSH donne la priorité aux configurations les plus spécifiques. Ainsi, même si des paramètres généraux sont définis au début du fichier, ils seront surchargés par des paramètres plus spécifiques pour un hôte donné rencontrés plus loin dans le fichier.

Cela signifie que le client SSH construit un ensemble de configurations pour chaque connexion en combinant les paramètres généraux avec les paramètres spécifiques à l’hôte, en donnant la priorité aux derniers. Cette méthode permet une grande flexibilité et une personnalisation fine des connexions SSH, facilitant la gestion de configurations multiples et complexes dans un seul fichier bien organisé.

Host *
    Compression yes
    ServerAliveInterval 60

Host serveurspecial
    Compression no
    ServerAliveInterval 20

Les principales options

1. Host : Définit un alias pour un hôte, facilitant la connexion à celui-ci avec un nom simple.
2. HostName : Spécifie l’adresse réelle ou le nom de domaine du serveur auquel se connecter.
3. User : Détermine le nom d’utilisateur par défaut pour la connexion SSH.
4. Port : Permet de spécifier un port SSH autre que le port par défaut (22).
5. IdentityFile : Indique l’emplacement du fichier de clé privée à utiliser pour la connexion.
6. ServerAliveInterval : Définit un intervalle en secondes pour envoyer un message de maintien de connexion au serveur, utile pour garder des sessions inactives ouvertes.
7. ServerAliveCountMax : Détermine le nombre de messages de maintien de connexion à envoyer sans réponse du serveur avant de fermer la connexion.
8. Compression : Active ou désactive la compression des données pendant la transmission.
9. CompressionLevel : Permet de spécifier le niveau de compression (généralement entre 1 et 9).
10. StrictHostKeyChecking : Permet de gérer la manière dont SSH vérifie la clé d’hôte du serveur distant.
11. UserKnownHostsFile : Spécifie l’emplacement du fichier contenant les clés des hôtes connus.
12. RemoteCommand : Définit une commande à exécuter immédiatement après la connexion au serveur distant.
13. ForwardAgent : Active ou désactive le transfert de l’agent d’authentification SSH, utile pour les scénarios de saut entre plusieurs serveurs.

Ces options offrent une grande flexibilité pour optimiser et sécuriser vos connexions SSH, en adaptant chaque connexion à vos besoins spécifiques.

# Configuration globale applicable à tous les hôtes
Host *
    Compression yes
    ServerAliveInterval 30
    IdentityFile ~/.ssh/id_ed25519

# Configuration spécifique pour un serveur web
Host serveurweb
    HostName serveurweb.exemple.com
    User webadmin
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_serveurweb

# Configuration pour un serveur de données
Host dataserver
    HostName dataserver.exemple.com
    User datauser
    Port 2200
    Compression no
    ServerAliveInterval 15

# Configuration pour un serveur accessible via un saut (ProxyJump)
Host serveurfinal
    HostName serveurfinal.exemple.com
    ProxyJump serveurintermediaire
    User finaluser

# Configuration pour un serveur intermédiaire utilisé pour ProxyJump
Host serveurintermediaire
    HostName intermediaire.exemple.com
    User interuser

L’optimisation des connexions

ControlMaster est une option de configuration dans SSH qui permet de réutiliser une connexion SSH existante pour établir de nouvelles connexions SSH au même hôte. Cela réduit le temps nécessaire pour établir de nouvelles connexions après la première, car il n’est pas nécessaire de renégocier la connexion et l’authentification. Lorsque vous vous connectez pour la première fois à un hôte, SSH établit une connexion complète, y compris l’authentification. Avec ControlMaster activé, cette connexion initiale peut servir de « tunnel » pour d’autres connexions au même hôte.

Un exemple :

Host *.example.com
    User monutilisateur
    IdentityFile ~/.ssh/id_ed25519
    ControlMaster auto
    ControlPath ~/.ssh/cm-%r@%h:%p
    ControlPersist 5m

Le paramètre ControlMaster auto permet de réutiliser les connexions existantes. ControlPath spécifie le chemin d’un fichier socket utilisé pour gérer les connexions partagées. ControlPersist 600 indique que la connexion maître reste active 600 secondes (10 minutes) après la dernière connexion client, ce qui permet de réutiliser la connexion maître pour d’autres sessions SSH pendant cette période.

Dans le chemin définit dans le paramêtre ControlPath, il est fait appel à des variables dont voici les principales :

• %L : Le premier composant du nom d’hôte local (local hostname). Utile si votre nom d’hôte local contient des points.
• %l : Le nom d’hôte local complet (FQDN). C’est le nom d’hôte canonique, qui peut être utile pour les scripts ou les configurations qui dépendent du nom de domaine complet.
• %n : Le nom d’hôte original tel que spécifié sur la ligne de commande SSH.
• %p : Le numéro de port utilisé pour la connexion SSH.
• %r : Le nom d’utilisateur distant (remote user) pour la connexion SSH.
• %h : Le nom d’hôte du serveur auquel vous vous connectez.
• %C : Un hachage de la chaîne %l%h%p%r. Utile pour créer des chemins uniques de manière concise.
• %i : L’ID de l’utilisateur local.
• %d : Le répertoire personnel de l’utilisateur local.
• %u : Le nom d’utilisateur local.
• %T : Le fichier temporaire utilisé pour les contrôles maître.

Ces variables fournissent une flexibilité considérable pour configurer les chemins de fichiers et autres options dans SSH, permettant une personnalisation adaptée à divers scénarios et environnements de réseau. Elles sont particulièrement utiles pour des configurations complexes où vous devez gérer de multiples connexions SSH de manière dynamique et automatisée.

Sécurité : Bien que pratique, cette fonctionnalité peut présenter des risques de sécurité si le fichier socket est accessible à des utilisateurs non autorisés. Assurez-vous que le fichier socket est bien protégé.

Debug de connexions SSH

Le débogage des connexions SSH peut être complexe, mais en comprenant les mécanismes sous-jacents et en adoptant une approche méthodique, vous pouvez identifier et résoudre efficacement la plupart des problèmes. SSH (Secure Shell) est un protocole pour sécuriser les connexions réseau, mais divers problèmes peuvent survenir, allant des erreurs de configuration à des problèmes de réseau.

La complexité du débogage SSH provient de plusieurs facteurs :

• Configuration Multiple : SSH implique des configurations à la fois sur le serveur et le client, chacune pouvant être source d’erreurs.
• Problèmes de Réseau : Des problèmes tels que les pare-feu, la redirection de ports ou les problèmes de connectivité réseau peuvent affecter SSH.
• Authentification : Les problèmes d’authentification, y compris les clés SSH, les mots de passe et les permissions, sont des sources courantes de problèmes.
• Messages d’Erreur Vagues : Parfois, SSH ne fournit pas des informations d’erreur suffisamment détaillées, rendant le diagnostic difficile.

Étapes de Débogage de Base

Erreur Man in The Middle

Dans un contexte dynamique, où les serveurs virtuels peuvent être dynamiques en réutilisant les mêmes adresses IP, vous risquez de voir apparaître ce message d’erreur SSH relatif à une attaque de type “Man-in-the-Middle” :

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Voici comment cela se produit et ce que cela signifie :

1. Enregistrement des Clés d’Hôte SSH : Lorsque vous vous connectez pour la première fois à un serveur SSH, la clé d’hôte du serveur est enregistrée dans le fichier known_hosts sur le client. Cette clé est associée à l’adresse IP ou au nom d’hôte du serveur.

2. Changement d’Adresse IP : Dans un environnement dynamique, si un serveur est arrêté puis redémarré, ou si une nouvelle instance est créée, il peut se voir attribuer une nouvelle adresse IP. Si vous essayez de vous connecter à la nouvelle adresse IP, SSH recherche la clé d’hôte correspondante dans le fichier known_hosts.

3. Détection d’une Potentielle Attaque MitM : Si SSH trouve une entrée pour l’adresse IP dans le fichier known_hosts mais que la clé d’hôte ne correspond pas à celle enregistrée, il génère un avertissement de sécurité. SSH considère cela comme une possible attaque Man-in-the-Middle, car il semble que l’identité du serveur ait changé.

Si vous êtes sûr que le changement d’adresse IP est légitime et non le résultat d’une attaque MitM, vous pouvez résoudre ce problème en supprimant l’ancienne entrée pour cette adresse IP du fichier known_hosts. Ceci peut être fait avec la commande suivante (remplacez adresse.ip par la véritable adresse IP) :

ssh-keygen -t ed25519 -f "~/.ssh/known_hosts" -R adresse.ip

Après cela, lors de la prochaine tentative de connexion, SSH demandera de vérifier et d’accepter la nouvelle clé d’hôte pour cette adresse IP.

Vérifiez la Connectivité Réseau

Assurez-vous que le serveur est accessible depuis le client. Utilisez des commandes comme traceroute, netcat ou lsof pour tester la connectivité.

Fixer les problèmes de droits coté client

Pour configurer les permissions correctes sur les fichiers et répertoires liés à SSH dans votre répertoire .ssh, il est important de suivre des règles strictes, car SSH est très sensible aux permissions. Voici les commandes nécessaires pour définir ces permissions sous un environnement Unix ou Linux :

1. Permissions pour le Répertoire .ssh : Le répertoire .ssh doit avoir des permissions restreintes, de sorte que seul l’utilisateur puisse lire, écrire et exécuter. Utilisez la commande suivante :

chmod 700 ~/.ssh

2. Permissions pour les Clés Privées : Les clés privées dans .ssh doivent également être protégées. Seul l’utilisateur doit avoir des droits de lecture et d’écriture. Exécutez cette commande pour chaque clé privée (par exemple, id_ed25519) :

chmod 600 ~/.ssh/id_ed25519

3. Permissions pour les Clés Publiques et Autres Fichiers : Les clés publiques (comme id_ed25519.pub) et d’autres fichiers comme config ou known_hosts peuvent avoir des permissions un peu moins restrictives, permettant la lecture par l’utilisateur. Utilisez cette commande :

chmod 644 ~/.ssh/id_ed25519.pub
chmod 644 ~/.ssh/known_hosts
chmod 644 ~/.ssh/config

4. Permissions pour les Fichiers authorized_keys : Si vous utilisez un fichier authorized_keys pour la gestion des accès SSH, il doit également être protégé. Seul l’utilisateur doit avoir des droits de lecture et d’écriture sur ce fichier :

chmod 600 ~/.ssh/authorized_keys

Debogage coté client

Si tous les points ci-dessus sont OK et que la connexion ne se fait toujours pas. Utilisez l’option -v (verbose) avec la commande SSH pour obtenir des informations détaillées sur le processus de connexion. Pour plus de détails, utilisez -vv ou -vvv.

Un exemple de connexion en mode verbose depuis une machine Windows

ssh -v internal
OpenSSH_for_Windows_8.6p1, LibreSSL 3.4.3
debug1: Reading configuration data C:\\Users\\SROBERT/.ssh/config
debug1: C:\\Users\\SROBERT/.ssh/config line 2: Applying options for internal
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to internal.mshome.net [172.31.213.180] port 22.
debug1: Connection established.
debug1: identity file C:\\Users\\SROBERT/.ssh/id_ed25519 type 0
debug1: identity file C:\\Users\\SROBERT/.ssh/id_ed25519-cert type -1
debug1: identity file C:\\Users\\SROBERT/.ssh/id_dsa type -1
debug1: identity file C:\\Users\\SROBERT/.ssh/id_dsa-cert type -1
debug1: identity file C:\\Users\\SROBERT/.ssh/id_ecdsa type -1
debug1: identity file C:\\Users\\SROBERT/.ssh/id_ecdsa-cert type -1
debug1: identity file C:\\Users\\SROBERT/.ssh/id_ecdsa_sk type -1
debug1: identity file C:\\Users\\SROBERT/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file C:\\Users\\SROBERT/.ssh/id_ed25519 type -1
debug1: identity file C:\\Users\\SROBERT/.ssh/id_ed25519-cert type -1
debug1: identity file C:\\Users\\SROBERT/.ssh/id_ed25519_sk type -1
debug1: identity file C:\\Users\\SROBERT/.ssh/id_ed25519_sk-cert type -1
debug1: identity file C:\\Users\\SROBERT/.ssh/id_xmss type -1
debug1: identity file C:\\Users\\SROBERT/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_8.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.9p1 Ubuntu-3ubuntu0.4
debug1: compat_banner: match: OpenSSH_8.9p1 Ubuntu-3ubuntu0.4 pat OpenSSH* compat 0x04000000
...

Lisez toutes les lignes, car vous allez comprendre rapidement où le problème se situe.

Debogage coté serveur

Vous avez réglé les problèmes de fichiers de configuration coté client et cela ne fonctionne toujours pas. Consultez les journaux du serveur SSH pour obtenir des indices sur les échecs de connexion. Sur de nombreux systèmes, ces journaux se trouvent dans /var/log/auth.log ou /var/log/secure.

Modifiez temporairement le niveau de journalisation du serveur SSH (LogLevel) pour obtenir plus de détails lors de la connexion.

Un exemple de contenu :

Dec  5 09:24:03 internal sshd[94625]: pam_unix(sshd:session): session opened for user bob(uid=1000) by (uid=0)
Dec  5 09:24:03 internal systemd-logind[613]: New session 47 of user bob.
Dec  5 09:24:03 internal sshd[94645]: Received disconnect from 172.31.208.1 port 58420:11: disconnected by user
Dec  5 09:24:03 internal sshd[94645]: Disconnected from user bob 172.31.208.1 port 58420
Dec  5 09:24:03 internal sshd[94625]: pam_unix(sshd:session): session closed for user bob
Dec  5 09:24:03 internal systemd-logind[613]: Session 47 logged out. Waiting for processes to exit.
Dec  5 09:24:03 internal systemd-logind[613]: Removed session 47.
Dec  5 09:24:12 internal sudo: pam_unix(sudo:session): session closed for user root
Dec  5 10:13:24 internal sshd[106310]: Accepted publickey for bob from 172.31.208.1 port 59430 ssh2: RSA SHA256:i/cP6dWYgNI419VoENjOZr0yRuPwXVsDN3/9UEV6yt4
Dec  5 10:13:24 internal sshd[106310]: pam_unix(sshd:session): session opened for user bob(uid=1000) by (uid=0)
Dec  5 10:13:24 internal systemd-logind[613]: New session 48 of user bob.
Dec  5 10:17:35 internal CRON[106891]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Dec  5 10:17:35 internal CRON[106891]: pam_unix(cron:session): session closed for user root
Dec  5 11:17:01 internal CRON[117833]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Dec  5 11:17:01 internal CRON[117833]: pam_unix(cron:session): session closed for user root
Dec  5 12:01:38 internal sshd[125365]: Accepted publickey for bob from 172.31.208.1 port 61096 ssh2: RSA SHA256:i/cP6dWYgNI419VoENjOZr0yRuPwXVsDN3/9UEV6yt4
Dec  5 12:01:38 internal sshd[125365]: pam_unix(sshd:session): session opened for user bob(uid=1000) by (uid=0)
Dec  5 12:01:38 internal systemd-logind[613]: New session 51 of user bob.

Si vous ne vous voyez pas de connexions provenant de votre adresse IP. Il faudra fouiller dans des problèmes de firewalls.

Conclusion

Maîtriser SSH est une compétence précieuse pour tout professionnel de l’informatique ou utilisateur de Linux. Nous espérons que ce guide vous a aidé à comprendre et à appliquer les principes fondamentaux de SSH pour une utilisation sécurisée et efficace.

L’installation et la configuration correctes de SSH sont des étapes importantes pour assurer une gestion sûre et efficace de vos serveurs Linux. En suivant les instructions fournies dans cette documentation, vous avez appris comment installer SSH sur différentes distributions Linux, comment le configurer pour une sécurité optimale et comment établir une connexion sécurisée avec votre serveur.

La mise en œuvre de l’authentification par clé publique, la modification du port par défaut et la désactivation de l’accès root direct renforcent significativement la sécurité de votre serveur SSH. De plus, la maintenance régulière de votre système et des mises à jour de sécurité contribue à protéger votre infrastructure contre les vulnérabilités connues, OpenSSH étant l’une premières cibles.

Astuce

Si vous souhaitez pousser plus loin votre durcissement d’openSSH, je vous conseille de jeter un œil sur Lynis.

Plus loin

Pour ceux qui utilisent Ansible et qui cherche à améliorer les temps d’exécution des playbooks à destination de nombreuses cibles, je vous propose de lire cette documentation.

Dans une prochaine documentation, nous verrons la mise en place de tunnels, de proxyjump, la limitation des ciphers…