Uau, obrigado por fazer esta pergunta. Acho raro ver alguém explorando totalmente o SSH e essa questão atinge algumas áreas.
Este não é um problema de ProxyCommand . O ProxyCommand simplesmente instrui o cliente ssh local a fazer algo em preparação antes de tentar conversar com o cliente remoto. Sim, em nossa instância, conversamos com outra sessão ssh, mas essa sessão, com o -W simplesmente pega nossa entrada e a encaminha para outra máquina. Você pode pensar que a sessão de ssh preparatória é completamente independente. Inevitável analogia com o carro: seu carro é o mesmo carro, independentemente de você ter que pegar uma balsa para ir do ponto A ao ponto B.
Este não é um problema de ForwardAgent . ForwardAgent tem o cliente local fornecendo um recurso que disponibiliza as chaves locais no ambiente da sessão remota. Você não passou de estabelecer a sessão remota.
É um problema de .ssh/config format. Observe as segundas e terceiras linhas debug1. Eles listam quais sub-rotinas do Host estão sendo aplicadas a partir do seu .ssh/config . Você nota que $ ssh target.example.com%via funciona, mas como nome de usuário e chave incorretos. Bem, a sub-rotina para Host target não está sendo lida (o que forneceria o nome de usuário e o arquivo de chaves corretos). Quais estrofes são usadas? * e *%via .
Como obter essas opções para passar? Bem, interessante o suficiente, o curinga combina cadeias de comprimento 0. Host target* corresponderá a target , target%via , target.example.com e target.example.com%via .
E então você faz a pergunta, definindo um .ssh/config na ajuda da máquina gateway . Não, não seria. Nunca seria lido. Tudo está acontecendo na nossa máquina local.
Tudo o que expliquei, apenas responde por que $ ssh target.example.com%via não está funcionando.
Você prefere $ ssh target%via . Com razão, é mais conveniente. A forma abreviada está falhando porque, como um nome de host, target não é encontrado; não está resolvendo. Por que não não é vomitar ssh: ssh: Could not resolve hostname target: Name or service not known ? Porque o ProxyCommand já foi estabelecido com sucesso. Elementos de uma conexão ssh foram construídos, mas a falha do nome do host está acontecendo onde não está esperando, e por isso está bombardeando com a mensagem mais genérica. Eu enviaria um relatório de bug sobre isso, para ajudar a identificar onde as informações de depuração poderiam ser melhoradas.
Comentário final:
Eu gosto da sintaxe Host *%via . É limpo, mas flexível. Eu já tinha visto Host *+* e ele usa a primeira e a última parte do %h(ost) para determinar para onde ir. Mas é preciso um pouco mais de esforço para entender isso.
link: link