it-swarm.com.de

WARNUNG: UNGESCHÜTZTE PRIVATE KEY-DATEI! beim Versuch, eine SSH in die Amazon EC2-Instanz aufzunehmen

Ich arbeite daran, Panda für eine Amazon EC2-Instanz einzurichten ... Ich habe gestern Abend mein Konto und meine Tools eingerichtet und hatte kein Problem mit SSH, um mit meiner eigenen Instanz zu interagieren, aber jetzt habe ich keine Erlaubnis in die EC2-Instanz von Panda . Erste Schritte mit Panda

Ich erhalte folgende Fehlermeldung:

@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @

Permissions 0644 for '~/.ec2/id_rsa-gsg-keypair' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.

Ich habe mein Schlüsselpaar auf 600 geändert, um letzte Nacht in meine persönliche Instanz zu gelangen, und habe ausführlich experimentiert, die Berechtigungen auf 0 gesetzt und sogar neue Schlüsselketten erzeugt, aber nichts scheint zu funktionieren.

Jede Hilfe wäre eine große Hilfe!


Hm, es scheint, als könnte das Skript ec2-run-instances meine Schlüsseldateien nicht finden, wenn für das Verzeichnis keine Berechtigungen auf 777 festgelegt sind. Ich bin neu bei SSH, daher könnte ich etwas übersehen.

146
btw

Ich habe mein Schlüsselpaar auf 600 geändert, um letzte Nacht in meine persönliche Instanz zu gelangen.

Und so soll es sein. 

Aus der EC2-Dokumentation haben wir "Wenn Sie OpenSSH (oder einen vernünftig paranoiden SSH-Client) verwenden, müssen Sie wahrscheinlich die Berechtigungen dieser Datei so einstellen, dass sie nur von Ihnen gelesen werden kann." Die Panda-Dokumentation, die Sie mit Links zu Amazon-Dokumentation verlinken, vermittelt nicht wirklich, wie wichtig das alles ist.

Die Idee ist, dass die Schlüsselpaardateien wie Passwörter sind und geschützt werden müssen. Der von Ihnen verwendete ssh-Client erfordert also, dass diese Dateien gesichert sind und nur Ihr Konto sie lesen kann.

Die Einstellung des Verzeichnisses auf 700 sollte eigentlich ausreichend sein, aber 777 wird nicht schaden, solange die Dateien 600 sind.

Alle Probleme, die Sie haben, sind Client-seitig. Geben Sie daher bei weiteren Fragen unbedingt lokale Betriebssysteminformationen an! 

173
Stu Thompson

Stellen Sie sicher, dass das Verzeichnis mit den privaten Schlüsseldateien auf 700 eingestellt ist.

chmod 700 ~/.ec2
45
Mark Biek

Um dies zu beheben, 1) müssen Sie die Berechtigungen auf den Standard zurücksetzen:

Sudo chmod 600 ~/.ssh/id_rsa Sudo chmod 600 ~/.ssh/id_rsa.pub

Wenn Sie eine weitere Fehlermeldung erhalten: Möchten Sie die Verbindung wirklich fortsetzen (Ja/Nein)? yes Fehler beim Hinzufügen des Hosts zur Liste der bekannten Hosts (/home/geek/.ssh/known_hosts).

2) Dies bedeutet, dass die Berechtigungen für diese Datei ebenfalls falsch festgelegt sind und mit diesem angepasst werden können:

Sudo chmod 644 ~/.ssh/known_hosts

3) Schließlich müssen Sie möglicherweise auch die Verzeichnisberechtigungen anpassen:

Sudo chmod 755 ~/.ssh

Dies sollte Sie wieder zum Laufen bringen.

20
Alena

