Warum erhalte ich die Berechtigung verweigert (Publickey), wenn ich versuche, eine SSH-Verbindung von einem lokalen Ubuntu zu einem Amazon EC2-Server herzustellen?

Lösung 1:

Das erste, was Sie in dieser Situation tun müssen, ist, den -v zu verwenden Option zu ssh , damit Sie sehen können, welche Arten von Authentifizierung versucht werden und was das Ergebnis ist. Hilft das zur Aufklärung der Situation?

In Ihrem Update zu Ihrer Frage erwähnen Sie "auf einem anderen lokalen Ubuntu". Haben Sie den privaten ssh-Schlüssel auf die andere Maschine kopiert?

Lösung 2:

Da es nicht ausdrücklich erwähnt wurde, ist sshd standardmäßig sehr streng in Bezug auf Berechtigungen für authorized_keys Dateien. Wenn also authorized_keys ist beschreibbar für jeden anderen als den Benutzer oder beschreibbar gemacht werden von jemand anderem als dem Benutzer, wird es die Authentifizierung verweigern (es sei denn, sshd ist mit StrictModes no konfiguriert )

Was ich mit "kann beschreibbar gemacht werden" meine, ist, dass, wenn eines der übergeordneten Verzeichnisse für andere Personen als den Benutzer beschreibbar ist, Benutzer, die diese Verzeichnisse ändern dürfen, damit beginnen können, Berechtigungen so zu ändern, dass sie authorisierte_Schlüssel ändern/ersetzen können.

Wenn außerdem /home/username/.ssh Das Verzeichnis gehört nicht dem Benutzer, und daher hat der Benutzer keine Berechtigung zum Lesen des Schlüssels, auf den Sie Probleme stoßen können:

drwxr-xr-x 7 jane jane 4096 Jan 22 02:10 /home/jane
drwx------ 2 root root 4096 Jan 22 03:28 /home/jane/.ssh

Beachten Sie, dass Jane den .ssh nicht besitzt Datei. Beheben Sie dies über

chown -R jane:jane /home/jane/.ssh

Diese Arten von Problemen mit Dateisystemberechtigungen werden bei ssh -v nicht angezeigt , und sie werden nicht einmal in den sshd-Protokollen (!) angezeigt, bis Sie die Protokollebene auf DEBUG setzen.

• Bearbeite /etc/ssh/sshd_config . Sie möchten eine Zeile, die LogLevel DEBUG liest irgendwo drin. Laden Sie den SSH-Server mithilfe des von der Distribution bereitgestellten Mechanismus neu. (service sshd reload auf RHEL/CentOS/Scientific.) Durch ein ordnungsgemäßes Neuladen werden vorhandene Sitzungen nicht gelöscht.
• Versuchen Sie erneut, sich zu authentifizieren.
• Finden Sie heraus, wohin Ihre Authentifizierungsprotokolle gehen, und lesen Sie sie. (IIRC, /var/log/auth.log auf Debian-basierten Distributionen; /var/log/secure auf RHEL/CentOS/Scientific.)

Es ist viel einfacher herauszufinden, was mit der Debug-Ausgabe schief läuft, die Dateisystem-Berechtigungsfehler enthält. Denken Sie daran, die Änderung auf /etc/ssh/sshd_config zurückzusetzen wenn fertig!

Lösung 3:

Ich habe diesen Fehler erhalten, weil ich vergessen habe, -l hinzuzufügen Möglichkeit. Mein lokaler Benutzername war nicht derselbe wie auf dem Remote-System.

Dies beantwortet Ihre Frage nicht, aber ich suchte hier nach einer Antwort auf mein Problem.

Lösung 4:

Ich habe diese Nachricht auf einer neuen Instanz erhalten, die auf dem Ubuntu AMI basiert. Ich habe die Option -i verwendet, um das PEM bereitzustellen, aber es wurde immer noch "Permission denied (publickey)" angezeigt.

Mein Problem war, dass ich nicht den richtigen Benutzer verwendet habe. Durch Ausführen von ssh mit [email protected] funktionierte es wie gewohnt.

Lösung 5:

Etwas, das einfacher zu lesen ist als ssh -v (meiner Meinung nach natürlich) ist tail -f /var/log/auth.log . Das sollte auf dem Server ausgeführt werden, zu dem Sie eine Verbindung herstellen möchten, während Sie versuchen, eine Verbindung herzustellen. Fehler werden im Klartext angezeigt.

Das hat mir geholfen, mein Problem zu lösen:

Benutzer [Benutzername] von xx.yy.com nicht zulässig, da keine der Benutzergruppen in AllowGroups aufgeführt ist