Faça com que o ssh resolva os nomes de host da configuração ao usar o ProxyCommand e o modo netcat

16

Estou tentando configurar algumas opções universais para as conexões ssh. Aqui está o meu arquivo ~/.ssh/config , abreviado:

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

Quando utilizo *%via utilizando os Host aliases, recebo:

% 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

No entanto, se eu utilizar

% ssh target.example.com%via

Eu acertei o servidor de destino, mas como o usuário errado e sem autenticação de pubkey.

Eu acho que minha pergunta, neste ponto, é que esse método de rejeição, quando utilizo ForwardAgent , passa pelo meu ssh config / environment inteiro, ou apenas chaves. Se apenas as chaves, o primeiro pode ser utilizado de alguma forma?

Minha versão do ssh é 5.9v1, o gateway é 5.9v1 e o destino é 5.3p1. Eu acredito que -W foi introduzido em 5.4, mas isso não deve importar para a caixa final na fila? utilizando a escola antiga nc não parece diferente.

Eu verifiquei que posso manualmente ssh para cada caixa na linha. Isso indica que as informações do alias do nome do host não são transmitidas, como quando no gateway, não consigo ssh target , mas posso ssh target.example.com . Isso funciona com o auth do pubkey. gateway e destino, aliás, têm o mesmo nome de usuário, e é por isso que isso funciona se nenhuma configuração for pressionada.

Se ForwardAgent ou configuração similar não puder enviar essas informações, qual é a melhor maneira de contornar isso, mantendo um .ssh / config no gateway com essas informações?

    
por Joshua Hogendorn 27.09.2013 / 09:45

1 resposta

13

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

    
por 27.09.2013 / 14:12

Tags