Por que “ssh user @ machine1” não exige uma senha, mas “ssh root @ machine2” faz?

Question

Este é um problema de login do DigitalOcean que eu pesquisei depois lendo esta pergunta no site de suporte oficial da DigitalOcean . Eu estava recebendo rejeições com a minha inicial:

ssh root@$IP_DO

A partir do link acima, eu o reduzi para:

ssh -o "IdentitiesOnly yes" -i ~/.ssh/id_rsa root@$IP_DO

Quando fiz o acima, pedi uma senha. Abri meu gerenciador de senhas e, com certeza, bastava definir uma frase-senha nessa chave. Entre e eu estou dentro.

(Se for importante, eu inseri a chave pública quando configuro minha conta do Oceano Digital e a escolhi para a criação de minhas gotas).

Um pouco de ssh-add ~/.ssh/id_rsa entrou na senha uma vez e agora não estou sendo mais solicitado pela DigitalOcean.

Mas, antes mesmo de eu fazer aquele ssh-add acima, eu sempre podia ssh em VMs do Virtualbox em um servidor na minha LAN, sem problemas. Estas são VMs bitnami, a propósito.

Em ambos os casos, DigitalO cean e VM, ~/.ssh/authorized_keys mostram a mesma coisa:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC35MyHYQPWgHgxOffs2oI4jAJCTSldYr1tMb/LMogbTXtQW35mSsWexiwYjPIcdkkOl2Zqrt43696U1oZco90ibkFrbbXrqDGZssbaqfqk7
…

E olhando para / etc / ssh / sshd_config

DigitalOcean:

egrep 'Authentication|PAM|Pass' /etc/ssh/sshd_config | grep -v '^#
RSAAuthentication yes
PubkeyAuthentication yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM yes

uname -rv
4.4.0-93-generic #116-Ubuntu SMP Fri Aug 11 21:17:51 UTC 2017

VM Bitnami

egrep 'Authentication|PAM|Pass' /etc/ssh/sshd_config | grep -v '^#'
RSAAuthentication yes
PubkeyAuthentication yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes

uname -rv
3.16.0-4-amd64 #1 SMP Debian 3.16.43-2+deb8u2 (2017-06-26)

Agora, lendo mais sobre esse tópico, é aconselhável executar ssh-add ~/.ssh/id_rsa . Que pediu a senha da chave.

Agora, tanto o DigitalOcean quanto a VM funcionam sem passphrase, mas estou curioso para saber por que a VM nunca precisou da senha e do DigitalOcean?

    

Answer 1

OK, resolvi e tenho certeza de que sei o que aconteceu.

O SSL testará as chaves públicas remotas armazenadas em chaves authorized_keys vs locais usando um sistema de desafio. Você realmente não sabe, ou controla, a sequência do que ela tenta.

O ~/.ssh/authorized_keys da raiz da machine1 (VM) apontou para uma das minhas chaves que não estava protegida por frase-senha, digamos github . Ele também tinha id_rsa , mas nunca chegou a perguntar sobre isso porque ele entrou antes de id_rsa , usando github .

O ~/.ssh/authorized_keys da raiz da machine2 (Digitalocean) não incluiu uma referência à minha chave de identidade github desprotegida, por isso acabou por chegar a id_rsa . Uma vez que a identidade do id_rsa não foi carregada no ssh-agent e como é protegida por senha, me pediram a frase secreta.

Note que isso contradiz minha afirmação de que chaves autorizadas eram as mesmas. A entrada de id_rsa foi, em ambos os arquivos, mas havia outras chaves públicas na VM Bitnami.

    

Answer 2

Note que a configuração do DigitalOcean que você cita acima tem PasswordAuthentication no , como o Bitnami não faz.

Isso pode, ironicamente, ser a explicação: quando você se conecta ao DigitalOcean, você deve usar uma chave pública e, assim, o sistema local solicita que você descriptografe essa chave.

No Bitnami, você aparentemente está usando autenticação por senha, que de alguma forma está escondida de você. Tente "ssh -vvv ..." para ver o que está acontecendo ou adicione PasswordAuthentication no ao servidor Bitnami para ver o que acontece.