Por que o login automático por meio de ssh com authorized_keys não funciona?

Embora o seu problema já possa ter sido resolvido por outras respostas, eu me bloqueei de máquinas suficientes para não validar as alterações de sshd_config antes de assinar, então criei o processo abaixo que pode ser útil para depuração futura de alterações de configuração de sshd:

NÃO DESCONECTE uma conexão ssh ativa até APÓS o teste verificar se o comportamento é o esperado.

uma. verifique o que você acha que o sshd deveria estar fazendo

b. verifique se a configuração é válida usando "-t"

c. iniciar uma versão detalhada de 'teste' do servidor que você pode monitorar ao vivo

d. iniciar uma conexão de cliente de 'teste' detalhada que você pode monitorar ao vivo

uma. verifique o que você acha que o sshd deveria estar fazendo

Revise o arquivo de configuração sshd sem todos os comentários com algo como o abaixo (assumindo que sshd_config é o arquivo correto e em/etc/ssh)

$ grep -v "^ #"/etc/ssh/sshd_config | grep -v "^ $"

Isso apenas esclarece as coisas, então verificamos o que achamos que estamos mudando (não necessariamente se está correto ou não).

b. verifique se a configuração é válida usando "-t"

Na página de manual do sshd que estou usando,

-t Modo de teste. Verifique apenas a validade do arquivo de configuração e a integridade das chaves. Isso é útil para atualizar o sshd de forma confiável, pois as opções de configuração podem mudar.

Outras mudanças podem ter circunstâncias mais sutis. Por exemplo, não desative a autenticação de senha até ter certeza de que a autenticação de chave pública está funcionando corretamente.

c. iniciar uma versão detalhada de 'teste' do servidor que você pode monitorar ao vivo

$ Sudo/usr/sbin/sshd -ddd -p 9999

Isso mantém sua sessão de trabalho existente ativa, mas fornece outra instância do sshd para verificar suas novas mudanças de configuração. O SSHD agora está sendo executado em primeiro plano para uma porta definida pelo usuário (9999 em nosso exemplo) e enviando muitas informações de depuração barulhentas que você pode rastrear em/var/log/authlog (ou possivelmente /var/log/auth.log dependendo no seu sistema operacional.)

d. iniciar uma conexão de cliente de 'teste' detalhada que você pode monitorar ao vivo

Execute a conexão do cliente ssh no modo verbose para exibir em sua tela mais informações que podem levá-lo a depurar melhor o erro.

$ ssh -vvv -p 9999 nome do servidor

Agora você deve ter informações suficientes nos arquivos de log do servidor ou na tela de conexão do cliente para isolar o problema.

A solução geralmente se resume a permissões de arquivo (como mostrado por Magnar e setatakahashi)

Boa sorte