Warum erhalte ich die Meldung "Permission denied (publickey)", wenn ich versuche, SSH von lokalem Ubuntu auf einen Amazon EC2-Server zu übertragen?

Ich habe eine Instanz einer Anwendung, die in der Cloud auf einer Amazon EC2-Instanz ausgeführt wird, und ich muss eine Verbindung von meinem lokalen Ubuntu herstellen. Es funktioniert gut auf einem lokalen Ubuntu und auch Laptop. Ich habe die Meldung "Permission denied (publickey)" erhalten, wenn ich versuche, auf einem anderen lokalen Ubuntu auf SSH zu EC2 zuzugreifen. Es ist so seltsam für mich.

Ich denke, eine Art von Problemen mit den Sicherheitseinstellungen auf dem Amazon EC2, der über eingeschränkten IP-Zugriff auf eine Instanz oder ein Zertifikat verfügt, muss möglicherweise neu generiert werden.

Kennt jemand eine Lösung?

In diesem Fall müssen Sie zunächst die -vOption to verwenden ssh, damit Sie sehen können, welche Arten der Authentifizierung versucht werden und was das Ergebnis ist. Hilft das, die Situation aufzuklären?

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?

Da dies nicht explizit erwähnt wurde, ist sshd bei den Berechtigungen für die authorized_keysDateien standardmäßig sehr streng . Also, wenn authorized_keysist beschreibbar für jemanden anderen als den Benutzer oder kann beschreibbar gemacht werden , indem jemand anderes als der Benutzer, wird es ablehnen , zu authentifizieren (es sei denn , sshd mit konfiguriert ist StrictModes no)

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

Wenn das /home/username/.sshVerzeichnis nicht im Besitz des Benutzers ist und der Benutzer daher keine Berechtigung zum Lesen des Schlüssels hat, können Probleme auftreten:

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 die .sshDatei nicht besitzt. Beheben Sie dies über

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

Diese Art von Dateisystem-Berechtigungsproblemen wird nicht ssh -vangezeigt, und sie werden nicht einmal in den sshd-Protokollen (!) Angezeigt, bis Sie die Protokollstufe auf DEBUG setzen.

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

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

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

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

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

Mein Problem war, dass ich nicht den richtigen Benutzer verwendete. Durch Ausführen von ssh mit ubuntu @ ec2 ... funktionierte es wie gewohnt.

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

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

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

Überprüfen Sie Ihre / etc / ssh / sshd_config- Datei. Dort finden Sie die Zeile, die sagt

PasswordAuthentication no

Diese Zeile muss geändert werden, um Ja statt Nein zu sagen. Starten Sie den sshd-Server anschließend neu.

sudo /etc/init.d/ssh restart

Vielleicht nicht relevant für das aktuelle Poster, könnte aber anderen helfen, die dies finden, wenn sie nach Antworten auf ähnliche Situationen suchen. Anstatt Amazon das SSH-Schlüsselpaar generieren zu lassen, empfehle ich, Ihren eigenen öffentlichen Standard-SSH-Schlüssel auf Amazon hochzuladen und diesen beim Ausführen einer EC2-Instanz anzugeben.

Auf diese Weise können Sie die Syntax vom Typ "-i" in ssh löschen, rsync mit Standardoptionen verwenden und in allen EC2-Regionen denselben ssh-Schlüssel verwenden.

Ich habe hier einen Artikel über diesen Prozess geschrieben:

Hochladen persönlicher SSH-Schlüssel auf Amazon EC2
http://alestic.com/2010/10/ec2-ssh-keys

Seltsamerweise stellte sich heraus, dass der Server neu gestartet und ein neuer DNS-Name vergeben wurde. Ich habe den alten DNS-Namen verwendet. Ich weiß, das klingt dumm, aber ich habe eine Weile gebraucht, um das herauszufinden.

Wenn Sie versuchen, eine Verbindung zu einem CyanogenMod-Telefon herzustellen, auf dem Dropbear ausgeführt wird, sollten Sie die folgenden Zeilen ausführen, um sicherzustellen, dass alle Berechtigungen korrekt sind:

chmod 600 /data/dropbear/.ssh/authorized_keys

oder

chmod 700 /data/dropbear/.ssh/authorized_keys # In case of MacOS X 10.6-10.8

und

chmod 755 /data/dropbear/ /data/dropbear/.ssh

Das hat es für mich behoben, sonst kann sich nichts verbinden.

Wenn Sie mit CentOS 5, können Sie festlegen möchten StrictModes noin /etc/ssh/sshd_config. Ich teile / home-Verzeichnis mit NIS / NFS und habe alle Berechtigungen korrekt festgelegt, wurde jedoch immer zur Eingabe des Kennworts aufgefordert. Nachdem ich eingestellt hatte StrictModes no, verschwand das Problem!

Gregs Antwort erklärt, wie Sie Probleme besser lösen können. Das eigentliche Problem ist jedoch, dass auf einer Seite der Transaktion (dem Client) ein SSH-Schlüssel festgelegt ist, der eine Authentifizierung mit öffentlichem Schlüssel anstelle einer passwortbasierten Authentifizierung versucht. Da Sie auf der EC2-Instanz nicht über den entsprechenden öffentlichen Schlüssel verfügen, funktioniert dies nicht.

Ich hatte das gleiche Problem und nachdem ich Tonnen von Lösungen ausprobiert hatte, die nicht funktionierten, öffnete ich den SSH-Port an der Firewall meines Routers (die Firewall-Systemsteuerung meines Routers ist durcheinander, daher ist es schwer zu sagen, was los ist). Wie auch immer, das hat es behoben :)

Super verdammt ärgerlich, dass der Fehler, den Sie bekommen, "Permission Denied" ist, was bedeutet, dass irgendeine Verbindung hergestellt wurde, grr.

Ich hatte das gleiche Problem, obwohl ich angeblich alle Schritte einschließlich folgte

$ ec2-authorize default -p 22

Ich hatte jedoch meine Instanz in der Region us-west-1 gestartet. Daher sollte der obige Befehl dies auch angeben.

$ ec2-authorize default -p 22 --region us-west-1

Nach diesem Befehl konnte ich in die Instanz ssh. Ich habe eine Weile gebraucht, bevor ich das Problem erkannt habe und hoffe, dass dieser Beitrag anderen hilft.

Dies ist ein seltener Fall, aber wenn Sie selinux aktiviert haben und nfs für das Verzeichnis mit den authorized_keys verwenden (z. B. freigegebene Home-Verzeichnisse), müssen Sie entweder selinux deaktivieren (aus Sicherheitsgründen nicht empfohlen, aber Sie können es vorübergehend deaktivieren) um zu sehen, ob dies das Problem verursacht) oder erlauben Sie selinux, nfs home-Verzeichnisse zu verwenden. Ich weiß nicht genau, aber das hat bei mir funktioniert setsebool -P use_nfs_home_dirs 1

Ich habe gerade das gleiche Problem festgestellt, nachdem ich versehentlich Gruppenschreibberechtigungen zum Basisverzeichnis des Benutzers hinzugefügt habe.

Ich entdeckte, dass dies die Ursache war, indem ich tail -f /var/log/secureauf der Maschine lief und den Fehler sah Authentication refused: bad ownership or modes for directory /home/<username>.