ssh não permite mais autenticação de chave pública

Question

Minha máquina parou recentemente de aceitar a autenticação de chave pública recebida. Eu tenho um desktop Ubuntu 11,04 que eu ssh em uma máquina Windows. Eu uso putty com concurso. Eu sou capaz de se conectar, mas apenas com autenticação de senha interativa, não com a minha chave rsa que eu configurei.

Eu já verifiquei que a chave está listada em ~ / .ssh / authorized_keys. Como faço para corrigir isso e o que verifico?

    

Answer 1

Se a autenticação por chave pública não funcionar: verifique se no lado do servidor, seu diretório pessoal ( ~ ), o diretório ~/.ssh e o arquivo ~/.ssh/authorized_keys são todos graváveis somente por seu dono . Em particular, nenhum deles deve ser gravável pelo grupo (mesmo que o usuário esteja sozinho no grupo). chmod 755 ou chmod 700 está ok, chmod 770 não é.

O que verificar quando algo está errado:

• Execute ssh -vvv para ver muita saída de depuração. Se você postar uma pergunta perguntando por que você não pode se conectar com o ssh, inclua esta saída (você pode querer anonimizar os nomes de host e de usuário).
• Se puder, verifique os logs do servidor em /var/log/auth.log .
• Se a autenticação por chave pública não estiver funcionando, verifique as permissões novamente, especialmente o bit do grupo (veja acima).

Answer 2

Corri para a mesma coisa e finalmente descobri que era porque eu criptografei meu diretório pessoal. O SSH não pode ler o arquivo authorized_keys até que você efetue o login, então basicamente ele obriga você a autenticar a senha primeiro. Veja a seção sobre o diretório inicial criptografado no seguinte link:

link

    

Answer 3

Eu asseguro que você tenha suas configurações em / etc / ssh / sshd_config correto.

Para forçar o uso de PKI apenas e para não permitir senhas, localize a linha

#PasswordAuthentication yes 

no seu arquivo, descomente-o e configure-o para

PasswordAuthenticate no

Eu também leio o equilíbrio das configurações para garantir que elas façam sentido. Em particular, tente garantir que você use chaves RSA, já que o DSA está comprometido.

    

Answer 4

Se você verificar as permissões nos diretórios e houver um "." logo depois deles, então você pode ter o selinux habilitado, que irá mexer com a troca de chaves, e o padrão para identificação manual de senhas.

Você pode desativar o SELinux para solucionar problemas seguindo as instruções aqui: link , ou simplesmente edite o arquivo / etc / selinux / config e mude de" enforcing "para" disabled ".

Espero que isso ajude.

    

Answer 5

Corrigi este problema ao descomentar "PasswordAuthentication yes" em / etc / ssh / sshd_config.

    

Answer 6

Devido a uma necessidade de solucionar problemas de comunicação entre duas máquinas diferentes, eu tinha duas chaves privadas em ~/.ssh no lado do cliente.

Em vez de configurar cada host de servidor com a respectiva chave privada em ~/.ssh/identity como eu deveria ter feito, tive a chave secundária (e neste caso errada) configurada para todos os hosts:

Host *
IdentityFile ~/.ssh/identity_b

Corrigir ~/.ssh/identity resolveu o problema:

Host a
IdentityFile ~/.ssh/identity_a
Host b
IdentityFile ~/.ssh/identity_b

    

Answer 7

Uma possível causa do problema é que você tem chaves DSA, mas agora o SSH (aparentemente) é padronizado para exigir chaves RSA. Eu tenho o problema quando atualizando para 16.04. Você pode ver mais aqui , mas a resposta curta é adicionar o seguinte para ~/.ssh/config :

PubkeyAcceptedKeyTypes ssh-dss

    

Answer 8

Acabei de ter o mesmo problema, mas alterar as permissões com chmod não estava ajudando, pois descobri que não possuía o arquivo ~/.ssh/authorized_keys . Você pode alterar a propriedade do diretório .ssh com:

sudo chown -R "$USER" ~/.ssh

    

Answer 9

De alguma forma, isso funcionou para mim:

root @ kaiser: ~ # vim / etc / ssh / sshd_config

Altere esta linha de sim para não  28 StrictModes não

Tente novamente

sysadmin @ suselinux1: ~ > con sysadmin kaiser Bem-vindo ao Ubuntu 12.04.1 LTS (GNU / Linux 3.2.0-25-i686 genérico)

• Documentação: link

Último acesso: sex 09 de novembro 15:40:11 2012 de 10.1.3.25 sysadmin @ kaiser: ~ $ date vie nov 9 17:53:11 CST 2012 sysadmin @ kaiser: ~ $