conexão SSH pede senha embora chave seja aceita

Question

Estou sendo solicitado a fornecer uma senha, embora pareça que minha chave SSH seja aceita. Tanto quanto eu posso dizer, a linha "Servidor aceita chave: pkalg ssh-rsa blen 277" nos logs abaixo significa que minha chave é aceita.

Aqui estão os registros de depuração:

debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/sam/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug2: input_userauth_pk_ok: fp <<HASH REDACTED>>
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /home/sam/.ssh/id_dsa
debug1: Trying private key: /home/sam/.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1

Ajuda muito apreciada, todos que encontrei com problemas de SSH falham em um ponto anterior que estou vendo.

    

Answer 1

Sua chave privada foi certamente não aceita, só foi tentada. Existem várias maneiras pelas quais a autenticação baseada em chave SSH pode falhar, e o registro em log não é realmente tão grande, portanto depurar esse problema em particular é um dos meus problemas pessoais. Descobri que o erro é geralmente resultante de uma das seguintes situações.

• Seu arquivo ~/.ssh/authorized_keys é muito aberto. Para sua própria proteção, sshd tenta protegê-lo de si mesmo. Se as permissões em seu arquivo de chaves autorizadas, ele falhará a autenticação. Executar chmod -R go-rwx ~/.ssh .
• Sua chave pública em ~/.ssh/authorized_keys está malformada. Isso pode ser resultado de vários problemas, mas o mais comum é um problema de copiar e colar. Alguns terminais, quando copiam / colam em telas, interpretam uma quebra de linha como uma nova linha. Cada entrada no arquivo authorized_keys deve ser uma única linha. Você pode verificar isso alterando o tamanho do seu emulador de terminal e verificando se há uma pausa, comparando a saída de wc -l ~/.ssh/authorized_keys com o número de chaves que devem estar lá, ou o que for melhor para você . Apenas certifique-se de que cada chave é uma linha e você deve estar bem.

Answer 2

A saída ssh -v que você colou sugeriu que ele tentou usar a chave, mas isso não funcionou, então ela passou para o teclado interativo.

Você verificou o log de autenticação no servidor ao qual está se conectando? (por exemplo, /var/log/auth.log). Se sua configuração no final remoto estiver incorreta, por exemplo, permissões erradas, então ssh -v (ou -vv ou -vvv) não lhe dirá isso, mas será registrado pelo sshd.

    

Answer 3

No meu caso, o arquivo /var/log/authlog mostrou:

[ID 800047 auth.info] Authentication refused: bad ownership or modes for directory 

Eu tinha verificado a propriedade / permissões corretas em .ssh , mas o $HOME tinha 777 permissões. Configurar 755 permissões em $HOME permitiu que o sftp funcionasse. Obrigado novamente.

    

Answer 4

Se você tiver acesso ao servidor (diretamente ou através de outro login), verifique os logs do servidor em (digamos) / var / log / sshd

Geralmente é causado por um erro de permissão no seu arquivo ~ / .ssh / authorized_keys. Certifique-se de que não é legível pelo mundo, mas crucialmente que é legível pelo usuário (às vezes um usuário do serviço) executando sshd

    

Answer 5

Permissões de ~/.ssh/authorized_keys no controle remoto são importantes ( 600 para meus sistemas RHEL e Solaris)

As permissões do seu diretório pessoal no controle remoto são importantes ( 700 em meus sistemas)

No final, executar sshd na máquina remota no modo de depuração em outra porta pode ser útil:

sudo /usr/sbin/sshd -p 5555 -dd

5555 é uma porta de exemplo, você pode alterá-la. Para mais informações sobre esse assunto, você pode ver: link

    

Answer 6

Descobri que há um problema se eu usar o serviço sshd . Para evitar esse problema, pare o sshd service com service sshd stop e inicie o daemon sshd no prompt de comando com sudo /usr/sbin/sshd .

    

Answer 7

Tente

/sbin/restorecon -r /root/.ssh

Um possível problema com a configuração de permissões.