☰

Warum erfordert „ssh user@machine1“ keine Passphrase, „ssh root@machine2“ jedoch schon?

tag-icon • tag-icon ssh security
Warum erfordert „ssh user@machine1“ keine Passphrase, „ssh root@machine2“ jedoch schon?

Dies ist ein von mir untersuchtes Login-Problem bei DigitalOceannachdem ich diese Frage auf der offiziellen DigitalOcean-Support-Site gelesen habe. Ich erhielt Absagen für meinen Anfangsbuchstaben:

ssh root@$IP_DO

Anhand des obigen Links habe ich die Auswahl zunächst auf Folgendes eingegrenzt:

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

Als ich das oben genannte ausführte, wurde ich nach einer Passphrase gefragt. Ich öffnete meinen Passwortmanager und hatte tatsächlich eine Passphrase für diesen Schlüssel festgelegt. Geben Sie sie ein und ich bin drin.

(Falls es wichtig ist: Ich habe den öffentlichen Schlüssel eingegeben, als ich mein Digital Ocean-Konto eingerichtet habe, und ihn einfach für die Erstellung meines Droplets ausgewählt.)

Ein bisschen ssh-add ~/.ssh/id_rsa, einmal die Passphrase eingegeben und jetzt werde ich von DigitalOcean nicht mehr nach einem Passwort gefragt.

Aber selbst bevor ich das oben genannte ssh-add ausgeführt habe, konnte ich mich immer problemlos per SSH mit Virtualbox-VMs auf einem Server in meinem LAN verbinden. Dies sind übrigens Bitnami-VMs.

In beiden Fällen zeigen DigitalOcean und VM ~/.ssh/authorized_keysdasselbe an:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC35MyHYQPWgHgxOffs2oI4jAJCTSldYr1tMb/LMogbTXtQW35mSsWexiwYjPIcdkkOl2Zqrt43696U1oZco90ibkFrbbXrqDGZssbaqfqk7
…

Und wenn man/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

Bitnami VM

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)

Beim weiteren Lesen dieses Threads wurde empfohlen, auszuführen ssh-add ~/.ssh/id_rsa. Dabei wurde nach der Passphrase des Schlüssels gefragt.

Nun funktionieren sowohl DigitalOcean als auch die VM ohne Passphrase, aber ich frage mich, warum die VM die Passphrase nie benötigte und DigitalOcean schon?

Antwort1

OK, ich habe es also gelöst und bin ziemlich sicher, dass ich weiß, was passiert ist.

SSL versucht, entfernte öffentliche Schlüssel zu verwenden, die inautorisierte Schlüsselvs. lokale Schlüssel mit einem Challenge-System. Sie kennen die Abfolge der Versuche nicht wirklich und haben auch keine Kontrolle darüber.

machine1 (VM) root's ~/.ssh/authorized_keyszeigte auf einen meiner Schlüssel, der nicht durch eine Passphrase geschützt war, sagen wirgithubEs hatte auchid_rsa, aber ich habe nie danach gefragt, weil es vorher reinkamid_rsa, mitgithub.

machine2 (Digitalocean) root's ~/.ssh/authorized_keysenthielt keinen Verweis auf meine ungeschütztegithubIdentitätsschlüssel, so dass es schließlich zuid_rsa. Seitdemid_rsaDie Identität wurde nicht in den SSH-Agenten geladen und da sie durch eine Passphrase geschützt ist, wurde ich nach der Passphrase gefragt.

Beachten Sie, dass dies meiner Aussage widerspricht, dass die autorisierten Schlüssel dieselben waren. Der Eintrag von id_rsa war in beiden Dateien vorhanden, aber es gab andere öffentliche Schlüssel auf der Bitnami-VM.

verwandte Informationen