Se connecter en SSH : guide du client OpenSSH

Le client ssh est la porte d'entrée de tout serveur Linux, et le fichier ~/.ssh/config transforme des commandes longues et répétitives en simples alias. La connexion basique ssh utilisateur@serveur suffit pour débuter, mais dès que vous gérez plusieurs serveurs, plusieurs clés ou un bastion, la configuration du client devient indispensable. Ce guide couvre tout : de la première connexion aux techniques du quotidien (ProxyJump, ControlMaster, diagnostic), avec des sorties réelles capturées sur un lab de deux machines. Public visé : administrateurs et DevOps à l'aise avec le terminal.

Ce guide couvre un objectif direct LFCS (domaine Networking, « Configure the OpenSSH server and client ») et RHCSA (domaine Manage Security, « Configure key-based authentication for SSH »).

Ce que vous allez apprendre

• Établir une connexion SSH de base avec utilisateur, port et clé.
• Créer un fichier ~/.ssh/config avec des alias de connexion.
• Rebondir sur un serveur interne via un bastion avec ProxyJump.
• Accélérer les reconnexions avec ControlMaster.
• Diagnostiquer une connexion qui échoue avec -v.
• Gérer les empreintes avec known_hosts et éviter les faux positifs MitM.

Prérequis

Ce guide suppose que vous disposez déjà d'une clé SSH. Si ce n'est pas le cas, commencez par créer et gérer des clés SSH : l'authentification par clé est la base de tout ce qui suit, et elle remplace avantageusement le mot de passe.

Dans quel contexte utiliser quoi

Chaque technique de ce guide répond à un besoin précis. Ce tableau vous oriente vers la bonne section selon votre situation.

Situation	Technique
Se connecter à dix serveurs aux ports et clés différents	~/.ssh/config avec alias
Atteindre un serveur interne via un bastion public	ProxyJump
Lancer des scripts Ansible ou rsync sans saisir de mot de passe	clé SSH + ssh-agent
Enchaîner des connexions répétées lors d'un déploiement	ControlMaster (multiplexage)
Connexion refusée après reconstruction d'une VM	nettoyer known_hosts
Déboguer un refus d'authentification	ssh -vvv utilisateur@serveur

Glissez pour voir

Connexion de base

La forme minimale

La commande la plus simple précise l'utilisateur et l'hôte :

ssh bob@192.168.10.77

SSH se connecte sur le port 22 avec l'utilisateur bob. S'il trouve une clé correspondante, il l'utilise ; sinon il demande le mot de passe. Une fois connecté, vérifiez que vous êtes bien où vous croyez :

hostname   # le nom de la machine distante
whoami     # l'utilisateur effectif

Les options courantes à la volée

Trois options couvrent l'essentiel des cas particuliers, sans fichier de configuration :

# Port non standard
ssh -p 2222 bob@192.168.10.77

# Clé privée spécifique
ssh -i ~/.ssh/id_ed25519_backup bob@backup.exemple.fr

# Mode verbeux, pour comprendre ce qui se passe
ssh -v bob@192.168.10.77

Accepter l'empreinte au premier contact

Au premier contact, SSH affiche l'empreinte du serveur et vous demande de la valider :

The authenticity of host '192.168.10.77' can't be established.
ED25519 key fingerprint is SHA256:NqZlPkE/wI00lVSvf+jI6/ENp5tIeqiwM4P5nhuuBtE.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Répondez yes pour mémoriser l'empreinte dans ~/.ssh/known_hosts. À partir de là, SSH refusera la connexion si l'empreinte change : c'est intentionnel, c'est la protection contre les attaques de type man-in-the-middle (voir plus bas).

Configurer ~/.ssh/config

Le fichier ~/.ssh/config définit des alias de connexion avec tous leurs paramètres. C'est la façon propre de gérer plusieurs serveurs, et le premier réflexe professionnel à acquérir.

La structure de base

