Por que o login automático através do ssh com authorized_keys não funciona?

10

Eu criei um dsa-keypair privado / público. Eu coloquei a chave pública no servidor em

~/.ssh/authorized_keys

Tudo está configurado como o meu outro servidor, mas parece que o servidor está apenas ignorando meus esforços.

    
por Magnar 30.04.2009 / 13:17

4 respostas

12

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

NÃO DESCONECTE uma conexão ssh ativa até que o teste tenha um comportamento verificado conforme esperado.

a. verificar 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 'test' do servidor que você pode monitorar ao vivo

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

a. verificar o que você acha que o sshd deveria estar fazendo

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

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

Isso apenas elimina 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"

A partir da página man do sshd que estou usando,

-t Test mode. Only check the validity of the configuration file and sanity of the keys. This is useful for updating sshd reliably as configuration options may change.

Outras alterações podem ter circunstâncias mais sutis. Por exemplo, não desabilite 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 'test' do servidor que você pode monitorar ao vivo

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

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

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

Execute a conexão do cliente ssh no modo detalhado para exibir na tela mais informações que podem levar a uma melhor depuração do erro.

$ ssh -vvv -p 9999 server-name

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 arquivos (como mostrado por Magnar e setatakahashi)

Melhor da sorte

    
por 24.05.2009 / 16:22
32

O servidor irá ignorar seu arquivo authorized_keys se as propriedades do proprietário estiverem erradas. Alterá-lo para isso corrige:

chmod 0700 ~/.ssh
chmod 0600 ~/.ssh/authorized_keys
    
por 30.04.2009 / 13:19
10

$ chmod 700 ~

$ chmod 700 ~/.ssh

$ chmod 600 ~/.ssh/authorized_keys

Verifique esses atributos em / etc / ssh / sshd_config

$ sudo grep PubkeyAuthentication /etc/ssh/sshd_config

$ sudo grep Protocol /etc/ssh/sshd_config

    
por 01.05.2009 / 04:58
0

Outra armadilha importante ..

Se o seu diretório pessoal estiver criptografado , o sshd não terá acesso a ~ / .ssh / authorized_keys.

Veja esta resposta

    
por 08.03.2018 / 17:52