Die private Schlüsseldatei sollte geschützt sein. In meinem Fall habe ich die public_key-Authentifizierung seit langem verwendet und habe die Erlaubnis auf 600 (rw- --- ---) für den privaten Schlüssel und 644 (rw-r-- r--) und für festgelegt Im .ssh-Ordner im Basisordner haben Sie die Berechtigung 700 (rwx --- ---). Um dies einzustellen, gehen Sie in den Home-Ordner des Benutzers und führen Sie den folgenden Befehl aus


Legen Sie die Berechtigung 700 für den Ordner .ssh fest

chmod 700 .ssh


Legen Sie die Berechtigung 600 für die private Schlüsseldatei fest

chmod 600 .ssh/id_rsa


Legen Sie 644 Berechtigung für die Datei mit dem öffentlichen Schlüssel fest

chmod 644 .ssh/id_rsa.pub
13

Ich habe auch das gleiche Problem, aber ich behebe es, indem ich meine Schlüsseldateiberechtigung auf 600 ändere.

Sudo chmod 600 /path/to/my/key.pem

Link: http://stackabuse.com/how-to-fix-warning-unprotected-private-key-file-on-mac-and-linux/

3
ANAND SONI

Behalten Sie Ihren privaten Schlüssel, öffentlichen Schlüssel, known_hosts im gleichen Verzeichnis und versuchen Sie, sich wie folgt anzumelden:

ssh -I (kleines i) "hi.pem" ec2-user @ ec2 - -- -. us-west-2.compute.amazonaws.com

  • Dasselbe Verzeichnis im Sinne von Cd/Users/prince/Desktop Geben Sie jetzt ls Befehl Sie sollten **. Pem **. Ppk known_hosts sehen

Hinweis: Sie müssen versuchen, sich aus demselben Verzeichnis anzumelden. Andernfalls erhalten Sie eine Fehlermeldung, der die Berechtigung verweigert wurde, da die PPM-Datei nicht aus Ihrem aktuellen Verzeichnis übernommen werden kann.

1
Prince Charu

Nur eine Anmerkung für alle, die darauf stoßen:

Wenn Sie versuchen, eine SSH-Verbindung mit einem Schlüssel herzustellen, der für Sie freigegeben wurde, zum Beispiel:

ssh -i /path/to/keyfile.pem [email protected]

Wobei keyfile.pem der für Sie freigegebene private/öffentliche Schlüssel ist und Sie ihn zum Herstellen einer Verbindung verwenden, Stellen Sie sicher, dass Sie ihn in ~/.ssh/ und chmod 777 speichern.

Der Versuch, die Datei zu verwenden, wenn sie an einer anderen Stelle auf meinem Computer gespeichert wurde, führte zu einem OP-Fehler. Ich bin mir nicht sicher, ob es in direktem Zusammenhang steht.

0
Kubie

Ändern Sie die Dateiberechtigung mit dem Befehl chmod

Sudo chmod 700 keyfile.pem
0
Greenkraftz

Ich denke über etwas anderes nach. Wenn Sie versuchen, sich mit einem anderen Benutzernamen anzumelden, der nicht existiert, wird dies die Nachricht sein, die Sie erhalten.

Ich gehe also davon aus, dass Sie versuchen, mit ec2-user ssh zu versuchen, aber ich erinnere mich, dass vor kurzem die meisten Centos-AMIs Centos-Benutzer anstelle von ec2-user verwenden

wenn Sie also ssh -i file.pem [email protected]_IP sind, sagen Sie mir bitte, dass Sie mit dem richtigen Benutzernamen auf ssh zugreifen. Andernfalls kann dies ein starker Grund dafür sein, dass Sie eine solche Fehlermeldung sehen, auch wenn Sie über die entsprechenden Berechtigungen für ~/.ssh/id_rsa oder file.pem verfügen

0
Abdel Hegazi

Versuchen Sie es unter Windows mit git bash und verwenden Sie dort Ihre Linux-Befehle. Einfacher Ansatz

chmod 400 *****.pem

ssh -i "******.pem" [email protected]
0
Dheeraj