Dies scheint ein häufiges Problem zu sein, aber mein spezieller Fall scheint etwas anders zu sein.

Ich habe eine neue Amazon EC2-Instanz mit den Befehlszeilentools eingerichtet und über SSH verbunden und einige Konfigurationsarbeiten durchgeführt.

Anfangs konnte ich jedoch nicht auf die Instanz zugreifen, ich musste die Instanz stoppen und neu starten, dann konnte ich eine Verbindung herstellen. Vor dem Neustart habe ich gerade die Antwort erhalten.

Permission denied (publickey).

Das war letzte Nacht, heute morgen gehe ich zurück zu derselben Instanz und jetzt bekomme ich nur noch

Permission denied (publickey).

Ich habe versucht, die Instanz ohne Freude neu zu starten.

Kann mich hier jemand in die richtige Richtung weisen? Der gleiche Befehl, der letzte Nacht funktioniert hat, funktioniert nicht mehr. Ich verbinde mich von meinem Macbook Pro.

Ich werde meine eigene Frage beantworten, falls jemand anderes dasselbe sieht ... Letzte Nacht hatte ich getan:

ssh-add ~/.ssh/[keypair name]

dann verbunden mit:

ssh ec2-user@[ec2 instance ip]

Heute Morgen habe ich das gleiche versucht und konnte keine Verbindung herstellen. Aber tun

ssh -i ~/.ssh/[keypair name] ec2-user@[ec2 instance ip]

bringt mich rein.

Die ssh-adderneute Verwendung des Schlüsselpaars bringt mich dazu. Ich schätze ssh-add, es funktioniert nur innerhalb der Shell, in der ich es ausgegeben habe. Als ich das Terminalfenster schloss und ein anderes öffnete, war dieses Schlüsselpaar nicht mehr verfügbar, ohne explizit zu sein.

Dies geschah für mich, weil ich nicht den richtigen Benutzernamen verwendete. Ich konnte mich anmelden, wenn ich ein AMI verwendete, das in einem Tutorial verwendet wurde, das ich verfolgte, aber wenn ich versuchte, ein anderes AMI (Ubuntu + LAMP von Bitnami) zu verwenden, wurde der Permission denied (public key).Fehler angezeigt . Endlich wurde mir klar, dass ich den gleichen Fehler erhalten würde , wenn ich den Benutzernamen für das Tutorial ami von ubuntuin ändern ec2-userwürde.

Ein kurzer Blick auf Google zeigt also, dass der Benutzername für Bitnami-AMIs lautet bitnami. Problem gelöst.

Ich hatte ein ähnliches Problem und es stellte sich heraus, dass es sich um Berechtigungen für den Home-Ordner handelte. Zum Glück war noch eine andere SSH-Verbindung geöffnet, sodass ich das Protokoll auf der ec2-Instanz überprüfen konnte:

$ sudo less / var / log / secure

welches enthielt:

Dec  9 05:58:20 ... sshd[29816]: Authentication refused: 
    bad ownership or modes for directory /home/ec2-user

Dies wurde durch Ausgabe des Befehls behoben:

$ chmod og-rwx / home / ec2-user

Ich hoffe das hilft jemand anderem.

Bitte beachten Sie, dass sich der DNS-Name nach dem Neustart der Instanz geändert hat. Ich bin mehrmals darauf hereingefallen. Die Schlüsseldatei war noch gültig, aber der "Servername" wurde geändert.

Vielen Dank!

Ich schätze die Antwort von @ Trevor hier sehr. Ich werde diesen kleinen Trick hinzufügen, den ich jetzt verwende, um dieses Problem in Zukunft zu vermeiden.

Bequemlichkeit

Da Sie für jede Verfügbarkeitszone ein anderes Schlüsselpaar erstellen müssen, ist es ziemlich mühsam, sie alle und die Befehle, die sie verwenden, zu verwalten. Mit der richtigen Einrichtung in ~/.ssh/configmeinem ssh-Befehl ist so einfach wie:

ssh ec2-52-10-20-30.us-west-2.compute.amazonaws.com

Dies ist das vollständige öffentliche DNS eines Servers in der US West 2-Verfügbarkeitszone. Der richtige Benutzername und Schlüssel werden aus diesem Grund ausgewählt:

