Rédigé par Rédaction CyberSDF / 18 September 2026

SSH sous Linux : se connecter par clé et via un bastion

SSH ouvre une session ou exécute une commande sur une autre machine. La clé privée reste sur votre poste, la clé publique est installée sur le compte distant, et un bastion relaie la connexion vers un serveur qui n’est pas exposé directement. La séquence sûre est donc : vérifier la clé du serveur, créer sa propre clé, décrire l’accès dans ~/.ssh/config, puis contrôler la configuration avant le premier login.

Le contrôle local réalisé le 17 septembre 2026 à 22:30 UTC avec OpenSSH_9.6p1 Ubuntu-3ubuntu13.19 a mesuré une clé Ed25519 de 256 bits, un fichier privé en mode 600 et une configuration résolue avec ssh -G. Les exemples utilisent des noms et adresses fictifs pour ne jamais exposer un serveur réel.

Un accès SSH fiable commence par la clé du serveur

SSH utilise deux familles de clés qu’il ne faut pas confondre. La clé d’hôte identifie le serveur et son empreinte est conservée dans ~/.ssh/known_hosts. Votre clé utilisateur sert ensuite à prouver que vous avez le droit d’ouvrir la session. Une clé privée de connexion ne remplace donc pas la vérification de la clé du serveur.

Lors d’une première connexion, le client affiche l’empreinte présentée par le serveur et demande votre confirmation. Comparez-la avec une empreinte transmise par l’administrateur, un inventaire interne ou la console du fournisseur. Le manuel ssh(1) d’OpenBSD décrit le contrôle des clés d’hôte et le rôle de known_hosts.

Un changement d’empreinte n’est pas une invitation à supprimer la ligne correspondante. Il peut signaler une réinstallation légitime, mais aussi une mauvaise cible ou une interception. Arrêtez la connexion, demandez la nouvelle empreinte par un autre canal, puis seulement utilisez ssh-keygen -R nom-du-serveur si le changement est confirmé.

Ne désactivez pas ce contrôle avec StrictHostKeyChecking=no pour faire disparaître un message. Vous obtiendriez une connexion plus rapide, pas une connexion vérifiée.

Créer une clé sans déplacer le secret

Il vous faut un client OpenSSH, un compte déjà autorisé sur le serveur et l’empreinte attendue de sa clé d’hôte. Créez la paire sur le poste qui servira à vous connecter :

mkdir -m 700 -p ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519
chmod 600 ~/.ssh/id_ed25519
ssh-keygen -lf ~/.ssh/id_ed25519.pub

ssh-keygen demande une phrase secrète pour protéger le fichier privé. Le fichier id_ed25519.pub est la partie partageable. La commande ssh-keygen -lf affiche son empreinte et son type ; elle ne transmet rien au serveur.

Dans le contrôle local du 17 septembre, la sortie de l’empreinte commençait par 256 SHA256: et se terminait par (ED25519). La mesure stat a renvoyé 600 pour le fichier privé. Ce contrôle vérifie une protection élémentaire, pas l’autorisation d’un compte distant.

Si une session existe déjà sur le serveur, envoyez uniquement la clé publique :

ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@serveur.example.net

Sans ssh-copy-id, l’administrateur peut ajouter la ligne de id_ed25519.pub dans ~/.ssh/authorized_keys avec la session de secours encore ouverte. Ne copiez jamais id_ed25519 sur le serveur et ne remplacez pas authorized_keys en bloc. Les permissions Linux expliquent pourquoi le dossier SSH et ses fichiers doivent rester privés.

Décrire un serveur dans ~/.ssh/config

Une entrée nommée évite de répéter l’utilisateur, le port et la clé à chaque commande. Placez les règles spécifiques avant les règles générales, puis protégez le fichier :

Host serveur-admin
    HostName serveur.example.net
    User admin
    Port 22
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

chmod 600 ~/.ssh/config
ssh serveur-admin