Chaque bloc Host déclare un alias et ses options :

Host webserver
    HostName 192.168.10.20
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_deploy

Host db
    HostName 10.0.1.5
    User dbadmin
    IdentityFile ~/.ssh/id_ed25519_db

Avec cette configuration, un simple ssh webserver équivaut à ssh -p 2222 -i ~/.ssh/id_ed25519_deploy deploy@192.168.10.20. Le gain est immédiat : sur le lab qui sert ce guide, l'alias bastion répond directement.

ssh bastion 'echo "connecte sur $(hostname), utilisateur $(whoami)"'

connecte sur lab-bastion, utilisateur labuser

Permissions obligatoires

SSH refuse de lire un fichier config accessible par d'autres utilisateurs. Les permissions ne sont pas optionnelles :

chmod 700 ~/.ssh
chmod 600 ~/.ssh/config

La configuration globale avec Host *

Le bloc Host * applique des options à tous les hôtes, sauf surcharge par un bloc plus spécifique :

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
    Compression yes

ServerAliveInterval 60 envoie un signal de vie toutes les 60 secondes et évite les déconnexions sur les sessions inactives. C'est le réglage qui vous épargne les « Broken pipe » agaçants sur une session laissée ouverte.

Les principales directives

Ces directives couvrent la quasi-totalité des besoins d'administration :

Directive	Rôle
Host	Alias de connexion
HostName	Adresse réelle ou nom complet (FQDN)
User	Utilisateur distant
Port	Port SSH (défaut : 22)
IdentityFile	Chemin de la clé privée
ServerAliveInterval	Signal de vie (secondes)
ProxyJump	Rebond via un bastion
ControlMaster	Multiplexage de connexion
StrictHostKeyChecking	Politique de vérification d'empreinte

Glissez pour voir

ProxyJump, rebondir via un bastion

Dans une architecture saine, les serveurs internes ne sont pas accessibles directement depuis Internet. On passe par un bastion (aussi appelé jump host), seul point d'entrée exposé et durci.

[poste de travail] --> [bastion:22] --> [serveur interne:22]

La configuration dans ~/.ssh/config

La directive ProxyJump automatise le rebond : vous déclarez le bastion, puis vous le référencez dans le bloc du serveur interne.

Host bastion
    HostName 192.168.10.77
    User labuser
    IdentityFile ~/.ssh/id_ed25519

Host interne
    HostName 192.168.10.210
    User labuser
    IdentityFile ~/.ssh/id_ed25519
    ProxyJump bastion

Un simple ssh interne établit alors la connexion au bastion, puis rebondit automatiquement vers le serveur interne :

ssh interne 'echo "connecte sur $(hostname), utilisateur $(whoami)"'

connecte sur lab-interne, utilisateur labuser

La force de ProxyJump tient dans un détail de sécurité : votre clé privée ne quitte jamais votre poste. Le mode verbeux le prouve, avec sa ligne (via proxy) :

ssh -v interne true

debug1: Connecting to 192.168.10.77 [192.168.10.77] port 22.
Authenticated to 192.168.10.77 ([192.168.10.77]:22) using "publickey".
Authenticated to 192.168.10.210 (via proxy) using "publickey".

Vous vous authentifiez d'abord sur le bastion, puis sur le serveur interne à travers lui, chaque fois avec votre clé. Le bastion ne fait que relayer le trafic chiffré ; il ne voit jamais votre clé.

En une ligne, sans fichier de configuration

Pour un rebond ponctuel, l'option -J fait la même chose sans rien configurer :

ssh -J labuser@192.168.10.77 labuser@192.168.10.210

Et pour une chaîne de plusieurs sauts, on enchaîne les bastions séparés par des virgules : ProxyJump bastion1,bastion2.

ControlMaster, multiplexer les connexions

