A conexão SSH solicita a senha, embora a chave seja aceita

Estou recebendo uma senha, mesmo que pareça que minha chave SSH foi aceita. Até onde eu sei, a linha "Servidor aceita chave: pkalg ssh-rsa blen 277" nos logs abaixo significa que minha chave é aceita.

Aqui estão os logs 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 que estão com problemas de SSH falham em um ponto anterior que estou vendo.

Sua chave privada certamente não foi aceita, apenas foi tentada. Existem várias maneiras pelas quais a autenticação baseada em chave SSH pode falhar, e o registro não é realmente tão bom, portanto a depuração desse problema específico é uma das minhas irritações pessoais. Descobri que o erro geralmente é resultado de uma das seguintes situações.

• Seu ~/.ssh/authorized_keysarquivo está muito aberto. Para sua própria proteção, sshdtenta protegê-lo de si mesmo. Se as permissões no seu arquivo de chaves autorizadas falharem na autenticação. Corra chmod -R go-rwx ~/.ssh.
• Sua chave pública ~/.ssh/authorized_keysestá incorreta. Isso pode resultar de vários problemas, mas o mais comum é um problema de copiar e colar. Alguns terminais, ao copiar / colar nas telas, interpretam uma quebra de linha como uma nova linha. Cada entrada no authorized_keysarquivo deve ser uma única linha. Você pode verificar isso alterando o tamanho do emulador de terminal e verificando se há uma interrupção, comparando a saída wc -l ~/.ssh/authorized_keyscom o número de chaves que devem estar lá ou o que funcionar melhor para você. Apenas certifique-se de que cada tecla tenha uma linha e você deve ficar bem.

A saída ssh -v que você colou sugeriu que ele tentou usar a tecla, mas que não funcionou, por isso 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 terminal remoto estiver incorreta, por exemplo, permissões erradas, o ssh -v (ou -vv ou -vvv) não informará isso, mas será registrado pelo sshd.

No meu caso, o arquivo /var/log/authlogmostrou:

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

Eu verifiquei a propriedade / permissões corretas, .sshmas as $HOMEpermissões tinham 777. Definir 755 permissões no $HOMEsftp permitido para funcionar. Obrigado novamente.

Se você tiver acesso ao servidor (diretamente ou através de outro login), verifique os logins do servidor (digamos) /var/log/sshdou /var/log/securedependendo do seu sistema

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

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

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

No final, executar sshdna 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 a esse respeito, você pode ver: http://ubuntuforums.org/archive/index.php/t-2219973.html

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

Experimentar

/sbin/restorecon -r /root/.ssh

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