Host est l’alias saisi dans le terminal. HostName est le nom réellement résolu. IdentityFile indique la clé privée à proposer et IdentitiesOnly yes évite que le client tente d’autres identités offertes par un agent. L’ordre des réglages n’est pas décoratif : ssh_config(5) d’OpenBSD indique que la ligne de commande est lue avant le fichier utilisateur, puis le fichier système, et que la première valeur obtenue pour une directive est retenue.

Pour vérifier cette entrée sans ouvrir de connexion :

ssh -F ~/.ssh/config -G serveur-admin

Dans l’essai local, les lignes utiles renvoyées par la configuration de test étaient :

user admin
hostname serveur.example.net
port 22
identitiesonly yes
identityfile ~/.ssh/id_ed25519
proxyjump none

ssh -G imprime la configuration effective et s’arrête avant l’authentification. La commande ne vérifie donc ni le DNS ni l’ouverture du port ; elle vérifie uniquement la lecture locale des règles.

Passer par un bastion avec ProxyJump

Un bastion est un relais auquel votre poste peut se connecter et qui peut atteindre le serveur interne. Il ne devient pas le serveur final : le client ouvre d’abord le relais, puis demande à celui-ci de transporter le flux vers la cible.

Host bastion
    HostName bastion.example.net
    User jump
    IdentityFile ~/.ssh/id_ed25519_bastion
    IdentitiesOnly yes

Host serveur-interne
    HostName 10.0.0.12
    User admin
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes
    ProxyJump bastion

La commande devient :

ssh serveur-interne

Pour un essai ponctuel, la même option s’écrit :

ssh -J jump@bastion.example.net admin@10.0.0.12

Le bloc du bastion peut avoir une clé et un utilisateur différents de ceux de la cible. Cette séparation évite de supposer que le relais accepte la même identité. Le manuel ssh(1) documente -J, et la page ProxyJump dans ssh_config(5) précise le chemin utilisé par le client.

Si votre besoin porte plutôt sur une authentification matérielle, la page sur l’authentification forte sur SSH traite les clés FIDO2 sans mélanger leur rôle avec celui d’un bastion.

Contrôler la configuration avant la connexion

Commencez par lire la configuration effective de l’alias :

ssh -G serveur-interne

Vérifiez au minimum user, hostname, port, identityfile, identitiesonly et proxyjump. Si une valeur est inattendue, corrigez le bloc Host ou l’ordre des règles avant de demander une connexion.

Une fois la cible et l’empreinte confirmées, commencez par une commande distante sans effet :

ssh -o IdentitiesOnly=yes serveur-interne 'printf "connexion-ok\n"'

La sortie attendue est connexion-ok. Pour comprendre un échec, ajoutez -v, puis -vvv si le premier niveau ne suffit pas :

ssh -vvv serveur-interne

La sortie verbeuse permet de voir le fichier de configuration lu, la cible choisie et les identités proposées. Elle peut contenir des noms d’hôtes et des chemins locaux : ne la publiez pas telle quelle dans un forum ou un ticket sans retirer ces éléments.

Lire l’erreur qui arrête la connexion

Un diagnostic SSH ne commence pas par un changement de port ou une suppression de known_hosts. Pour séparer une route absente d’un service qui refuse une connexion, utilisez la méthode de diagnostic d’une connexion sous Linux.

Le serveur reste responsable de sa propre règle

La configuration du client ne prouve pas à elle seule que le serveur est joignable ni que le compte a le droit d’ouvrir une session : l’administrateur doit confirmer l’empreinte, le compte, la clé publique et le chemin par le bastion. Sur une machine que vous administrez, vérifiez la syntaxe du démon avant tout rechargement avec sshd -t, gardez une session ouverte et appliquez les règles adaptées au serveur.

Le manuel sshd_config(5) précise les réglages du serveur, notamment AuthorizedKeysFile et AuthenticationMethods. Le durcissement minimal sous Linux complète cette partie, tandis que l’administration Debian aide à lire les services et leurs journaux.