Se connecter en SSH : guide du client OpenSSH

---

ssh est la porte d'entrée de tout serveur Linux en production. La connexion basique ssh user@host suffit pour commencer, 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 jusqu'aux techniques utilisées à l'examen LFCS et RHCSA.

C'est 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 et utiliser un fichier ~/.ssh/config avec des alias de connexion
• Rebondir sur un serveur via un bastion avec ProxyJump
• Accélérer les reconnexions avec ControlMaster
• Diagnostiquer une connexion qui échoue avec -v / -vvv
• Gérer les empreintes avec known_hosts et éviter les faux positifs MitM

Dans quel contexte ?

Situation	Technique
Se connecter à 10 serveurs avec des ports et clés différents	~/.ssh/config avec aliases
Atteindre un serveur interne via un bastion public	ProxyJump
Exécuter des scripts Ansible ou rsync sans saisir de mot de passe	clé SSH + ssh-agent
Connexions répétées lors d'un déploiement	ControlMaster (multiplexage)
Connexion refusée après rebuild d'une VM	nettoyer known_hosts
Déboguer un refus d'authentification	ssh -vvv user@host

Glissez pour voir

Prérequis

Ce guide suppose que vous avez une clé SSH. Si ce n'est pas le cas, commencez par Créer et gérer des clés SSH avant de continuer.

Connexion de base

Forme minimale

ssh bob@192.168.1.10

SSH se connecte sur le port 22 avec l'utilisateur bob. Si aucune clé n'est trouvée, il demande le mot de passe.

Options courantes à la volée

# Port non standard
ssh -p 2222 bob@192.168.1.10

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

# Mode verbose (debug léger)
ssh -v bob@192.168.1.10

Vérifier que la connexion est établie :

# Sur le serveur distant après connexion
whoami
hostname
uptime

Accepter l'empreinte du serveur

Au premier contact, SSH affiche l'empreinte du serveur :

The authenticity of host '192.168.1.10 (192.168.1.10)' can't be established.
ED25519 key fingerprint is SHA256:xxxx...
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Tapez yes pour mémoriser l'empreinte dans ~/.ssh/known_hosts. SSH refusera la connexion si l'empreinte change à l'avenir, c'est intentionnel (protection MitM).

---

Configurer ~/.ssh/config

Le fichier ~/.ssh/config permet de définir des alias de connexion avec tous leurs paramètres. C'est la façon propre de gérer plusieurs serveurs.

Structure de base

Host webserver
    HostName 192.168.1.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 config, ssh webserver est équivalent à ssh -p 2222 -i ~/.ssh/id_ed25519_deploy deploy@192.168.1.20.

Permissions obligatoires

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

SSH refuse de lire le fichier config s'il est lisible par d'autres utilisateurs.

Configuration globale avec Host *

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
    Compression yes
    IdentityFile ~/.ssh/id_ed25519

ServerAliveInterval 60 envoie un keepalive toutes les 60 s, évite les déconnexions sur les sessions inactives. Ces options s'appliquent à tous les hôtes, sauf surcharge par un bloc Host spécifique.

Principales directives

Directive	Rôle
Host	Alias de connexion
HostName	Adresse réelle ou FQDN
User	Utilisateur distant
Port	Port SSH (défaut : 22)
IdentityFile	Chemin de la clé privée
ServerAliveInterval	Keepalive (secondes)
ServerAliveCountMax	Tentatives avant coupure
Compression	Compression des données
ForwardAgent	Transfert de l'agent SSH
StrictHostKeyChecking	Vérification d'empreinte
ProxyJump	Rebond via bastion
ControlMaster	Multiplexage de connexion
ControlPath	Socket du multiplexage
ControlPersist	Durée de vie du master

Glissez pour voir

---

ProxyJump, rebondir via un bastion

Dans une architecture typique, les serveurs internes ne sont pas accessibles directement depuis Internet. On passe par un bastion (aussi appelé jump host).

[Workstation] → [bastion:22] → [internal-server:22]

Configuration dans ~/.ssh/config

Host bastion
    HostName bastion.example.com
    User jumpuser
    IdentityFile ~/.ssh/id_ed25519

Host internal
    HostName 10.0.1.50
    User admin
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519

# Connexion directe au serveur interne
ssh internal

SSH établit d'abord la connexion au bastion, puis rebondit automatiquement vers internal. Vous n'avez pas besoin de copier votre clé sur le bastion, le ForwardAgent yes n'est pas nécessaire avec ProxyJump.

En one-liner (sans fichier config)

ssh -J jumpuser@bastion.example.com admin@10.0.1.50

ProxyJump en chaîne (multi-sauts)

