Permissão negada (publickey)

Question

Isso me persegue há anos.

Dois servidores IDENTICAL. Conectado a ambos como 'bob'.

Tente fazer o ssh de bob @ server1 para bob @ server2.

Permission denied (publickey).

Nos dois servidores:

rm -r ~/.ssh

no servidor1:

ssh-keygen
ssh bob@server2

Permission denied (publickey).

Ok, então vamos forçá-lo a usar a senha:

mv ~/.ssh ~/oldssh
ssh bob@server2

Permission denied (publickey).

Eu até tentei colocar o conteúdo do id_rsa.pub do server1 em authorized_keys no server2 e server2's no server1.

Nada disso faz sentido!

    

Answer 1

On BOTH servers:

rm -r ~/.ssh

On server1:

ssh-keygen
ssh bob@server2

Como o server2 sabe que deve aceitar a nova chave que você acabou de criar? Não faz. Depois de criar uma chave com ssh-keygen , você deve copiá-la para o arquivo ~ / .ssh / authorized_keys do server2.

I've even tried putting the contents of server1's id_rsa.pub into the authorized_keys on server2

Sim, é basicamente obrigatório.

Ok, so let's force it to use password instead:

mv ~/.ssh ~/oldssh
ssh bob@server2

A mensagem de erro indica quais mecanismos o servidor ofereceu a você. Neste caso, porque somente oferece publickey authentication, os clientes não podem forçá-lo a usar senha ou qualquer outro método.

Para usar a autenticação de senha, primeiro você precisa permitir que ele esteja no /etc/ssh/sshd_config do servidor (usando as opções PasswordAuthentication e ChallengeResponseAuthentication).

Uma vez feito isso, você pode usar ssh -o PreferredAuthentications=password bob@server2 para preferir um mecanismo específico. Dessa forma, você não precisará mover as chaves temporariamente, nem movê-las de volta.

This has dogged me for years.

Parece que está na hora de verificar os registros do sistema do servidor2. O serviço SSH pode informar a você por que está rejeitando ou ignorando suas chaves. Você precisará da opção sshd_config LogLevel DEBUG para obter o máximo de informações.

Todas as mensagens de log sshd vão para o log de segurança, geralmente /var/log/auth.log ou /var/log/security , ou pelo menos journalctl -b se o systemd for usado.

O motivo mais comum é que o servidor "corrompido" está se recusando a ler o seu arquivo authorized_keys devido a permissões de arquivo "muito abertas". Por exemplo, se ~ / .ssh / for mundialmente gravável ou mesmo pertencer a um usuário diferente, isso é considerado um problema de segurança e faz com que o sshd ignore seu arquivo. No Linux, use namei -l ~/.ssh/authorized_keys para verificar isso.

Revise também todo o arquivo sshd_config. Pode ser configurado para procurar por authorized_keys em um local completamente diferente e fora do padrão.