Berechtigung verweigert (öffentlicher Schlüssel), wenn SSH-Zugriff auf Amazon EC2-Instanz [geschlossen]

Ich möchte meine Amazon ec2-Instanz verwenden, habe jedoch den folgenden Fehler festgestellt:

Permission denied (publickey).

Ich habe mein Schlüsselpaar erstellt und die PEM- Datei heruntergeladen .

Gegeben:

chmod  600 pem file.

Dann dieser Befehl

ssh -i /home/kashif/serverkey.pem  ubuntu@ec2-54-227-242-179.compute-1.amazonaws.com

Aber haben Sie diesen Fehler:

Permission denied (publickey)

Auch wie kann ich eine Verbindung mit FileZilla Upload / Download - Dateien?

Diese Fehlermeldung bedeutet, dass Sie sich nicht authentifizieren konnten.

Dies sind häufige Gründe, die dazu führen können:

1. Es wird versucht, eine Verbindung mit dem falschen Schlüssel herzustellen. Sind Sie sicher, dass diese Instanz dieses Schlüsselpaar verwendet?
2. Es wurde versucht, eine Verbindung mit dem falschen Benutzernamen herzustellen. ubuntuist der Benutzername für die Distribution Ubuntu basiert AWS, aber auf einigen anderen ist es ec2-user(oder adminauf einigen Debians nach Bogdan Kulbida Antwort) (auch sein kann root, fedorasiehe unten)
3. Der Versuch, den falschen Host zu verbinden. Ist das der richtige Host, bei dem Sie sich anmelden möchten?

Beachten Sie, dass dies 1.auch passiert, wenn Sie die /home/<username>/.ssh/authorized_keysDatei auf Ihrer EC2-Instanz durcheinander gebracht haben .

In 2.der AMI-Image-Beschreibung fehlen häufig Informationen darüber, welchen Benutzernamen Sie verwenden sollten. Einige finden Sie jedoch in der AWS EC2-Dokumentation, Aufzählungspunkt 4.: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html

Verwenden Sie den Befehl ssh, um eine Verbindung zur Instanz herzustellen. Sie geben die private Schlüsseldatei (.pem) und den Benutzernamen @ public_dns_name an. Für Amazon Linux lautet der Benutzername ec2-user. Bei RHEL5 lautet der Benutzername entweder root oder ec2-user . Für Ubuntu lautet der Benutzername Ubuntu . Für Fedora lautet der Benutzername entweder fedora oder ec2-user . Für SUSE Linux lautet der Benutzername root . Wenn ec2-user und root nicht funktionieren, wenden Sie sich an Ihren AMI-Anbieter.

Beachten Sie schließlich , dass es viele andere Gründe gibt, warum die Authentifizierung fehlschlagen würde. SSH ist normalerweise ziemlich explizit darüber, was schief gelaufen ist, wenn Sie die -vOption zu Ihrem SSH-Befehl hinzufügen und die Ausgabe lesen möchten, wie in vielen anderen Antworten auf diese Frage erläutert.

In diesem Fall entsteht das Problem durch ein verlorenes Schlüsselpaar. Darüber:

• Es gibt keine Möglichkeit, das Schlüsselpaar für eine Instanz zu ändern . Sie müssen eine neue Instanz erstellen, die ein neues Schlüsselpaar verwendet.
• Sie können das Problem umgehen, wenn Ihre Instanz von einer Anwendung auf Elastic Beanstalk verwendet wird .

Sie können die folgenden Schritte ausführen:

1. Zugriff auf die AWS Management Console
2. Öffnen Sie die Registerkarte Elastic Beanstalk
3. Wählen Sie Ihre Anwendung auf der Registerkarte Alle Anwendungen aus
4. Wählen Sie im Menü auf der linken Seite Konfiguration aus
5. Klicken Sie auf das Instances Gear
6. In Server überprüft Formular des EC2 Key Pair Eingang und wählen Sie Ihr neues Schlüsselpaar. Möglicherweise müssen Sie aktualisieren die Liste , um ein neues Schlüsselpaar zu sehen , die Sie gerade erstellt sind.
7. speichern
8. Elastic Beanstalk erstellt für Sie neue Instanzen, die dem neuen Schlüsselpaar zugeordnet sind.

Denken Sie im Allgemeinen daran, dass Sie Ihrer EC2-Instanz erlauben müssen, eingehenden SSH-Verkehr zu akzeptieren.

Dazu müssen Sie eine bestimmte Regel für die Sicherheitsgruppe Ihrer EC2-Instanz erstellen. Sie können diese Schritte ausführen.

