Demandez à ssh de résoudre les noms d'hôtes à partir de la configuration lors de l'utilisation de ProxyCommand et du mode netcat

J'essaie de mettre en place des options universelles pour rebondir les connexions ssh. Voici mon ~/.ssh/configdossier, abrégé:

Host *%via
  ProxyCommand ssh gateway -W $(echo %h | cut -d%% -f1) %p

Host gateway
  HostName gateway.example.com
  User username
  ForwardAgent yes
  IdentityFile keypathg

Host target
  User username
  HostName target.example.com
  IdentityFile keypatht

Lorsque j'utilise en *%viautilisant les Hostalias, j'obtiens:

% ssh -vvv target%via
OpenSSH_5.9p1, OpenSSL 0.9.8y 5 Feb 2013
debug1: Reading configuration data /Users/myuser/.ssh/config
debug1: /Users/myuser/.ssh/config line 5: Applying options for *
debug1: /Users/myuser/.ssh/config line 12: Applying options for *%via
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: auto-mux: Trying existing master
debug1: Control socket "/Users/myuser/.ssh/tmp/target%via_22_myuser" does not exist
debug2: ssh_connect: needpriv 0
debug1: Executing proxy command: exec ssh -A gateway -W $(echo target%via | cut -d% -f1):22
debug1: permanently_drop_suid: 501
debug1: identity file /Users/myuser/.ssh/id_rsa type -1
debug1: identity file /Users/myuser/.ssh/id_rsa-cert type -1
debug1: identity file /Users/myuser/.ssh/id_dsa type -1
debug1: identity file /Users/myuser/.ssh/id_dsa-cert type -1
ssh_exchange_identification: Connection closed by remote host

Cependant, si j'utilise

% ssh target.example.com%via

J'ai frappé le serveur cible, mais en tant que mauvais utilisateur et sans authentification de clé publique.

Je pense que ma question, à ce stade, est de savoir si cette méthode de rebond, lors de l'utilisation ForwardAgent, passe par l'ensemble de ma configuration / environnement ssh, ou simplement par des clés. S'il ne s'agit que de clés, les premières peuvent-elles être utilisées d'une manière ou d'une autre?

Ma version ssh est 5.9v1, la passerelle est 5.9v1 et la cible est 5.3p1. Je crois que cela a -Wété introduit en 5.4, mais cela ne devrait pas avoir d'importance pour la dernière case en ligne? utiliser l'ancienne école ncne semble pas différent.

J'ai vérifié que je peux manuellement ssh dans chaque case de la ligne. Cela indique que les informations d'alias de nom d'hôte ne sont pas transmises, car lorsque sur la passerelle, je ne peux pas ssh targetmais je peux ssh target.example.com. Cela fonctionne avec l'authentification pubkey. la passerelle et la cible ont d'ailleurs le même nom d'utilisateur, c'est pourquoi cela fonctionne si aucune configuration n'est poussée.

Si ForwardAgentou une configuration similaire ne peut pas pousser ces informations, quel est le moyen le plus sûr de les contourner, en conservant une .ssh / config sur la passerelle avec ces informations?

Wow, merci d'avoir posé cette question. Je trouve qu'il est rare de voir quelqu'un exploiter pleinement SSH et cette question frappe sur quelques domaines.

Ce n'est pas un ProxyCommandproblème. Le ProxyCommanddemande simplement au client ssh local de faire quelque chose en préparation avant d'essayer de parler au client distant. Oui, dans notre exemple, nous parlons à une autre session ssh, mais cette session, avec -Wprend simplement notre entrée et la transmet à une autre machine. Vous pouvez penser que cette session préparatoire ssh est complètement indépendante. Analogie inévitable de voiture: votre voiture est la même voiture, que vous ayez ou non dû prendre un ferry pour aller d'un point A à un point B.

Ce n'est pas un ForwardAgentproblème. ForwardAgentdemande au client local de fournir une fonctionnalité qui rend les clés locales disponibles dans l'environnement de la session distante. Vous n'avez pas réussi à établir la session à distance.

C'est un .ssh/configproblème de format. Notez les deuxième et troisième lignes debug1. Ils répertorient les strophes Host appliquées à partir de votre .ssh/config. Vous notez que cela $ ssh target.example.com%viafonctionne, mais comme nom d'utilisateur et clé incorrects. Eh bien, la strophe de Host targetn'est pas lue (ce qui fournirait le nom d'utilisateur et le fichier de clés corrects). Quelles strophes sont utilisées? *et *%via.

Comment faire passer ces options? Eh bien, assez intéressant, le caractère générique correspond à 0 chaîne de longueur. Host target*correspondra target, target%via, target.example.comet target.example.com%via.

Et donc vous posez la question, serait de définir un .ssh/configsur l' gatewayaide de la machine. Non, ce ne serait pas le cas. Il ne serait jamais lu. Tout se passe depuis notre machine locale.

Tout ce que j'ai expliqué, ne répond que pourquoi $ ssh target.example.com%viane fonctionne pas.

Tu préfères $ ssh target%via. À juste titre, c'est plus pratique. Le formulaire court échoue car, en tant que nom d'hôte, il targetest introuvable; ça ne résout pas. Pourquoi n'est pas crachant ssh: ssh: Could not resolve hostname target: Name or service not known? Parce que le ProxyCommanda déjà été établi avec succès. Des éléments d'une connexion ssh ont été construits, mais l'échec du nom d'hôte se produit là où il ne l'attend pas, et c'est donc le bombardement avec le message plus générique. Je déposerais un rapport de bogue à ce sujet, pour aider à identifier où les informations de débogage pourraient être améliorées.

Commentaire final:

J'aime bien la Host *%viasyntaxe. C'est propre, mais flexible. J'avais déjà vu Host *+*et il utilise à la fois la première et la dernière partie du %h(ost)pour déterminer où aller. Mais il faut un peu plus d'efforts pour se faire une idée. lien: http://wiki.gentoo.org/wiki/SSH_jump_host