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