Berechtigung verweigert (öffentlicher Schlüssel). SSH vom lokalen Ubuntu zum Amazon EC2-Server

Question

Ich habe eine Instanz einer Anwendung, die in der Cloud auf einer Amazon EC2-Instanz läuft, und ich muss mich von meinem lokalen Ubuntu aus damit verbinden. Das funktioniert auf einem lokalen Ubuntu und auch auf einem Laptop einwandfrei. Ich habe diese Meldung erhalten, Permission denied (publickey).als ich versuchte, von einemanderslokales Ubuntu.

Ich vermute, dass es möglicherweise Probleme mit den Sicherheitseinstellungen von Amazon EC2 gibt, da der IP-Zugriff auf eine Instanz beschränkt ist. Oder vielleicht muss ein Zertifikat neu generiert werden.

Kennt jemand eine Lösung für den Fehler „Zugriff verweigert“?

Answer 1

-vIn dieser Situation sollten Sie zunächst die Option verwenden ssh, um zu sehen, welche Arten der Authentifizierung versucht werden und was das Ergebnis ist. Hilft das, die Situation zu klären?

In Ihrer Aktualisierung zu Ihrer Frage erwähnen Sie „auf einem anderen lokalen Ubuntu“. Haben Sie den privaten SSH-Schlüssel auf die andere Maschine kopiert?

Answer 2

Da es nicht explizit erwähnt wurde, ist sshd standardmäßig sehr streng bei den Berechtigungen für die authorized_keysDateien. Wenn authorized_keysalsoschreibbarfür andere als den Benutzer oderkann beschreibbar gemacht werdenvon jemand anderem als dem Benutzer, wird die Authentifizierung verweigert (es sei denn, sshd ist mit konfiguriert StrictModes no)

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

/home/username/.sshDarüber hinaus können Probleme auftreten , wenn das Verzeichnis nicht dem Benutzer gehört und der Benutzer daher keine Berechtigung zum Lesen des Schlüssels hat:

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 die Datei nicht Jane gehört .ssh. Beheben Sie dies über

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

Diese Art von Problemen mit den Dateisystemberechtigungen werden mit nicht angezeigt ssh -vund sie werden nicht einmal in den SSHD-Protokollen (!) angezeigt, bis Sie die Protokollebene auf DEBUG setzen.

• Bearbeiten /etc/ssh/sshd_config. Sie möchten eine Zeile, die LogLevel DEBUGdort irgendwo eingelesen wird. Laden Sie den SSH-Server mit dem von der Distribution bereitgestellten Mechanismus neu. ( service sshd reloadunter RHEL/CentOS/Scientific.) Ein ordnungsgemäßes Neuladen löscht keine vorhandenen Sitzungen.
• Versuchen Sie die Authentifizierung erneut.
• Finden Sie heraus, wo die Protokolle Ihrer Authentifizierungseinrichtung gespeichert sind, und lesen Sie sie. (Wenn ich mich richtig erinnere, /var/log/auth.logauf Debian-basierten Distributionen; /var/log/secureauf RHEL/CentOS/Scientific.)

Es ist viel einfacher herauszufinden, was mit der Debug-Ausgabe schief läuft, die Fehler bei den Dateisystemberechtigungen enthält. Denken Sie daran, die Änderung rückgängig zu machen, /etc/ssh/sshd_configwenn Sie fertig sind!

Answer 3

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

Dies beantwortet Ihre Frage nicht, aber ich bin hierher gekommen, um nach einer Antwort auf mein Problem zu suchen.

Answer 4

Etwas, das leichter 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, mit dem Sie eine Verbindung herstellen möchten, während Sie versuchen, eine Verbindung herzustellen. Es zeigt Fehler im Klartext an.

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

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