Login de chave pública / privada do SSH

Question

Estou tentando fazer com que o ssh trabalhe com as chaves pp. No entanto, depois de ter seguido vários howto, ainda tenho problemas com o login. O servidor é opensuse 12.1, o cliente é mac. Esta é a saída detalhada:

 debug1: Reading configuration data /etc/ssh_config
 debug1: Applying options for *
 debug1: Connecting to 192.168.1.139 [192.168.1.139] port 22.
 debug1: Connection established.
 debug1: identity file /Users/me/.ssh/id_rsa type 1
 debug1: identity file /Users/me/.ssh/id_rsa-cert type -1
 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8
 debug1: match: OpenSSH_5.8 pat OpenSSH*
 debug1: Enabling compatibility mode for protocol 2.0
 debug1: Local version string SSH-2.0-OpenSSH_5.6
 debug1: SSH2_MSG_KEXINIT sent
 debug1: SSH2_MSG_KEXINIT received
 debug1: kex: server->client aes128-ctr hmac-md5 none
 debug1: kex: client->server aes128-ctr hmac-md5 none
 debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
 debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
 debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
 debug1: Host '192.168.1.139' is known and matches the RSA host key.
 debug1: Found key in /Users/me/.ssh/known_hosts:7
 debug1: ssh_rsa_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,keyboard-interactive
 debug1: Next authentication method: publickey
 debug1: Offering RSA public key: /Users/me/.ssh/id_rsa
 debug1: Authentications that can continue: publickey,keyboard-interactive
 debug1: Next authentication method: keyboard-interactive
 Password: 

Alguém tem uma ideia de onde procurar? obrigado

    

Answer 1

Não é possível depurar isso ainda mais do lado do cliente. O cliente está oferecendo a chave, não sendo aceita, deve ser um problema no lado do servidor. A maneira mais rápida de descobrir o motivo, se for possível, é iniciar outro sshd no modo de depuração, que informará exatamente por que a chave foi rejeitada. No lado do servidor:

/usr/sbin/sshd -d -p 2222

que iniciará um sshd no modo de depuração na porta 2222 (uma porta diferente para que não perturbemos o servidor que está sendo executado na porta 22).

Em seguida, no lado do cliente:

ssh -p 2222 user@remotehost

Você deve ver a razão pela qual sua chave foi rejeitada no terminal onde você inicia o sshd.

Geralmente, o problema é que as permissões são muito frouxas. O arquivo authorized_keys e toda a ancestralidade do diretório não devem ser graváveis por ninguém além do usuário. Portanto, se o arquivo authorized_keys estiver em /home/username/.ssh/authorized_keys, então, por exemplo, /, / home, / home / username, todos NÃO poderão ser graváveis em grupo.

    

Answer 2

Parece que as chaves são geradas no sistema que não aquele ao qual você está tentando se conectar. Gere a chave no sistema do qual você está tentando se conectar.

Você está se conectando ao túnel VPN primeiro e depois ao servidor. Se for esse o caso, você também receberá o mesmo erro, porque você não está mais se conectando da sua máquina a recursos protegidos.