Lors d'un déploiement ou d'une série de commandes, SSH établit une nouvelle connexion TCP et une nouvelle authentification à chaque appel. ControlMaster réutilise une connexion existante : la première ouvre un socket, les suivantes l'empruntent au lieu de tout recommencer.

Host *.exemple.fr
    ControlMaster auto
    ControlPath ~/.ssh/cm-%r@%h:%p
    ControlPersist 2m

• ControlMaster auto : réutilise une connexion si possible, en crée une sinon.
• ControlPath : chemin du socket Unix (variables %r utilisateur, %h hôte, %p port).
• ControlPersist 2m : le socket reste ouvert 2 minutes après la dernière session.

Le gain est mesurable. Sur le lab, une connexion qui réutilise le master contre une connexion neuve :

== connexion via master réutilisé ==
real    0m0,034s
== connexion neuve ==
real    0m0,166s

Sur un réseau local, l'écart paraît modeste (34 ms contre 166 ms), mais il explose dès que l'authentification est coûteuse (bastion, clé sur carte à puce, latence WAN). C'est ce qui rend rsync, scp ou ansible quasi instantanés sur un même hôte après la première connexion.

Le socket de multiplexage est sensible

Le fichier ControlPath donne un accès SSH sans nouvelle authentification. Vérifiez ses permissions (ls -la ~/.ssh/cm-*) : il doit appartenir uniquement à votre utilisateur. Quiconque peut le lire peut emprunter votre session.

Gérer known_hosts

Le fichier ~/.ssh/known_hosts mémorise l'empreinte de chaque serveur visité. C'est ce qui permet à SSH de détecter qu'un serveur n'est plus celui qu'il prétend être.

L'avertissement MitM après une reconstruction

Quand une VM est reconstruite ou une IP réaffectée, la clé d'hôte change. SSH le détecte et bloque la connexion avec un avertissement spectaculaire, capturé ici sur le lab :

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
...
Offending ED25519 key in /home/bob/.ssh/known_hosts:1
Host key verification failed.

Ne désactivez pas ce contrôle par réflexe : c'est exactement la protection qui vous alerterait d'une vraie attaque. Si vous savez que la machine a légitimement changé, supprimez l'ancienne entrée. SSH vous donne même la commande exacte :

ssh-keygen -f ~/.ssh/known_hosts -R 192.168.10.77

# Host 192.168.10.77 found: line 1
known_hosts updated.
Original contents retained as known_hosts.old

La prochaine connexion redemandera de valider la nouvelle empreinte.

Pré-remplir known_hosts sans se connecter

Dans un script d'automatisation, on ne veut pas de question interactive au premier contact. La commande ssh-keyscan récupère l'empreinte à l'avance :

ssh-keyscan -H 192.168.10.77 >> ~/.ssh/known_hosts

Désactiver la vérification (environnements éphémères uniquement)

Pour des VM jetables recréées en boucle, la vérification devient un frein. On la désactive alors par plage d'IP, jamais globalement :

Host 192.168.122.*
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null

Uniquement pour les labs

StrictHostKeyChecking no désactive la protection contre les attaques MitM. Ne l'utilisez jamais en production ni sur des serveurs accessibles depuis Internet. Réservez-la à un réseau de VM jetables strictement délimité.

Diagnostiquer une connexion

Les niveaux de verbosité

Quand une connexion échoue, la première commande à lancer est ssh -v. Trois niveaux existent, du plus utile au plus bavard :

ssh -v bob@192.168.10.77     # diagnostic de base, suffisant 9 fois sur 10
ssh -vv bob@192.168.10.77    # détail du handshake
ssh -vvv bob@192.168.10.77   # tout, réservé aux cas extrêmes

Sur une connexion qui réussit par clé publique, les lignes clés ressemblent à ceci :

