Frage Warum bekomme ich "Permission denied (publickey)", wenn ich versuche, SSH von einem lokalen Ubuntu auf einen Amazon EC2 Server zu übertragen?


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

Ich denke an eine Art von Problemen mit Sicherheitseinstellungen auf dem Amazon EC2, der eingeschränkte IP-Zugriff auf eine Instanz hat oder Zertifikat muss möglicherweise neu generiert werden.

Kennt jemand eine Lösung?


213
2017-07-13 07:38


Ursprung


"Früher hat es früher funktioniert" - vorher Was? - womble♦
Ich habe eine Elastic Beanstalk EC2-Instanz. Seit August 2013 bestand die Lösung darin, auf die Instanz als Benutzer des ec2-Benutzers zuzugreifen, der den Fehler "Permission Denied (publicKey)" beseitigt hatte. Viz: ssh -i ./mike-key-pairoregon.pem ec2-user@ec2-some-address.us-west-2.compute.amazonaws.com. Natürlich muss man all die anderen Sachen nachlesen stackoverflow.com/questions/4742478/... - mikemay
Dieses Problem tritt auf, wenn Sie den falschen Benutzernamen angegeben haben. Die aws-Dokumentation (docs.aws.amazon.com/AWSEC2/latest/UserGuide/...) geben Sie ein Beispiel mit dem Benutzernamen ec2-user [ssh -i /path/my-key-pair.pem ec2-user@ec2-198-51-100-1.compute-1.amazonaws.com], während my ( alt) Ubuntu-Box hat einen Benutzernamen von Ubuntu, so, wenn ich das Beispiel nutzte, erhielt ich diesen Fehler, die Änderung zum richtigen Benutzernamen verrechnet. - david.barkhuizen
@ david.barkhuizen, dein Kommentar hat mir geholfen. Ich hatte ein ähnliches Problem; Es stellte sich heraus, dass es mit dem Benutzernamen zu tun hatte. Vielen Dank. - NaijaProgrammer


Antworten:


Das erste, was in dieser Situation zu tun ist, ist die Verwendung der -v Option zu sshSo können Sie sehen, welche Arten der Authentifizierung versucht werden und was das Ergebnis ist. Hilft das die Situation aufzuklären?

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


140
2017-07-13 07:44



Ich habe den privaten ssh-Schlüssel auf den anderen Rechner kopiert, wie es @Greg vorgeschlagen hat. Es funktioniert jetzt. Vielen Dank! - Vorleak Chy
Zu Ihrer Information: Sie können das Flag -i verwenden, um auf den Pfad der Schlüssel zu zeigen, ohne sie zu installieren - Jorge Vargas
In meinem Fall nutzte ich ein Bitnami .ami und wusste nicht, dass Sie sich einloggen müssen, da der Benutzer bitnami anwendete, wie: ssh -i <keyfile> bitname@<ec2-address>. Leider die -v Option hat mir nicht geholfen, das zu finden, aber es ist immer noch sehr nützlich zu überprüfen! - Matt Connolly
Nun, in meinem Fall habe ich den falschen Benutzernamen benutzt. benutzte "ubuntu" anstelle von "bitnami". wie folgt: ssh -i key.pem bitnami @ hostadresse - Lucas Pottersky
Ein guter Anhaltspunkt ist auch der Remote-Knoten selbst, schauen Sie mal rein /var/log/auth.logManchmal werden Sie die folgenden Nachrichten sehen: Authentication refused: bad ownership or modes for file /var/lib/jenkins/.ssh/authorized_keys oder etwas anderes - Jonas Libbrecht


Da es nicht explizit erwähnt wurde, ist sshd standardmäßig sehr streng auf Berechtigungen für die authorized_keys Dateien. Also, wenn authorized_keys ist schreibbar für jeden anderen als den Benutzer oder kann beschreibbar gemacht werden von jemand anderem als dem Benutzer, wird es sich weigern, sich zu authentifizieren (es sei denn, sshd ist mit konfiguriert StrictModes no)

Was ich mit "Schreibbar machen" meinen kann, ist, dass Benutzer, die berechtigt sind, diese Verzeichnisse zu ändern, Berechtigungen ändern können, so dass sie autorisierte Schlüssel ändern / ersetzen können, wenn eines der übergeordneten Verzeichnisse für andere Benutzer schreibbar ist.

Dies wird nicht angezeigt ssh -vEs wird in den Protokollen angezeigt, die von sshd ausgegeben werden /var/log/secure oder /var/log/auth.log, hängt von Distro und ab syslogd Aufbau).

Von Mann sshd (8):

 ~/.ssh/authorized_keys
         Lists the public keys (RSA/DSA) that can be used for logging in
         as this user.  The format of this file is described above.  The
         content of the file is not highly sensitive, but the recommended
         permissions are read/write for the user, and not accessible by
         others.

         If this file, the ~/.ssh directory, or the user's home directory
         are writable by other users, then the file could be modified or
         replaced by unauthorized users.  In this case, sshd will not
         allow it to be used unless the StrictModes option has been set to
         “no”.

73
2018-01-05 14:38