## ~/.ssh/config

Host *.us-west-2.compute.amazonaws.com
    User ec2-user
    IdentityFile ~/.ssh/bruno-bronosky-aws-us-west-2.pem

Wenn die EC2-Instanz Ubuntu ami 14.04 verwendet. Versuchen Sie, 'ubuntu @' vor der IP der EC2-Instanz hinzuzufügen.

ssh -i [key name] ubuntu@[EC2 instance ip]

Stellen Sie sicher, dass der Pfad zu Ihrem privaten Schlüssel korrekt ist.

Wenn Ihr SSH-Client den privaten Schlüssel, den Sie bereitstellen möchten, nicht finden kann, wird Ihnen seltsamerweise kein Fehler angezeigt! Dieser Schlüssel wird einfach nicht verwendet. Es wird jeder Schlüssel verwendet, den Sie unter .ssh / id_dsa und .ssh / id_ecdsa haben, was natürlich die Authentifizierung mit öffentlichem Schlüssel in Ohnmacht fallen lässt.

Ich habe dieses Problem gelöst, indem ich den Inhalt von ~ / .ssh / id_rsa.pub nach ~ / .ssh / authorized_keys auf der EC2-Instanz kopiert habe.

Dies ist in der Dokumentation angegeben: http://docs.aws.amazon.com/opsworks/latest/userguide/security-ssh-access.html

Dann könnte ich mit diesem Befehl ssh:

ssh ec2-user@[ip.address]

Ich erhielt auch: Erlaubnis verweigert.

Ich benutzte :

ssh -v -i ~/.ssh/pemfile ec2-user@xx.xx.xx.xx

und die Antwort war:

debug1: No more authentication methods to try.

Geben Sie den Befehl ein:

ssh-add -l

Aber die Antwort war leer

Ich denke, die Stiftdatei hat ein falsches Format. Als nächstes fand ich die von ec2 web heruntergeladene Stiftdatei und verschob sie. Vorher habe ich eine neue Datei erstellt und den Text aus der heruntergeladenen PEM-Datei in das Verzeichnis ".ssh" analysiert. Dann:

ssh-add filename

Welches war erfolgreich.

Ich habe den ganzen Tag im Internet nach der Antwort gesucht. Mein Problem genau das gleiche. Ich spielte mit Erlaubnisproblemen, wechselte hin und her, aber keiner löste mein Problem. Nach dem Test mit einem neuen Schlüssel und dem Starten / Beenden einiger Instanzen stellte ich schließlich fest, dass dies mit demselben Schlüsselnamen in verschiedenen Regionen zu tun hat.

So ist mir "Berechtigung verweigert (öffentlicher Schlüssel)" passiert:
1. Befolgen Sie das Übungsbuch, wählen Sie "us-east-1" als Standardzone aus.
2. Erstellen Sie einen Schlüsselnamen "mykey".
3. Erkunden Sie die AWS-Welt anhand der folgenden Beispiele Buch.
4. Versuchen Sie eines Tages, die Geschwindigkeit der Sydney-Zone zu testen, und wechseln Sie standardmäßig zur Sydney-Zone.
5. Erstellen Sie einen weiteren Schlüssel mit dem Namen "mykey", ohne darüber nachzudenken, aber verwenden Sie ihn einige Tage lang nicht, um eine Verbindung über cli herzustellen.
6. Versuchen Sie, mit cli eine Verbindung zu AWS herzustellen.
7. Erhielt "Berechtigung verweigert (öffentlicher Schlüssel)".
8. Ich habe viele Stunden damit verbracht, das SSH-Problem zu debuggen, bis ich das Schlüssel- / Zonenproblem bemerke.

Hoffe das könnte Neulingen wie mir helfen.

Um dieses Problem zu vermeiden, ist es meiner Meinung nach die beste Vorgehensweise, einen Schlüssel zu benennen, eine Region darin anzuhängen.

Ich habe die Berechtigungen auf 600 geändert, obwohl die Berechtigungen für die PEM-Datei bereits 644 waren. Und das hat funktioniert: Ich hoffe, es hilft

