Méthode 1 - oignon (tunnels imbriqués)
Avec OpenSSH 7.3 et ultérieur:
Hôte webserverA
ProxyJump bastionA,bastionB
La même chose via la ligne de commande :
$ ssh -J bastionA,bastionB webserverA
Alternativement (également avec 7.3; ne mélangez pas ceci et ce qui précède):
Hôte webserverA
ProxyJump bastionB
Hôte bastionB
ProxyJump bastionA
Avec des versions plus anciennes - principalement identiques (mais ne copie pas automatiquement les options comme ssh -v):
Hôte webserverA
ProxyCommand ssh bastionB -W %h:%p
Hôte bastionB
ProxyCommand ssh bastionA -W %h:%p
Cette méthode initie toutes les connexions localement, établissant un tunnel ssh -W à chaque étape. Par conséquent, l'authentification se fait localement (ForwardAgent et GSSAPIDelegateCredentials ne sont pas nécessaires) et votre .ssh/config local s'applique à chaque étape également. Du côté du serveur, seul un support de base "TCP forwarding" est nécessaire, tout comme lors de l'utilisation de -W or -L.
Cependant, chaque couche ajoute une surcharge supplémentaire, car elle finit par transporter SSH en SSH en SSH en SSH.
Notez que chaque hôte, sauf le plus externe, liste une ProxyCommand via le serveur immédiatement avant lui. Si vous aviez 3 serveurs, vous utiliseriez [webserverA via bastionC], [bastionC via bastionB], et [bastionB via bastionA].
Méthode 2 - pas à pas
Hôte webserverA
ProxyCommand ssh bastionA -A ssh bastionB -W %h:%p
Cette méthode initie les connexions pas à pas, exécutant ssh à chaque étape pour se connecter à la suivante. Par conséquent, un agent ssh et ForwardAgent doivent être activés (ou GSSAPIDelegateCredentials si vous utilisez Kerberos); tout autre configuration spéciale .ssh/config doit être copiée sur tous les hôtes de bastion.
Par contre, cela entraîne moins de surcharge de protocole (maximum deux couches à chaque étape).
(Modification : ajout de -A pour toujours demander le transfert d'agent.)
