La différence en un tableau
| Jump host | Bastion | |
|---|---|---|
| Ce que décrit le terme | Un rôle : un serveur par lequel on passe | Une machine construite pour ce seul rôle |
| Où il se trouve | N'importe où : une machine de dev, une VM d'administration, un autre serveur | En bordure, joignable depuis internet ou depuis le bureau |
| Ce qui tourne d'autre dessus | Souvent d'autres services | Rien d'autre que SSH |
| Qui peut s'y connecter | Quiconque a un compte | Des utilisateurs nominatifs, souvent avec redirection seule et sans shell |
| Serveurs privés | Généralement joignables autrement aussi | N'acceptent SSH que depuis le bastion |
| Journaux | Ce que le serveur conserve | Chaque 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 GroupavecPermitOpenlimite 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
- ssh(1), -J et -W, manuel OpenBSD
- ssh_config(5), ProxyJump et ProxyCommand, manuel OpenBSD
- sshd_config(5), redirection et Match, manuel OpenBSD
- Notes de version d'OpenSSH 7.3, ProxyJump