Hatte das gleiche Problem, hier ist was du tun solltest. Wenn Sie Windows haben, verwenden Sie zunächst die Babun-Befehlszeile, die der Linux-Befehlszeile ähnelt. Sobald Sie diese Befehlszeile haben, öffnen Sie sie und geben Sie ein. ssh-i [key pair path] [username]@[EC2 public IP]. Um den Pfad für das Schlüsselpaar zu finden, gehen Sie zu der Datei, in der Ihr Schlüssel gespeichert ist, halten Sie die Umschalttaste gedrückt, klicken Sie mit der rechten Maustaste und klicken Sie auf Pfad kopieren, und fügen Sie ihn dort ein, wo der Pfad eingeht der obige Befehl. Sie erhalten wahrscheinlich "" Markierungen an den Außenseiten des eingefügten Pfads und \ Backslashes. Löschen Sie die Markierungen "" und ersetzen Sie die \ Backslashes durch reguläre Schrägstriche /. Dies funktionierte in einer Situation wie dieser, die ich hatte, viel Glück für Sie.

Die Verbindung von ECI zu EC2 ist zumindest zum ersten Mal etwas schwierig. Wenn du zu `gehst

Dienste -> Rechnen -> EC2 -> Instanzen ausführen> und wählen Sie die Instanz aus, die Sie ssh -> verbinden möchten

`Dann sehen Sie das Dialogfeld, in dem beschrieben wird, wie Sie eine Verbindung herstellen. Ein Teil davon ist unten gezeigt.

Wenn Sie Nummer 4 verwenden, ohne sie vorher ec2-user@anzugeben, erhalten Sie

Permission denied (publickey).

Kopieren Sie einfach die unten im `Beispiel :.

In meinem Fall war der Grund dafür, dass ich die Berechtigungen des Stammverzeichnisordners mit chmod geändert hatte. Auf der AWS-Website wird ein langer Weg beschrieben, um die Berechtigungen durch eine andere temporäre Instanz zurückzusetzen. Ich habe jedoch gerade die alte Instanz beendet und eine andere gestartet und diesmal keine Änderungen an den Berechtigungen des Stammverzeichnisses vorgenommen, und alles ist in Ordnung.

Ich hatte das gleiche Problem. Was es für mich gelöst hat, war, Anführungszeichen um mein Verzeichnis und meine PEM-Datei zu setzen. Das musste ich in der Vergangenheit nie tun. Ich bin mir nicht sicher, warum ich diesmal dazu gezwungen wurde. Ich habe meine PEM-Dateien für andere Projekte im selben Verzeichnis.

Dies ist ein häufiges Problem, wenn es um ssh geht.

Während man sich auf einem Mac- oder Linux-basierten System befindet, kann man dem folgenden Pfad folgen:

1. Gehen Sie zum Speicherort der Pem-Datei
2. Dort Terminal öffnen
3. Führen Sie den folgenden Befehl aus: chmod 400
4. Verwenden Sie dann den Befehl, um den Server mit ssh zu verbinden, und es wird gut funktionieren.

Es gibt jedoch ein Problem mit Windows-Systemen, da dies chmodkein Befehl in cmd oder Powershell ist.

Um ssh unter Windows zu verwenden, müssen wir den folgenden Prozess ausführen: ( Hinweis: Dieser Prozess funktioniert nur unter PowerShell und nicht unter CMD. Ich würde die Verwendung von PowerShell im Administratormodell empfehlen. )

Es folgen die Schritte:

1. Öffnen Sie Powershell im Administratormodus.
2. Gehen Sie zu dem Ordner, in dem die PEM-Datei gespeichert ist.
3. RUN Folgende Befehle nacheinander ausführen:

• Hier heißt die Pem-Datei key.pem

  1. icacls.exe key.pem /reset // um alle Privilegien zu widerrufen

  2. icacls.exe key.pem /grant:r "$($env:username):(r)" // um alle vorherigen Berechtigungen zu gewähren

  3. icacls.exe key.pem /inheritance:r // um alle Vererbungen zu entfernen

Hoffe das wird deinen Tag retten.

Dies ist eine Referenz aus dem folgenden Link: CHMOD 400 in WINDOWS