it-swarm.com.de

Amazon EC2-Berechtigung abgelehnt (publickey)

Dies scheint ein häufiges Problem zu sein, aber mein konkreter Fall scheint ein wenig anders zu sein.

Ich habe eine neue Amazon EC2-Instanz mit den Befehlszeilentools eingerichtet, die Verbindung über SSH hergestellt und einige Konfigurationsarbeiten vorgenommen. 

Anfangs konnte ich jedoch nicht auf die Instanz zugreifen, ich musste die Instanz stoppen und erneut starten, dann konnte ich mich verbinden. Vor dem Neustart erhielt ich nur die Antwort.

Permission denied (publickey).

Das war gestern Abend, heute morgen gehe ich zu derselben Instanz zurück und jetzt bekomme ich alles

Permission denied (publickey).

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

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

72
Trevor

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 [email protected][ec2 instance ip]

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

ssh -i ~/.ssh/[keypair name] [email protected][ec2 instance ip]

bringt mich rein.

Mit ssh-add für das Schlüsselpaar komme ich wieder rein. Ich denke, ssh-add funktioniert nur innerhalb der Shell, in der ich es ausgegeben habe. Als ich das Terminalfenster schloss und ein anderes öffnete, hatte ich dieses Schlüsselpaar nicht mehr zur Verfügung, ohne explizit zu sein.

75
Trevor

Dies geschah für mich, weil ich nicht den richtigen Benutzernamen verwendet habe. Ich konnte mich anmelden, als ich ein AMI verwendete, das in einem Tutorial verwendet wurde, dem ich folgte, aber als ich versuchte, ein anderes AMI (Ubuntu + LAMP von Bitnami) zu verwenden, würde ich den Permission denied (public key).-Fehler erhalten. Ich merkte schließlich, dass ich den gleichen Fehler erhalten würde, wenn ich den Benutzernamen für das Tutorial AMI von ubuntu in ec2-user änderte. 

So sagt ein schneller Google, dass der Benutzername für Bitnami AMIs bitnami ist. Problem gelöst. 

28
RyanM

Ich bin auf ein ähnliches Problem gestoßen und es stellte sich heraus, dass es Berechtigungen für den Basisordner gab. Glücklicherweise hatte ich noch eine andere SSH-Verbindung geöffnet, sodass ich das Protokoll in der ec2-Instanz überprüfen konnte:

$ Sudo weniger/var/log/secure

was enthielt:

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

Dies wurde mit dem folgenden Befehl behoben:

$ chmod og-rwx/home/ec2-user

Ich hoffe, das hilft jemand anderem.

14
Bryan Rink

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

12
Postal

Vielen Dank!

Ich bin @ Trevor's Antwort hier wirklich sehr dankbar. Ich werde diesen kleinen Trick hinzufügen, den ich jetzt benutze, um dieses Problem in der Zukunft zu vermeiden.

Bequemlichkeit

Da Sie für jede Verfügbarkeitszone ein anderes Schlüsselpaar erstellen müssen, ist es sehr umständlich, alle und die Befehle, die sie verwenden, zu verwalten. Mit dem richtigen Setup in ~/.ssh/config ist mein ssh-Befehl so einfach wie folgt:

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

Dies ist der vollständige öffentliche DNS eines Servers in der Verfügbarkeitszone West2 der USA. Der richtige Benutzername und der richtige 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
3
Bruno Bronosky

Wenn die EC2-Instanz Ubuntu AMI 14.04 verwendet. Fügen Sie "ubuntu @" vor der EC2-Instanz-IP hinzu.

ssh -i [key name] [email protected][EC2 instance ip]
2
TYMG

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 er seltsamerweise keinen Fehler anzeigen! Dieser Schlüssel wird einfach nicht verwendet. Es wird den jeweils verwendeten Schlüssel unter .ssh/id_dsa und .ssh/id_ecdsa verwenden, was natürlich die Authentifizierung des öffentlichen Schlüssels beeinträchtigt.

1
Seeker

Ich erhielt auch: Genehmigung verweigert.

Ich benutzte :

ssh -v -i ~/.ssh/pemfile [email protected]

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 etwas falsches Format. Als Nächstes fand ich die Stiftdatei, die von ec2 web heruntergeladen und verschoben wurde. Vorher habe ich eine neue Datei erstellt und den Text aus der heruntergeladenen Pem-Datei in das Verzeichnis ".ssh" geparst. Dann:

