Estou tentando configurar algumas opções universais para saltar conexões ssh. Aqui está meu ~/.ssh/configarquivo, 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 *%viaos Hostaliases, obtenho:
% 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
Atingi o servidor de destino, mas como o usuário errado e sem autenticação pubkey.
EUpensarminha pergunta, neste momento, é se esse método de salto, ao utilizar ForwardAgent, passa pela minha configuração/ambiente ssh inteiro ou apenas pelas chaves. Se forem apenas chaves, as primeiras podem ser utilizadas de alguma forma?
Minha versão ssh é 5.9v1, o gateway é 5.9v1 e o destino é 5.3p1. Acredito -Wque foi introduzido no 5.4, mas isso não deveria importar para a caixa final da fila? utilizar a escola mais antiga ncnão parece diferente.
Verifiquei que posso fazer ssh manualmente em cada caixa da linha. Fazer isso indica que as informações do alias do nome do host não foram passadas, como quando no gateway, não posso, ssh targetmas posso ssh target.example.com. Isso funciona com autenticação 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 enviada.
Se ForwardAgentuma configuração semelhante não puder enviar essas informações, qual é a maneira mais sensata de contornar isso, mantendo um .ssh/config no gateway com essas informações?
Responder1
Uau, obrigado por fazer esta pergunta. Acho raro ver alguém explorando totalmente o SSH e essa questão atinge algumas áreas.
Isto não é um ProxyCommandproblema. O ProxyCommandsimplesmente instrui o cliente ssh local a fazer algo de preparação antes de tentar falar com o cliente remoto. Sim, em nossa instância, conversamos com outra sessão ssh, mas essa sessão simplesmente -Wpega nossa entrada e a encaminha para outra máquina. Você pode pensar que a sessão preparatória do ssh é completamente independente. Analogia inevitável com o carro: seu carro é o mesmo carro, independentemente de você ter que pegar uma balsa para ir do ponto A ao ponto B.
Isso não é um ForwardAgentproblema. ForwardAgentfaz com que o cliente local forneça um recurso que disponibilize chaves locais no ambiente da sessão remota. Você ainda não conseguiu estabelecer a sessão remota.
É uma .ssh/configquestão de formato. Observe a segunda e terceira linhas debug1. Eles listam quais sub-rotinas Host estão sendo aplicadas no seu arquivo .ssh/config. Você nota que $ ssh target.example.com%viafunciona, mas como nome de usuário e chave errados. Bem, a estrofe para Host targetnão está sendo lida (o que forneceria o nome de usuário e o arquivo-chave corretos). Quais estrofes são usadas? *e *%via.
Como fazer com que essas opções sejam aprovadas? Bem, interessante o suficiente, o curinga corresponde a strings de comprimento 0. Host target*corresponderá a target, target%via, target.example.come target.example.com%via.
E então você faz a pergunta: configurar um .ssh/configna gatewaymáquina ajudaria. Não, não seria. Nunca seria lido. Tudo está acontecendo em nossa máquina local.
Tudo o que expliquei apenas responde por que $ ssh target.example.com%vianão está funcionando.
Você prefere $ ssh target%via. Com razão, é mais conveniente. A forma abreviada está falhando porque, como nome de host, targetnão foi encontrado; não está resolvendo. Por que o ssh não está vomitando: ssh: Could not resolve hostname target: Name or service not known? Porque o ProxyCommandjá 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 era esperada e, portanto, está bombardeando com uma mensagem mais genérica. Eu registraria 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 Host *%viasintaxe. É limpo, mas flexível. Eu já tinha visto Host *+*e ele usa a primeira e a última parte %h(ost)para determinar para onde ir. Mas é preciso um pouco mais de esforço para entender isso. link:http://wiki.gentoo.org/wiki/SSH_jump_host