layerd ssh connections - o segundo comando ssh procura chaves no diretório errado

1

Estou logado em um servidor chamado Walnut, do qual eu tento entrar em outro servidor chamado Hazelnut.

local machine (mac) ---ssh---> Walnut ---ssh---> Hazelnut

O primeiro ssh (da minha máquina local para Walnut) corre bem.

O segundo comando ssh, no entanto, me dá permissão negada.

Veja o que os registros dizem quando eu faço ssh -v -A Haezlnut .

debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to Hazelnut [address] port [port].
debug1: Connection established.
debug1: identity file /home/username/.ssh/id_rsa type -1
debug1: identity file /home/username/.ssh/id_rsa-cert type -1
debug1: identity file /home/username/.ssh/id_dsa type -1
debug1: identity file /home/username/.ssh/id_dsa-cert type -1
debug1: identity file /home/username/.ssh/id_ecdsa type -1
debug1: identity file /home/username/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Debian-5+deb8u2
debug1: match: OpenSSH_6.7p1 Debian-5+deb8u2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug1: kex: client->server aes128-ctr hmac-sha1 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: [Host key]
debug1: Host 'Hazelnut' is known and matches the ECDSA host key.
debug1: Found key in /home/username/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/username/.ssh/id_rsa
debug1: Trying private key: /home/username/.ssh/id_dsa
debug1: Trying private key: /home/username/.ssh/id_ecdsa
debug1: No more authentication methods to try.
Permission denied (publickey).

Então, acho que os registros indicam claramente que ele não está conseguindo encontrar o arquivo-chave no final. O que é confuso é que, como a chave privada reside na máquina local do Mac, ele deve procurar o arquivo em /Users/username/.ssh/ , não /home/username/.ssh/ . O primeiro comando ssh (do local para Walnut) faz isso bem, mas o segundo comando (de Walnut a Hazelnut) de alguma forma estraga tudo.

O que é mais confuso é que o mesmo processo funciona perfeitamente em muitas outras máquinas mac aparentemente idênticas. Se você tentar ssh em Hazelnut de Walnut usando qualquer outra máquina do mac, ele tentará procurar o arquivo de chave no diretório correto ( /Users/username/.ssh ).

Alguém já teve esse problema antes?

    
por jeebface 20.09.2017 / 02:02

1 resposta

0

Você precisa fazer com que seu agente ssh esteja disponível em walnut usando este comando do seu mac: ssh -A walnut , em seguida, ssh para avelã.

Fazer esse tipo de coisa é considerado uma prática ruim, pois expõe seu agente à máquina remota. Se um atacante estiver em nogueira, é possível que eles roubem suas chaves privadas.

Ou túnel para avelã. Existem muitas maneiras de fazer isso ...

Use a opção -J - um atalho para a opção ProxyJump (openssh ver. 7.3+ Required):

ssh -J <jumphost> <target>

A opção ProxyCommand usando o netcat no host de salto:

ssh -o ProxyCommand="ssh %h nc <target> 22" <jumphost>

ou o ProxyCommand com a opção -W:

ssh -o ProxyCommand="ssh -W %h:%p <jumphost>" <target>

As diretivas de configuração proxycommand ou ProxyJump também podem ser colocadas no arquivo de configuração ssh para o mesmo efeito

    
por 20.09.2017 / 03:24