Erlaubnis verweigert (publickey)

405
user4893295

Das hat mich jahrelang verfolgt.

Zwei IDENTICAL Server. Bei beiden als 'Bob' angemeldet.

Versuchen Sie, von bob @ server1 zu bob @ server2 zu ssh.

Erlaubnis verweigert (publickey).

Auf beiden Servern:

rm -r ~/.ssh

Auf Server1:

ssh-keygen ssh bob@server2

Erlaubnis verweigert (publickey).

Ok, also zwingen wir es stattdessen, das Passwort zu verwenden:

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

Erlaubnis verweigert (publickey).

Ich habe sogar versucht, den Inhalt von server1's id_rsa.pub in die authorized_keys auf server2 und server2 in server1 zu setzen.

Nichts davon macht Sinn!

0
Wie haben Sie die Verwendung eines Passworts erzwungen, wenn es in sshd_config möglicherweise ohne PasswordAuthentication konfiguriert wurde? Fanatique vor 6 Jahren 0

1 Antwort auf die Frage

0
grawity

Auf beiden Servern:

rm -r ~/.ssh

Auf Server1:

ssh-keygen ssh bob@server2

Woher weiß server2, dass es den brandneuen Schlüssel akzeptieren soll, den Sie gerade erstellt haben? Es tut nicht Nachdem Sie einen Schlüssel mit ssh-keygen erstellt haben, müssen Sie ihn in die ~ / .ssh / Authorized_keys-Datei von server2 kopieren.

Ich habe sogar versucht, den Inhalt von server1's id_rsa.pub in die Authorized_keys auf Server2 zu setzen

Ja, das ist grundsätzlich erforderlich.

Ok, also zwingen wir es stattdessen, das Passwort zu verwenden:

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

Die Fehlermeldung zeigt an, welche Mechanismen der Server Ihnen angeboten hat. In diesem Fall, da es nur bietet publickeyAuthentifizierung, Kunden können nicht erzwingen, es Kennwort zu verwenden oder eine andere Methode.

Um die Kennwortauthentifizierung zu verwenden, müssen Sie sie zunächst auf dem Server zulassen/etc/ssh/sshd_config (mithilfe der Optionen PasswordAuthentication und ChallengeResponseAuthentication).

Sobald dies erledigt ist, können Sie sogar ssh -o PreferredAuthentications=password bob@server2einen bestimmten Mechanismus bevorzugen. Auf diese Weise müssen Sie die Tasten weder vorübergehend wegbewegen noch zurückschieben.

Das hat mich jahrelang verfolgt.

Klingt, als wäre es an der Zeit, die Systemprotokolle von server2 zu überprüfen. Der SSH-Dienst kann Ihnen sagen, warum er Ihre Schlüssel ablehnt oder ignoriert. Sie benötigen die Option sshd_config LogLevel DEBUG, um die meisten Informationen zu erhalten.

Alle sshd-Protokollnachrichten werden normalerweise /var/log/auth.logoder /var/log/securitymindestens, journalctl -bwenn systemd verwendet wird, im Sicherheitsprotokoll abgelegt .

Der häufigste Grund ist, dass der "defekte" Server das Lesen Ihrer "authorized_keys" -Datei aufgrund von "zu offenen" Dateiberechtigungen verweigert. Wenn beispielsweise ~ / .ssh / weltweit beschreibbar ist oder sogar einem anderen Benutzer gehört, wird dies als Sicherheitsproblem betrachtet und sshd veranlasst, Ihre Datei zu ignorieren. namei -l ~/.ssh/authorized_keysÜberprüfen Sie dies unter Linux .

Überprüfen Sie auch die gesamte Datei sshd_config selbst. Es kann eingerichtet sein, nach Authorized_keys an einem völlig anderen, nicht dem Standard entsprechenden Ort zu suchen.

Verwandte Probleme