ssh-add filename

Welches war erfolgreich.

0
Alex Yao

Ich habe das Problem gelöst, indem ich den Inhalt von ~/.ssh/id_rsa.pub nach ~/.ssh/authorised_keys in der EC2-Instanz kopierte.

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

Dann könnte ich ssh mit diesem Befehl verwenden:

ssh [email protected][ip.address]
0
ChrisJF

Ich suchte den ganzen Tag im Internet nach der Antwort. Meine Ausgabe genau das gleiche. Ich habe mit Erlaubnisproblemen getüftelt, bin hin und her gewechselt, aber keiner hat mein Problem gelöst. Nach dem Test mit einem neuen Schlüssel und dem Starten/Beenden einiger Instanzen fand ich schließlich heraus, dass es sich um denselben Schlüsselnamen in verschiedenen Regionen handelt.

So ist mir "Permission denied (publickey)" passiert:
1. Folgen Sie dem Übungsbuch und wählen Sie als Standardzone die us-east-1 aus
2. Erstellen Sie einen Schlüsselnamen "mykey"
3. Erkunden der AWS-Welt anhand der Beispiele in diesem Buch. 
4. Versuchen Sie eines Tages, die Geschwindigkeiten der Zone Sydney zu testen, und wechseln Sie standardmäßig zur Zone Sydney.
5. Erstellen Sie einen weiteren Schlüssel, der als "mykey" bezeichnet wird, ohne nachzudenken, verwenden Sie ihn jedoch nicht, um ein paar Tage lang über CLI eine Verbindung herzustellen.
6. Versuchen Sie sich mit cli mit AWS zu verbinden.
7. Habe "Erlaubnis verweigert (publickey)".
8. Ich habe viele Stunden damit verbracht, das ssh-Problem zu debuggen, bis ich das Schlüssel-/Zonenproblem bemerkte.

Hoffe, das könnte Neulingen wie mir helfen.

Um dieses Problem zu vermeiden, denke ich, ist es am besten, wenn Sie eine Region angeben, um einen Schlüssel zu benennen.

0
FrankCJ

Die Verbindung zu EC2 von cli ist zumindest zum ersten Mal etwas schwierig. Wenn Sie zu `gehen

Dienste -> Berechnen -> EC2 -> Laufende Instanzen> und wählen Sie .__ aus. Instanz, die Sie ssh -> verbinden möchten

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

 enter image description here

Wenn Sie die Nummer 4 verwenden, ohne [email protected] vorangestellt zu werden, erhalten Sie 

Permission denied (publickey).

Kopieren Sie einfach den unten genannten in "Beispiel:".

0
tadtab

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

0
gaurav arora

Hatte das gleiche Problem, sollten Sie Folgendes tun ... Bevor Sie Windows verwenden, verwenden Sie die Babun-Befehlszeile, die der Linux-Zeile ähnelt. Sobald Sie diese Befehlszeile haben, öffnen Sie sie und Geben Sie ssh-i [key pair path] [username]@[EC2 public IP]..__ ein. Um den Pfad für das Schlüsselpaar zu finden, navigieren Sie zu der Datei, in der Ihr Schlüssel gespeichert ist. Halten Sie die Umschalttaste gedrückt, klicken Sie auf den Pfad, und klicken Sie auf den Pfad zum Kopieren. Wahrscheinlich erhalten Sie "" Markierungen auf den Außenseiten des Pfads, den Sie eingefügt haben, und\backslashes. Löschen Sie die "" -Markierungen und ersetzen Sie die\Backslashes durch normale Schrägstriche /. Das hat in einer Situation wie dieser funktioniert, die ich hatte, viel Glück für Sie.

0
user9357559

In meinem Fall war der Grund dafür, dass ich die Berechtigungen des Stammverzeichnisses mit chmod geändert hatte. Auf der AWS-Website wird ein langer Weg beschrieben, wie Sie die Berechtigungen mit einer anderen temporären Instanz zurücksetzen können. Ich habe jedoch gerade die alte Instanz beendet und eine neue gestartet. Dieses Mal wurden keine Änderungen an den Berechtigungen des Stammverzeichnisses vorgenommen, und alles ist in Ordnung.

0
entropy