Host deep-server
    HostName 10.1.2.3
    User admin
    ProxyJump bastion,intermediate

---

ControlMaster, multiplexer les connexions

Lors d'un déploiement ou d'une série de commandes, SSH établit une nouvelle connexion TCP + authentification à chaque appel. ControlMaster permet de réutiliser une connexion existante, la première connexion crée un socket, les suivantes l'empruntent.

Host *.example.com
    ControlMaster auto
    ControlPath ~/.ssh/cm-%r@%h:%p
    ControlPersist 10m

• ControlMaster auto : utilise une connexion existante si possible, en crée une sinon
• ControlPath : chemin du socket Unix (utilise des variables %r user, %h host, %p port)
• ControlPersist 10m : le socket reste ouvert 10 min après la dernière session

Résultat : rsync, scp ou ansible sur le même hôte sont quasi-instantanés après la première connexion.

Sécurité du socket

Le socket ControlPath est un fichier sensible, il donne accès SSH sans authentification. Vérifiez les permissions : ls -la ~/.ssh/cm-*. Il doit appartenir uniquement à votre utilisateur (600 ou 700).

---

Gérer known_hosts

Avertissement MitM après rebuild d'une VM

Quand une VM est reconstruite ou une IP réaffectée, la clé d'hôte change. SSH affiche :

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Supprimer l'ancienne entrée :

ssh-keygen -R 192.168.1.10
# ou
ssh-keygen -R hostname.example.com

SSH demande ensuite de confirmer la nouvelle empreinte au prochain ssh.

Ajouter une empreinte sans se connecter

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

Utile dans les scripts d'automatisation pour pré-peupler known_hosts avant le premier ssh.

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

Host 192.168.122.*
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null

Uniquement pour les labs

StrictHostKeyChecking no désactive la protection contre les attaques MitM. Ne jamais utiliser en production ou sur des serveurs accessibles depuis Internet.

---

Diagnostiquer une connexion

Niveau de verbosité -v

ssh -v bob@192.168.1.10     # debug de base
ssh -vv bob@192.168.1.10    # détail du handshake
ssh -vvv bob@192.168.1.10   # tout (trop verbeux sauf cas extrême)

Les premières lignes à regarder :

debug1: Reading configuration data ~/.ssh/config
debug1: Connecting to 192.168.1.10 [192.168.1.10] port 22.
debug1: Connection established.
debug1: Authenticating to 192.168.1.10:22 as 'bob'
debug1: Trying private key: ~/.ssh/id_ed25519
debug1: Authentication succeeded (publickey).

Si Authentication succeeded n'apparaît pas → problème de clé ou d'authorized_keys côté serveur.

Vérifier les permissions côté client

Les permissions incorrectes sur ~/.ssh/ font silencieusement échouer l'authentification par clé :

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

Lire les logs côté serveur

# Sur le serveur distant
sudo journalctl -u ssh -n 50
# ou sur RHEL/Fedora
sudo journalctl -u sshd -n 50

# Rechercher les refus
sudo grep "Failed\|refused\|Invalid" /var/log/auth.log

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/corrompu	Vérifier avec -v, corriger les permissions
WARNING: 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	Firewall bloque le port 22	nc -zv <host> 22 ou telnet <host> 22
Connexion coupée après inactivité	Pas de keepalive	Ajouter ServerAliveInterval 60 dans la config

Glissez pour voir

---

À retenir

• ~/.ssh/config centralise les paramètres de connexion pour tous vos serveurs, c'est la façon professionnelle de gérer l'accès distant
• ProxyJump remplace les anciennes configurations -A + bastion manuel, plus simple, plus sûr
• ControlMaster est indispensable pour les outils comme Ansible ou rsync qui multiplient les connexions
• ssh -v est la première commande à lancer quand une connexion échoue
• Les permissions sur ~/.ssh/ ne sont pas optionnelles, SSH refuse silencieusement si elles sont incorrectes

Contrôle de connaissances

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 questions

5 min.

80% 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

Prochaines étapes

Créer et gérer des clés SSH ssh-keygen Ed25519, ssh-agent, ssh-copy-id et authorized_keys, l'authentification sans mot de passe.

Exécuter des commandes distantes via SSH ssh user@host cmd, pipes distants, scripts batch et collecte d'informations multi-serveurs.

Tunnels SSH : -L, -R, -D et ProxyJump Redirection de port locale, distante et dynamique (proxy SOCKS), sécuriser l'accès à des services internes.

Durcir l'accès SSH sshd_config : désactiver root, authentification par clé uniquement, fail2ban, AllowUsers.

×

📖 Voir la documentation →