debug1: Reading configuration data ~/.ssh/config
debug1: Connecting to 192.168.10.77 [192.168.10.77] port 22.
debug1: Authenticating to 192.168.10.77:22 as 'labuser'
debug1: Offering public key: ~/.ssh/id_ed25519 ED25519 SHA256:NqZl... explicit
debug1: Server accepts key: ~/.ssh/id_ed25519 ED25519 SHA256:NqZl... explicit
debug1: Entering interactive session.

Si Server accepts key n'apparaît pas, le problème est côté serveur : clé absente de authorized_keys, ou permissions incorrectes.

Les permissions côté client

Des permissions trop larges sur ~/.ssh/ font silencieusement échouer l'authentification par clé. SSH refuse d'utiliser une clé privée que d'autres pourraient lire :

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 600 ~/.ssh/config

Lire les journaux côté serveur

Quand le client ne suffit pas, les journaux du serveur donnent la raison exacte du refus :

# Sur Debian/Ubuntu, le service s'appelle "ssh"
sudo journalctl -u ssh -n 50

# Sur RHEL/Fedora/AlmaLinux, il s'appelle "sshd"
sudo journalctl -u sshd -n 50

Tableau de dépannage

Symptôme	Cause probable	Action
Connection refused	Port 22 fermé ou sshd arrêté	sudo systemctl status ssh côté serveur
Permission denied (publickey)	Mauvaise clé ou authorized_keys absent	Vérifier avec -v, corriger les permissions
REMOTE HOST IDENTIFICATION HAS CHANGED	VM reconstruite, IP réaffectée	ssh-keygen -R <ip>
Host key verification failed	Empreinte inconnue en mode strict	Vérifier avant d'accepter, ou ssh-keyscan
Timeout sans message	Pare-feu bloque le port 22	nc -zv <hôte> 22
Déconnexion après inactivité	Pas de signal de vie	Ajouter ServerAliveInterval 60

Glissez pour voir

Sécurité et points de vigilance

Le client SSH est aussi une surface d'exposition : quelques réflexes le durcissent sans effort.

• Une clé par usage, pas une clé unique partout : une clé compromise ne doit pas ouvrir tout le parc.
• ProxyJump plutôt qu'un agent transféré : évitez ForwardAgent yes vers un bastion non maîtrisé, où votre agent pourrait être détourné.
• Chiffrez vos clés privées avec une phrase de passe, et déléguez sa saisie à ssh-agent.
• ControlPath dans un répertoire privé : le socket de multiplexage est une porte ouverte tant qu'il vit.

Validation du guide

Vous maîtrisez ce guide si vous savez, sans documentation : écrire un bloc Host avec HostName, User et IdentityFile ; atteindre un serveur interne par ProxyJump ; lire une sortie ssh -v pour repérer où l'authentification échoue ; et corriger un known_hosts après reconstruction d'une machine.

Contrôle de connaissances

Vérifiez que l'essentiel du guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• ~/.ssh/config centralise les paramètres de connexion : un alias remplace une commande longue et fragile.
• ProxyJump rebondit via un bastion sans jamais exposer votre clé : la ligne (via proxy) en -v le prouve.
• ControlMaster rend instantanées les connexions répétées d'ansible, rsync ou scp.
• ssh -v est la première commande à lancer quand une connexion échoue.
• Les permissions de ~/.ssh/ ne sont pas optionnelles : SSH refuse silencieusement si elles sont trop larges.
• L'avertissement REMOTE HOST IDENTIFICATION HAS CHANGED est une protection, pas un bug : comprenez-le avant de purger known_hosts.

Pour aller plus loin

• Créer et gérer des clés SSH : la brique en amont de tout ce guide, de ssh-keygen à ssh-copy-id.
• Exécuter des commandes distantes via SSH : ssh user@host cmd, pipes distants et collecte multi-serveurs.
• Tunnels SSH : -L, -R, -D et ProxyJump : redirection de port locale, distante et dynamique (proxy SOCKS).
• Durcir l'accès SSH : sshd_config, désactivation de root, authentification par clé uniquement, fail2ban.

×

📖 Voir la documentation →