1. Zugriff auf die AWS Management Console
2. Öffnen Sie die Registerkarte EC2
3. Aus Instanzen Liste wählen Sie die Instanz , die Sie interessiert sind
4. In der Beschreibung Tab Chek den Namen der Sicherheitsgruppe der Instanz verwendet.
5. Wieder in Beschreibung Tab auf klicken Ansicht Regeln und überprüfen , ob Ihre Sicherheitsgruppe eine Regel für eingehenden SSH - Verkehr auf Port verfügt über 22
6. Wenn nicht, wählen Sie im Menü Netzwerk & Sicherheit die Option Sicherheitsgruppe
7. Wählen Sie die von Ihrer Instanz verwendete Sicherheitsgruppe aus und klicken Sie auf die Registerkarte Eingehend
8. Auf der linken Seite der Registerkarte "Eingehend" können Sie eine Regel für eingehenden SSH-Verkehr erstellen:
   • Erstellen Sie eine neue Regel : SSH
   • Quelle : IP-Adresse oder Subnetz, von dem aus Sie auf die Instanz zugreifen möchten
   • Hinweis : Wenn Sie uneingeschränkten Zugriff auf Ihre Instanz gewähren möchten , können Sie 0.0.0.0/0 angeben , obwohl Amazon diese Vorgehensweise nicht empfiehlt
9. Klicken Sie auf Regel hinzufügen und dann auf Änderungen übernehmen
10. Überprüfen Sie, ob Sie jetzt über SSH eine Verbindung zu Ihrer Instanz herstellen können.

Hoffe das kann jemandem helfen wie mir geholfen hat.

So habe ich das Problem gelöst

ssh -i <key> ec2-user@<ec2 ip>

Ich löste das Problem nur darum sudovor

sudo ssh -i mykey.pem myec2.amazonaws.com

Die richtige Lösung besteht jedoch darin, zuerst den Eigentümer zu ändern und dann als normaler Benutzer eine Verbindung herzustellen, wie Janus Troelsen weiter unten sagte. In meinem Fall wäre es:

chown wellington:wellington key.pem

Versuchen Sie es mit

sudo ssh -i mykey.pem ubuntu@<ec2_ip_public_dns>

ODER

sudo ssh -i mykey.pem ec2-user@<ec2_ip_public_dns>

Eine weitere mögliche Ursache für diesen Fehler:

Wenn das Ausgangsverzeichnis des Benutzers für Gruppen beschreibbar ist , kann sich der Benutzer nicht anmelden.

(Wiedergabe auf Ubuntu-Instanz.)

für die ubuntu 12.04 lts micro instance musste ich den benutzernamen als option setzen

ssh -i pemfile.pem -l ubuntu dns

Sie müssen die folgenden Schritte ausführen:

1. Öffnen Sie Ihren SSH-Client oder Ihr Terminal, wenn Sie Linux verwenden.
2. Suchen Sie Ihre private Schlüsseldatei und ändern Sie Ihr Verzeichnis.
   cd <path to your .pem file>
3. Führen Sie die folgenden Befehle aus:
   chmod 400 <filename>.pem
ssh -i <filename>.pem ubuntu@<ipaddress.com>

Wenn der ubuntuBenutzer nicht arbeitet, versuchen Sie es mit ec2-user.

Ich kämpfte mit der gleichen Erlaubnis verweigert Fehler anscheinend wegen

key_parse_private2: missing begin marker 

In meiner Situation war die Ursache die ssh-Konfigurationsdatei des aktuellen Benutzers (~ / .ssh / config).

Verwenden Sie Folgendes:

ssh -i ~/myKey.pem ec2-user@<IP address> -v 'exit'

Die anfängliche Ausgabe zeigte:

debug1: Reading configuration data /home/ec2-user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug1: Hostname has changed; re-reading configuration
debug1: Reading configuration data /home/ec2-user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config

... viele Debug-Zeilen hier geschnitten ...

debug1: Next authentication method: publickey
debug1: Trying private key: /home/ec2-user/somekey.pem
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.

In der dritten Zeile oben wurde das tatsächliche Problem identifiziert. Ich habe jedoch vier Zeilen von unten (oben) nach der Debug-Meldung gesucht und wurde irregeführt. Es gibt kein Problem mit dem Schlüssel, aber ich habe ihn getestet und andere Konfigurationen verglichen.

Meine Benutzer-SSH-Konfigurationsdatei hat den Host über eine unbeabsichtigte globale Einstellung zurückgesetzt, wie unten gezeigt. Die erste Host-Zeile sollte kein Kommentar sein.

$ cat config
StrictHostKeyChecking=no
#Host myAlias
        user ec2-user
        Hostname bitbucket.org
#        IdentityFile ~/.ssh/somekey
#        IdentitiesOnly yes

Host my2ndAlias
        user myOtherUser
        Hostname bitbucket.org
        IdentityFile ~/.ssh/my2ndKey
        IdentitiesOnly yes

Ich hoffe, jemand anderes findet das hilfreich.

