it-swarm-pt.tech

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

Eu criei um par de chaves dsa público/privado. Coloquei a chave pública no servidor em

~/.ssh/authorized_keys

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

11
Magnar

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

14
samt

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

chmod 0700 ~/.ssh
chmod 0600 ~/.ssh/authorized_keys
33
Magnar

$ 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

Protocolo $ Sudo grep/etc/ssh/sshd_config

11
setatakahashi

Outra armadilha importante ..

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

Veja esta resposta

0
ApriOri