Das "kann beschreibbar gemacht werden" ist das, was mich hat - wmarbut
FWIW die richtigen Berechtigungen für die Schlüsseldateien sind 600 (siehe Hier) - Matt Lyons
Ja, meine Datei .authorized_keys war für die Gruppe beschreibbar, also weigerte sie sich zu akzeptieren. - Aditya M P
Ich schlug meinen Kopf gegen die Wand! Mein Benutzerordner hatte die falschen Berechtigungen. Vielen Dank! - XJones
Gleiches gilt für den Ordner ~ / .ssh. Sie können folgende Fehlermeldung erhalten: Authentication refused: bad ownership or modes for directory - Yevgeniy M.


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

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


37
2018-04-01 21:51



ssh host -l user ist das gleiche wie ssh user@host, Recht? - Znarkus
@ Znarkus ja, es ist das gleiche. - cregox
Yup, das löste mein Problem und verursachte den "Permission denied (publickey)" Fehler. - Brooks Moses
Das war das Problem für mich. Ich habe erwartet, dass der Benutzer "root" funktioniert, aber ich habe ein Ubuntu EC2-Image verwendet, das den Standardbenutzer "ubuntu" hatte. - Cerin


Ich habe diese Nachricht auf einer neuen Instanz basierend auf dem Ubuntu AMI erhalten. Ich benutzte die Option -i, um die PEM bereitzustellen, aber es zeigte immer noch die "Berechtigung verweigert (publickey)".

Mein Problem war, dass ich nicht den richtigen Benutzer verwendete. Indem ich den ssh mit ubuntu @ ec2 laufen ließ ... funktionierte es wie immer.


19
2017-11-17 16:29



Ja ... Ich habe den Befehl mit ausgeführt sudodeshalb funktionierte es nicht. - thaddeusmt


Etwas, das leichter zu lesen ist als ssh -i (meiner Meinung nach natürlich), ist 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.

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

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


16
2018-02-01 14:07



Ich denke, du meintest es -v - Tim Tisdall
Dies ist das Serverprotokoll. für RHEL / CentOS 7: tail -f /var/log/secure - Gianfranco P.


Überprüfe dein / 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

11
2017-12-10 06:15



Das würde den Server weniger sicher machen. - Znarkus
Das war das Problem, das ich hatte: Ich wollte einen Account für einen anderen Benutzer einrichten, mit nur einem Passwort authentifizieren. Ich wollte mich auch von Orten aus einloggen können, an denen ich meinen privaten Schlüssel nicht hatte. - Daniel
Wie können wir gehen? /etc/ssh/sshd_config - Wenn wir nicht einmal in den Server kommen können? - kyo
Um in den Server selbst zu gelangen, müssen Sie die PEM-Datei verwenden, die sie beim Erstellen der Instanz ausgegeben haben. Die Anweisungen gehen danach. - Sudipta Chatterjee
Dies funktionierte für mich, obwohl der Neustart von sshd den folgenden Befehl erforderte: sudo service sshd reload - pacoverflow


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

Auf diese Weise können Sie die Syntax "-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 von persönlichen SSH-Schlüsseln zu Amazon EC2
http://alestic.com/2010/10/ec2-ssh-keys


6
2017-09-29 21:15



+1 Diese Frage wurde genau aus diesem Grund nachgeschlagen. - John Riselvato
Ich sehe diesen Fehler beim Folgen Ihres Artikels. regions = $ (ec2-describe-regions | cut -f2) Erforderliche Option '-K, --private-key KEY' fehlt (-h zur Verwendung) - KashifAli
@KashifAli Sie sollten die Anmeldeinformationen für das EC2-API-Befehlszeilentool einrichten, damit Sie die Berechtigungsnachweise nicht immer an jeder Befehlszeile übergeben müssen. - Eric Hammond


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


5
2017-08-08 21:00



Vielen Dank! Das war genau mein Problem. Ich habe nicht bemerkt, dass der DNS-Name geändert wurde, wenn Sie eine Instanz neu starten. - Tim Swast
In meinem Fall hat sich die URL von * .compute.amazonaws.com geändert, als ich eine elastische IP-Adresse zugewiesen habe. - Geoffrey Booth


Wenn Sie CentOS 5 verwenden, möchten Sie möglicherweise festlegen StrictModes no im /etc/ssh/sshd_config. Ich teile / home-Verzeichnis mit NIS / NFS, und ich setze alle Berechtigungen korrekt, aber es hat mich immer mit dem Passwort aufgefordert. Nachdem ich mich gesetzt habe StrictModes no, das Problem ist verschwunden!


2
2017-07-10 04:58





Gregs Antwort erklärt, wie man Probleme besser erschießt, aber das eigentliche Problem ist, dass Sie einen ssh-Schlüssel auf einer Seite der Transaktion (dem Client) haben, der Authentifizierung mit öffentlichem Schlüssel anstatt passwortbasierter Authentifizierung versucht. Da Sie auf der EC2-Instanz nicht den entsprechenden öffentlichen Schlüssel haben, funktioniert dies nicht.


1
2017-07-13 08:11



Wie löst man das Problem? - Julien Grenier