Ich habe vergessen, den Benutzernamen (Ubuntu) hinzuzufügen, wenn ich meine Ubuntu-Instanz verbinde. Also habe ich das versucht:

ssh -i /path/my-key-pair.pem my-ec2-instance.amazonaws.com

und der richtige Weg war

ssh -i /path/my-key-pair.pem ubuntu@my-ec2-instance.amazonaws.com

Das ist mir schon mehrmals passiert. Ich habe Amazon Linux AMI 2013.09.2 und Ubuntu Server 12.04.3 LTS verwendet, die beide auf der kostenlosen Ebene sind.

Jedes Mal, wenn ich eine Instanz gestartet habe, wurde mir die Berechtigung verweigert, angezeigt zu werden. Ich habe dies nicht überprüft, aber meine Theorie ist, dass der Server nicht vollständig eingerichtet ist, bevor ich versuche, ihn zu ssh. Nach einigen Versuchen mit verweigerter Erlaubnis warte ich einige Minuten und kann dann eine Verbindung herstellen. Wenn Sie dieses Problem haben, empfehle ich, fünf Minuten zu warten und es erneut zu versuchen.

Hier sind mögliche frustrierende Szenarien, die diesen Fehler verursachen:

Wenn Sie eine neue Instanz von einem AMI zu Mittag essen, das Sie von einer anderen Instanz erstellt haben (z. B. Instanz xyz), akzeptiert die neue Instanz nur denselben Schlüssel, den Instanz A verwendet hat. Dies ist völlig verständlich, wird jedoch verwirrend, da Sie während des schrittweisen Erstellens der neuen Instanz aufgefordert werden, einen Schlüssel auszuwählen oder zu erstellen (im allerletzten Schritt), der nicht funktioniert.

Unabhängig davon, welchen Schlüssel Sie erstellen oder auswählen, wird nur der Schlüssel, den Sie beispielsweise für XYZ verwendet haben, von der neuen Instanz akzeptiert.

Ich hatte auch eine Weile damit zu kämpfen, bis ich Folgendes fand:

eb ssh

Wenn Sie das aus dem Projektverzeichnis verwenden, sind Sie in Bingo-Bango ohne Muss

In meinem Fall habe ich Folgendes getan:

chmod 400 <key.pem>

ssh -i <key.pem> ec2-user@ec2_public_dns (for debian)

Ich habe anfangs ein root@Teil verwendet und diese Aufforderung erhalten:

Please login as the user "ec2-user" rather than the user "root".

Ich bin in Windows mit WinSCP . Es funktioniert sowohl im Datei-Explorer als auch in der PuTTY SSH-Shell hervorragend, um auf mein Amazon EC2-VPC Linux zuzugreifen . Es gibt nichts mit dem zu tun , chmod pem filewie es verwendet myfile.ppk umgewandelt durch PuTTYgen aus der pem - Datei .

Das gleiche passierte mir, aber alles, was passierte, war, dass der private Schlüssel aus dem Schlüsselbund auf meinem lokalen Computer verloren ging.

ssh-add -K

Der Schlüssel wurde erneut hinzugefügt, und der Befehl ssh zum Verbinden kehrte zur Arbeit zurück.

Dieses Problem kann gelöst werden, indem Sie sich mit dem folgenden Befehl in die Ubuntu-Box einloggen:

ssh -i ec2key.pem ubuntu@ec2-public-IP

Ich hatte zweimal die richtigen Tasten und die richtige ssh-Befehlszeile (ich weiß, weil ich eine funktionierende Ubuntu 14.04-Instanz dupliziere), konnte aber einfach nicht in eine neue Instanz ssh, selbst nachdem ich 5 Minuten gewartet hatte, wie von Wade Anderson oben vorgeschlagen.

Ich musste die Maschine zerstören und neu erstellen. Dies ist bei zwei verschiedenen Gelegenheiten geschehen. Da ich anfangs nicht einsteigen kann, kann ich nicht sehen, was los ist.

Wenn Sie dieses Problem haben, versuchen Sie es.

Sie müssen diese wenigen Dinge überprüfen:

1. Stellen Sie sicher, dass Ihre IP-Adresse korrekt ist
2. Stellen Sie sicher, dass Sie den richtigen Schlüssel verwenden
3. Stellen Sie sicher, dass Sie den richtigen Benutzernamen verwenden. Versuchen Sie Folgendes: 3.1. admin 3.2. ec2-user 3.3. Ubuntu

Ich hatte das gleiche Problem und es wurde gelöst, nachdem ich den Benutzernamen in Ubuntu geändert hatte. In der AWS-Dokumentation wurde der Benutzer ec2-user erwähnt, aber irgendwie funktioniert das bei mir nicht.

Mein privater Schlüssel wurde auf Berechtigung gesetzt 400 und führte dazu, dass die Berechtigung verweigert wurde. Das Setzen auf '644' hat mir geholfen.

