Aller au contenu
DevSecOps Logo DevSecOps Logo DevSecOps
Docs
Blog
Blog

Maîtriser la Connexion aux Serveurs SSH

Mise à jour :

Le SSH, c’est un peu comme le couteau suisse des pros de l’informatique. Que vous soyez admin système, développeur ou que vous gériez des réseaux, c’est devenu un outil indispensable. Imaginez pouvoir accéder à un ordinateur à l’autre bout du monde comme si vous étiez juste devant. Avec SSH, vous pouvez lancer des commandes, envoyer des fichiers, et même gérer des programmes, tout ça de manière super sécurisée. C’est pratique, non ? Plus besoin de se déplacer physiquement pour faire son boulot !

Remarque : Cette documentation se concentre spécifiquement sur le client SSH sans aborder la configuration du serveur SSH et le tunneling SSH, qui sont traités séparément, afin de fournir une vue claire et ciblée sur les autres fonctionnalités essentielles de SSH.

Installation du client SSH

Le client SSH permet d’établir des connexions sécurisées vers des serveurs distants. Son installation varie en fonction du système d’exploitation que vous utilisez.

Sur Linux

La plupart des distributions Linux incluent le client SSH (OpenSSH Client) par défaut. Cependant, si ce n’est pas le cas ou si vous souhaitez installer la dernière version, suivez les instructions spécifiques à votre distribution.

Vérification de l’installation existante

Avant d’installer le client SSH, vérifiez s’il est déjà installé sur votre système :

Terminal window
ssh -V

Si une version s’affiche, le client SSH est déjà installé.

Installation sur Debian, Ubuntu et dérivés

Pour installer le client SSH sur des distributions basées sur Debian ou Ubuntu :

Terminal window
sudo apt update
sudo apt install openssh-client

Installation sur CentOS, Fedora et Red Hat

Pour les distributions basées sur Red Hat :

  1. Installer le paquet openssh-clients :

    • Sur Fedora :

      Terminal window
      sudo dnf install openssh-clients

    • Sur CentOS et Red Hat Enterprise Linux :

      Terminal window
      sudo yum install openssh-clients

Installation sur Arch Linux

Pour les distributions basées sur Arch Linux :

  1. Installer le paquet openssh :

    Terminal window
    sudo pacman -S openssh

Sur macOS

Le client SSH est préinstallé sur macOS, car il est basé sur une architecture Unix. Vous pouvez utiliser le Terminal pour accéder aux fonctionnalités SSH.

Pour vérifier la version du client SSH installé :

Terminal window
ssh -V

Exemple de sortie :

OpenSSH_8.1p1, LibreSSL 2.7.3

Si vous avez besoin d’une version plus récente du client SSH, vous pouvez utiliser des gestionnaires de paquets tiers comme Homebrew.

Terminal window
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Installation du Client SSH :

Terminal window
brew install openssh

Remarque : L’installation via Homebrew peut installer le client SSH dans un chemin différent. Assurez-vous que votre système utilise la version souhaitée.

Sur Windows

Historiquement, Windows ne disposait pas d’un client SSH natif, mais depuis Windows 10, OpenSSH Client est disponible en tant que fonctionnalité optionnelle.

Installation via les Paramètres

  1. Ouvrir les Paramètres :

    • Cliquez sur le menu Démarrer et sélectionnez Paramètres (l’icône en forme de roue dentée).

  2. Accéder aux fonctionnalités facultatives :

    • Allez dans Applications > Applications et fonctionnalités.
    • Cliquez sur Fonctionnalités facultatives.

  3. Ajouter le Client OpenSSH :

    • Cliquez sur Ajouter une fonctionnalité.
    • Faites défiler la liste et sélectionnez Client OpenSSH.
    • Cliquez sur Installer.

Installation via Chocolatey (gestionnaire de paquets)

Si vous utilisez Chocolatey, un gestionnaire de paquets pour Windows :

  1. Installer OpenSSH :

    Terminal window
    choco install openssh

Vérification de l’installation

  1. Ouvrir PowerShell ou l’invite de commande :

    • Cliquez sur le menu Démarrer et tapez PowerShell ou Invite de commandes.

  2. Vérifier la version de SSH :

    Terminal window
    ssh -V

    Exemple de sortie :

    OpenSSH_for_Windows_8.1p1, LibreSSL 2.9.2

Utilisation de clients SSH tiers

Plusieurs clients SSH tiers offrent des fonctionnalités supplémentaires ou une interface graphique.

PuTTY

PuTTY est un client SSH populaire pour Windows.

  1. Téléchargement :

  2. Installation :

    • Téléchargez l’installateur et suivez les instructions à l’écran.

  3. Utilisation :

    • Lancez PuTTY.
    • Entrez le nom d’hôte ou l’adresse IP du serveur.
    • Configurez les options selon vos besoins et cliquez sur Open.
MobaXterm

MobaXterm offre un environnement complet avec un terminal amélioré.

  1. Téléchargement :

  2. Installation :

    • Téléchargez la version installable ou portable.

  3. Utilisation :

    • Lancez MobaXterm.
    • Cliquez sur Session > SSH.
    • Entrez les informations de connexion SSH et établissez la session.
Git Bash

Git pour Windows inclut Git Bash, qui fournit un environnement similaire à Unix avec le client SSH.

  1. Téléchargement :

  2. Installation :

    • Téléchargez l’installateur et suivez les étapes.
    • Lors de l’installation, assurez-vous que Git Bash est sélectionné.

  3. Utilisation :

    • Ouvrez Git Bash depuis le menu Démarrer.
    • Utilisez les commandes SSH comme sur un système Unix.

Connexion au Serveur SSH

Une fois le client SSH installé sur votre poste de travail, la prochaine étape est de se connecter à un serveur 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) :

Terminal window
ssh utilisateur@adresse_ip -p port

Par exemple :

Terminal window
ssh bob@192.168.1.10

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 :

Terminal window
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 :

Terminal window
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.

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.

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 :
Terminal window
chmod 700 ~/.ssh
  1. 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) :
Terminal window
chmod 600 ~/.ssh/id_ed25519
  1. 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 :
Terminal window
chmod 644 ~/.ssh/id_ed25519.pub
chmod 644 ~/.ssh/known_hosts
chmod 644 ~/.ssh/config
  1. 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 :
Terminal window
chmod 600 ~/.ssh/authorized_keys

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) :

Terminal window
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é.

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

Terminal window
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 :

Terminal window
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 le client SSH est essentiel pour tout professionnel de l’informatique souhaitant gérer efficacement des serveurs distants. En comprenant comment installer le client SSH sur différents systèmes d’exploitation, configurer des connexions sécurisées et optimiser votre fichier ~/.ssh/config, vous gagnez en productivité tout en renforçant la sécurité de vos communications. De plus, savoir déboguer les connexions SSH vous permet de résoudre rapidement les problèmes qui pourraient survenir.

Dans les guides suivants, nous approfondirons l’utilisation avancée de SSH, notamment le tunneling SSH, qui permet de sécuriser le transfert de données entre vos applications, et la configuration des serveurs SSH, qui est en cours d’amélioration pour offrir encore plus de fonctionnalités et de robustesse. Ces connaissances vous permettront d’exploiter tout le potentiel de SSH.

Plus loin