A autenticação de chaves SSH continua pedindo senha

Question

Estou tentando definir o acesso do ServerA (SunOS) para o ServerB (Algum Linux personalizado com login interativo do teclado) com chaves SSH. Como prova de conceito, consegui fazê-lo entre duas máquinas virtuais. Agora, no meu cenário da vida real, não está funcionando.

Eu criei as chaves no ServerA, copiei-as para o ServerB, as pastas .ssh chmod'd para 700 no ServerA, B.

Aqui está o log do que eu recebo.

    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: Peer sent proposed langtags, ctos:
    debug1: Peer sent proposed langtags, stoc:
    debug1: We proposed langtags, ctos: en-US
    debug1: We proposed langtags, stoc: en-US
    debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
    debug1: dh_gen_key: priv key bits set: 125/256
    debug1: bits set: 1039/2048
    debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
    debug1: Host 'XXX.XXX.XXX.XXX' is known and matches the RSA host key.
    debug1: Found key in /XXX/.ssh/known_hosts:1
    debug1: bits set: 1061/2048
    debug1: ssh_rsa_verify: signature correct
    debug1: newkeys: mode 1
    debug1: set_newkeys: setting new keys for 'out' mode
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug1: newkeys: mode 0
    debug1: set_newkeys: setting new keys for 'in' mode
    debug1: SSH2_MSG_NEWKEYS received
    debug1: done: ssh_kex2.
    debug1: send SSH2_MSG_SERVICE_REQUEST
    debug1: got SSH2_MSG_SERVICE_ACCEPT
    debug1: Authentications that can continue: publickey,keyboard-interactive
    debug1: Next authentication method: publickey
    debug1: Trying private key: /XXXX/.ssh/identity
    debug1: Trying public key: /xxx/.ssh/id_rsa
    debug1: Authentications that can continue: publickey,keyboard-interactive
    debug1: Trying private key: /xxx/.ssh/id_dsa
    debug1: Next authentication method: keyboard-interactive
    Password:
    Password:

O ServerB tem ações bastante limitadas, já que é um linux propietário personalizado.

O que poderia estar acontecendo?

EDITAR COM RESPOSTA:

O problema foi que eu não tinha essas configurações ativadas no sshd_config (Consulte a resposta aceita) E que, ao colar a chave do ServerA para o ServerB, ele interpretaria a chave como 3 linhas separadas.

O que eu fiz foi, no caso de você não conseguir usar o ssh-copy-id como eu não poderia. Cole a primeira linha da sua chave no seu arquivo "ServerB" authorized_keys sem os dois últimos caracteres, digite os caracteres que faltam da linha 1 e o primeiro da linha 2, isso evitará adicionar uma "nova linha" entre a primeira e segunda linha da chave. Repita com a linha 3d.

    

Answer 1

Eu não acho que suas chaves foram copiadas corretamente, se você tem ssh-copy-id disponível eu recomendo que você use isso.

$ ssh-copy-id user@remote_server
Password:

Uma vez que você tenha digitado a senha, sua chave SSH será copiada e você deverá ser capaz apenas de ssh sem fornecer a senha novamente.

Verifique também a configuração do SSH em ServerB e verifique algumas coisas.

$ vi /etc/ssh/sshd_config

Outra coisa é verificar essas configurações:

RSAAuthentication yes
PubKeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys

O valor de AuthorizedKeysFile é onde você precisa colar sua chave ssh pública.

Você pode coletar suas informações de chave SSH usando: ssh-add -L

Atualizado

Quando ssh-copy-id não existe, você pode fazer da maneira antiga:

$ cat ~/.ssh/id_rsa.pub | ssh user@remote_host 'cat >> /home/user/.ssh/authorized_keys'

    

Answer 2

Seu registro de depuração mostra que o servidor não aceitou nenhuma das suas chaves RSA privadas. Você deve especificar o arquivo de chaves correto específico ou verificar se o servidor tem o arquivo de chave pública correto.

Como disse @Fredrik, permissões em arquivos também podem desempenhar um papel. O SSH se recusará a usar entradas de chave pública que outras pessoas possam gravar e entradas de chave privada que outras pessoas possam ler.

    

Answer 3

Com base no acima, não posso dizer qual é o problema. No entanto, na maioria das vezes, eu encontrei isso porque as chaves tiveram seus direitos definidos para serem legíveis (como legíveis para grupos ou outros, não apenas para o usuário). É onde eu começaria a procurar.

    

Answer 4

Esses problemas (que são geralmente relacionados a permissões) são muito mais facilmente depurados do lado do servidor. Eu recomendo que você inicie outro sshd no modo de depuração com: /usr/sbin/sshd -d -p 2222 que iniciará outro sshd na porta 2222, então execute ssh -p 2222 user@sshserver no lado do cliente. Veja o que sai do sshd quando seu cliente tenta autenticar.

Os problemas de permissões não precisam ser apenas /home/$USER/.ssh . Também pode haver um problema com / , /home ou /home/$USER . Se algum deles for de grupo, pode ser um problema.

Outro problema comum é que você cola mal e coloca quebras de linha no meio da sua chave no arquivo authorized_keys

    

Answer 5

A maneira mais fácil de configurar as chaves é executando

ssh-copy-id <remotehost>

na máquina que será conectada (sua estação de trabalho, por exemplo)

Ele deve pedir sua senha e, em seguida, copiar sua chave e configurar as permissões adequadamente.

    

Answer 6

Você deve verificar a permissão dos arquivos na máquina remota usando ls -l ~/.ssh e configurar a permissão:
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/<private_key> Ex: chmod 600 ~/.ssh/id_rsa a chmod 700 ~/.ssh/<public_key> Ex: chmod 700 ~/.ssh/id_rsa.pub
chmod 700 /home/vmirea/.ssh