Jump host ou bastion : quelle différence ?

Un jump host, ou serveur de rebond, est n'importe quel serveur par lequel vous passez pour en atteindre un autre, par exemple avec ssh -J. Un bastion est un serveur de rebond conçu pour ce seul rôle : exposé à internet, seule entrée d'un réseau privé, durci et journalisé. Tout bastion est un serveur de rebond, mais un serveur de rebond ne devient un bastion qu'une fois verrouillé. Avec ProxyJump, votre session reste chiffrée de votre machine jusqu'à la cible et vos clés ne se retrouvent jamais sur le serveur intermédiaire.

Mis à jour le . ssh -J, ProxyJump dans la configuration, ProxyCommand avec ssh -W, une chaîne de deux rebonds avec -J et ssh -G ont été exécutés avec OpenSSH 10.0 sur Debian 13 dans des conteneurs jetables : un client, un serveur de rebond et une cible privée.

La différence en un tableau

Jump hostBastion
Ce que décrit le termeUn rôle : un serveur par lequel on passeUne machine construite pour ce seul rôle
Où il se trouveN'importe où : une machine de dev, une VM d'administration, un autre serveurEn bordure, joignable depuis internet ou depuis le bureau
Ce qui tourne d'autre dessusSouvent d'autres servicesRien d'autre que SSH
Qui peut s'y connecterQuiconque a un compteDes utilisateurs nominatifs, souvent avec redirection seule et sans shell
Serveurs privésGénéralement joignables autrement aussiN'acceptent SSH que depuis le bastion
JournauxCe que le serveur conserveChaque connexion journalisée, journaux gardés hors de la machine

La question n'est donc pas lequel choisir. Un bastion est un serveur de rebond devenu la seule porte d'entrée, et sécurisé en conséquence. On rencontre aussi les noms jump server, jump box et passerelle SSH.

Comment SSH passe par l'un ou l'autre

De votre côté, la connexion est la même dans les deux cas. Il y a deux bonnes méthodes et une à éviter :

# ProxyJump, OpenSSH 7.3 and later
ssh -J user@bastion user@10.0.0.5

# ProxyCommand with -W, the older equivalent
ssh -o ProxyCommand="ssh -W %h:%p user@bastion" user@10.0.0.5

# Two separate logins: avoid
ssh -A user@bastion
ssh user@10.0.0.5

Avec les deux premières, le serveur de rebond ouvre seulement une connexion TCP vers la cible et relaie les octets. Votre session SSH vers 10.0.0.5 est chiffrée depuis votre machine, et votre clé est utilisée depuis votre machine. Avec la troisième, vous obtenez un shell sur le serveur de rebond et lancez un nouveau ssh depuis là : soit votre clé privée s'y trouve, soit votre agent y est redirigé. Quiconque a les droits root sur cette machine peut alors s'en servir.

Les formes pour le fichier de configuration, les rebonds multiples et les options qui n'atteignent pas le serveur de rebond sont dans ProxyJump et serveur de rebond, avec exemples.

ProxyJump ou ProxyCommand ?

Utilisez ProxyJump quand le rebond est un serveur SSH. C'est plus court, cela s'enchaîne avec des virgules, et chaque rebond est un Host normal avec son utilisateur, son port et sa clé :

ssh -J bastion-eu,admin-gw db-internal

Utilisez ProxyCommand quand l'entrée n'est pas du SSH simple : un proxy HTTP ou SOCKS via nc, ou l'outil en ligne de commande d'un fournisseur cloud qui ouvre la session pour vous. ssh lance la commande et communique avec son entrée et sa sortie standard.

Les deux options sont en concurrence : la première définie l'emporte, et un -o en ligne de commande passe avant le fichier de configuration. Pour savoir laquelle s'applique à un hôte, demandez à ssh :

ssh -G db-internal | grep -i '^proxy'
proxyjump bastion-eu,admin-gw

Ce qui fait d'un serveur de rebond un bastion

  • Une seule fonction. Un petit serveur avec SSH et rien d'autre : pas de base de données, pas de site web, pas d'outils de build.
  • La seule porte. Les serveurs privés n'acceptent le port 22 que depuis l'adresse du bastion, au niveau du pare-feu ou du groupe de sécurité.
  • Aucune clé dessus, pas d'agent forwarding. Les utilisateurs passent par lui avec ProxyJump.
  • Redirection seule. La plupart des utilisateurs n'ont pas besoin de shell dessus. Un bloc Match Group avec PermitOpen limite les destinations permises.
  • Connexion solide. Clés uniquement, et si vous le souhaitez un second facteur avec TOTP.
  • Journaux conservés ailleurs. Les journaux de connexion sortent de la machine, pour qu'un intrus ne puisse pas les effacer.
  • Mis à jour souvent. Il est exposé à internet, donc les mises à jour de sécurité s'installent automatiquement.

La configuration complète de sshd, avec les commandes pour tester ce qui est refusé, se trouve dans mettre en place un bastion SSH.

Avez-vous encore besoin d'un bastion ?

Un bastion règle un seul problème : permettre d'atteindre des serveurs privés par une entrée unique et surveillée. D'autres outils règlent le même problème autrement :

  • Un VPN ou un réseau privé superposé place votre machine sur le réseau privé, et vous vous connectez directement aux serveurs.
  • Le service de session d'un fournisseur cloud ouvre un shell ou un tunnel via l'API du fournisseur, sans aucun port SSH ouvert.
  • Un proxy d'accès basé sur l'identité vérifie qui vous êtes à chaque connexion et enregistre les sessions de façon centralisée.

Chacun déplace la porte unique ailleurs. Le bastion reste l'option la plus simple quand vous voulez OpenSSH tel quel, sans agent sur les serveurs et sans service supplémentaire à faire tourner.

Questions

Un jump server et un bastion, c'est la même chose ?

Dans l'usage courant, presque toujours, et jump box veut dire la même chose. Au sens strict, jump server ou jump host décrit le rôle, vous faire passer, tandis que bastion désigne une machine durcie en bordure de réseau dont c'est la seule fonction.

Le bastion peut-il lire ma session SSH ?

Pas avec ProxyJump ou ProxyCommand ssh -W. Il ne fait que relayer le flux chiffré : il voit qui s'est connecté, quand, et vers quelle adresse et quel port. Il ne peut tout lire que si vous ouvrez un shell dessus et relancez ssh depuis là.

Faut-il utiliser l'agent forwarding à travers un bastion ?

Non. Utilisez ProxyJump. Avec ssh -A vers le bastion, quiconque a les droits root dessus peut utiliser vos clés tant que vous êtes connecté. Voir les risques de l'agent forwarding.

Ai-je encore besoin d'un bastion avec un VPN ?

Pas toujours. Un VPN ou un réseau privé superposé peut le remplacer comme point d'entrée. Beaucoup d'équipes gardent tout de même un bastion comme seule entrée SSH, car une seule machine est facile à surveiller, journaliser et fermer.

Sources

Autres guides : Tunnels et hôtes de rebond

Tous les guides