Je pense que le problème de votre exemple réside dans les arguments finaux. ssh à B, alors que vous devriez énumérer les "destination finale" mais l'hôte/port transféré, qui est le port 10000, mais qui devrait être localhost , pas B , comme B est résolue du point de vue de la A et le port 10000 sur B n'est probablement pas ouvert à l'extérieur . Par exemple, corrigé :
ssh -ti key_file_for_C_on_A -l user_on_C -o "ProxyCommand ssh -ti key_file_for_B_on_A -W %h:%p user_on_B@B" -p 10000 localhost
Pour m'en convaincre, j'ai mis en place la même expérience, bien que légèrement plus simple puisque mon nom d'utilisateur est le même sur tous les hôtes, et que j'utilise la redirection d'agent ; notez que mon hophost (votre B ) accepte ssh sur un port non standard, 2222.
Sur C :
ssh -fNAR 12345:localhost:22 hophost -p 2222
Puis sur A :
ssh -A localhost -p 12345 -o "ProxyCommand ssh -A hophost -p 2222 nc %h %p"
Alternativement, vous pouvez encoder tout cela dans votre fichier .ssh/config sur A :
Host C
HostName localhost
Port 12345
ForwardAgent yes
#ProxyCommand ssh -A hophost -p 2222 nc %h %p
ProxyCommand ssh -A hophost -p 2222 -W %h:%p
#ProxyCommand $HOME/.ssh/proxy -w 2 -h hophost:2222 %h %p
Dans ce cas, votre commande sur A est simplement
ssh C
Note : J'ai également inclus deux alternatives ProxyCommand versions. La première utilise nc au cas où votre ssh est antérieure à la version 5.3, lorsque l'option -W a été ajoutée. L'autre utilise un proxy script que j'utilise depuis longtemps pour passer à travers certains hôtes (comme dans cet exemple) et utiliser la fonction corkscrew pour s'affranchir des pare-feu qui bloquent les flux sortants. ssh . Vous pouvez voir le ssh-proxy script sur mon github. Il simplifie ~/.ssh/config lorsque vous souhaitez utiliser un proxy pour Host * mais je ne promets pas que cela fonctionne toujours dans toutes les situations, car je l'ai modifié au fil du temps en fonction des situations, de sorte que toutes les options peuvent être fragiles ou même défectueuses, mais cela peut aider.