key_load_private_type: Berechtigung verweigert ist der spezifische Fehler, den ich erhalten habe

Lösung: Sudo chmod 644 <key.pem>

Hinweis: Auf 644 gesetzt ist ein Muss, es funktionierte nicht mit 400

Wenn du es versuchst

ssh -i <.pem path> root@ec2-public-dns

Sie erhalten eine Nachricht, in der Sie aufgefordert werden, die zu verwenden ec2-user.

Please login as the user "ec2-user" rather than the user "root".

Also benutze

ssh -i <.pem path> ec2-user@ec2-public-dns

Ich hatte das gleiche Problem und es ist sehr seltsam. Wenn Sie glauben, dass Sie alles gut machen, dann folgen Sie diesen Anweisungen: Manchmal gibt es Verwirrung über den Benutzer für die EC2-Instanz !! Manchmal bekommst du ec2-Benutzer, Ubuntu, Centos usw. Also überprüfe deinen Benutzernamen für den Machie !!

Mit Root-Benutzer anmelden ssh -i yourkey.pem (400 permission) root@<ip> Es wird ein Fehler ausgegeben und Sie erhalten den verfügbaren Benutzernamen . Melden Sie sich dann mit diesem Benutzer an.

Es ist eine grundlegende Sache, aber bestätigen Sie immer, welcher Benutzer Sie versuchen, sich anzumelden. Ich bin mein Fall war nur eine Ablenkung . Ich habe versucht, einen Root- Benutzer zu verwenden:

ssh -i ~/keys/<key_name> root@111.111.111.111

War aber ein anderer User :

ssh -i ~/keys/<key_name> dedeco@111.111.111.111

Ich hatte den gleichen Fehler, aber eine andere Situation. Für mich passierte es aus heiterem Himmel, nachdem ich viel Zeit erfolgreich mit meinem Remote-Computer verbracht hatte. Nach langem Suchen waren die Dateiberechtigungen die Lösung für mein Problem. es ist natürlich seltsam, weil ich keine Berechtigungen in meinem Computer oder der Remote-Berechtigung geändert habe, die zu den Dateien / Verzeichnissen des SSH gehört. Also aus dem guten Archlinux-Wiki hier ist es:

Führen Sie für den lokalen Computer folgende Schritte aus:

$ chmod 700 ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/id_ecdsa

Für die Remote-Maschine machen Sie das:

$ chmod 700 ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys

Danach fing mein SSH wieder an zu arbeiten, ohne dass die Erlaubnis verweigert wurde (publickey).

Ein weiteres mögliches Problem: Falsche Login-ID

Überprüfen Sie die 'Gebrauchsanweisung'

Alle guten Vorschläge oben, aber ich bin darauf gestoßen, dass ich eine vorgefertigte Instanz ausgewählt habe. Lesen Sie nach dem Start der Instanz die Gebrauchsanweisung. Ich habe die Anmelde-ID des privaten Schlüssels falsch verwendet, als ich in den Anweisungen 'bitnami' verwenden sollte (z. B. bitnami @ domain -i key.pem).

Ich hatte einen ähnlichen Fehler

debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: xxxx.pem
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

Mein Problem war, dass die Instanz aufgrund eines Fehlers im Startskript von nicht ordnungsgemäß gestartet wurde Step 3: Configure instance detail unterAdvanced details:

Was ich dachte, ich habe eingegeben:

#include
 https://xxxx/bootstrap.sh


Was tatsächlich eingegeben wurde, unterbricht das Instanz-Setup

#include

https://xxxx/bootstrap.sh

Der öffentliche Schlüssel auf der Instanzseite wurde also nicht erstellt

Es unterscheidet zwischen Groß- und Kleinschreibung.

Falsch: SSH EC2-Benutzer @ XXX.XX.XX.XX -i MyEC2KeyPair.pem

Richtig: SSH ec2-user @ XXX.XX.XX.XX -i MyEC2KeyPair.pem

Ich konnte von einer Maschine aus SSH, aber nicht von einer anderen. Es stellte sich heraus, dass ich den falschen privaten Schlüssel verwendet habe.

Ich habe dies herausgefunden, indem ich den öffentlichen Schlüssel von meinem privaten Schlüssel wie folgt abgerufen habe:

ssh-keygen -y -f ./myprivatekey.pem

Was herauskam, stimmte nicht mit dem überein, was in ~/.ssh/authorized_keysder EC2-Instanz enthalten war.

Alle oben genannten Antworten sind korrekt und sollten in den meisten Fällen funktionieren. Für den Fall, dass sie nicht so sind wie in meinem Fall, habe ich einfach meine ~/.ssh/known_hostsDatei auf dem Computer entfernt, von dem ich ssh wollte, und das hat das Problem für mich gelöst. Ich konnte mich danach verbinden.