it-swarm.com.de

Berechtigung abgelehnt (publickey), wenn SSH-Zugriff auf Amazon EC2-Instanz erfolgt

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

Permission denied (publickey).

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

Gegeben: 

chmod  600 pem file.

Dann diesen Befehl

ssh -i /home/kashif/serverkey.pem  [email protected]

Aber habe diesen Fehler:

Permission denied (publickey)

Wie kann ich mich mit filezilla verbinden, um Dateien hochzuladen/herunterzuladen?

355
Kashiftufail

Diese Fehlermeldung bedeutet, dass Sie sich nicht authentifiziert haben. 

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 wird versucht, eine Verbindung mit dem falschen Benutzernamen herzustellen. ubuntu ist der Benutzername für die Ubuntu-basierte AWS-Distribution, aber bei einigen anderen ist es ec2-user (oder admin bei einigen Debianen entsprechend der Antwort von Bogdan Kulbida) (kann auch root, Fedora sein, siehe unten) 
  3. Versuch, den falschen Host zu verbinden. Ist das der richtige Host, bei dem Sie sich anmelden möchten?

Beachten Sie, dass 1. auch auftritt, wenn Sie die /home/<username>/.ssh/authorized_keys-Datei in Ihrer EC2-Instanz durcheinander gebracht haben. 

Bei 2. fehlt die Beschreibung des zu verwendenden Benutzernamens häufig der Beschreibung des AMI-Images. Einige davon finden Sie in der AWS EC2-Dokumentation: Punkt 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. Bei Amazon Linux lautet der Benutzername ec2-user. Bei RHEL5 lautet der Benutzername entweder root oder ec2-user. Für Ubuntu lautet der Benutzername ubuntu. Bei Fedora lautet der Benutzername entweder Fedora oder ec2-user. Bei SUSE Linux lautet der Benutzername root. Wenn ec2-user und root nicht funktionieren, wenden Sie sich an Ihren AMI-Provider.

Schließlich ist zu beachten, dass die Authentifizierung aus vielen anderen Gründen fehlschlagen kann. SSH ist in der Regel ziemlich eindeutig, was falsch gelaufen ist, wenn Sie die Option -v zu Ihrem SSH-Befehl hinzufügen und die Ausgabe lesen möchten, wie in vielen anderen Antworten auf diese Frage erläutert. 

589
Thibault D.

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

  • Schlüsselpaar kann nicht in einer Instanz geändert werden. 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 diesen Schritten folgen:

  1. Zugriff auf AWS Management Console
  2. Öffnen Sie Elastic Beanstalk Tab
  3. Wählen Sie Ihre Anwendung aus Alle Anwendungen Tab
  4. Wählen Sie im linken Menü Konfiguration aus.
  5. Klicken Sie auf das Instances Gear
  6. In Server Form überprüfen Sie die Eingabe EC2 Key Pair und wählen Sie Ihr neues Schlüsselpaar aus. Möglicherweise müssen Sie Aktualisieren der Liste erstellen, um ein neues Schlüsselpaar anzuzeigen, das Sie gerade erstellt haben.
  7. Sparen
  8. Elastic Beanstalk erstellt für Sie neue Instanzen, die mit dem neuen Schlüsselpaar verknüpft 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 diesen Schritten folgen.

  1. Zugriff auf AWS Management Console
  2. Öffnen Sie Registerkarte EC2
  3. Wählen Sie aus Instances list die Instanz aus, an der Sie interessiert sind
  4. In der Registerkarte Beschreibung überprüfen Sie den Namen der Sicherheitsgruppe, die Ihre Instanz verwendet.
  5. Klicken Sie erneut in Registerkarte Beschreibung auf Regeln anzeigen, und prüfen Sie, ob Ihre Sicherheitsgruppe eine Regel für eingehenden SSH-Verkehr auf Port 22 enthält
  6. Wenn nicht, wählen Sie in Netzwerk & Sicherheitmenü Sicherheitsgruppe aus.
  7. Wählen Sie das Sicherheitsgruppe aus, das von Ihrer Instanz verwendet wird, und klicken Sie auf das Symbol {Eingehende Registerkarte.
  8. Auf der linken Seite der Registerkarte Eingehend können Sie eine Regel für den eingehenden SSH-Verkehr erstellen:
    • Neue Regel erstellen: SSH
    • Quelle: IP-Adresse oder Subnetzwerk, von dem aus Sie auf die Instanz zugreifen möchten
    • Hinweis: Wenn Sie Ihrer Instanz unbegrenzten Zugriff 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 Übernehmen Sie Ihre Änderungen
  10. Prüfen Sie, ob Sie jetzt über SSH eine Verbindung zu Ihrer Instanz herstellen können.

Hoffe, das kann jemandem helfen, der mir geholfen hat.

48
Matteo Ceserani

So habe ich das Problem gelöst

ssh -i <key> [email protected]<ec2 ip>
43
Deepti Kohli

Ich habe das Problem gelöst, indem ich vorher Sudo gesetzt habe

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

Aber die richtige Lösung ist, zuerst den Besitzer zu wechseln und dann als normaler Benutzer eine Verbindung herzustellen, wie Janus Troelsen unten sagte. In meinem Fall wäre das:

chown wellington:wellington key.pem
26

Versuchen Sie es mit

Sudo ssh -i mykey.pem [email protected]<ec2_ip_public_dns>

OR

Sudo ssh -i mykey.pem [email protected]<ec2_ip_public_dns>
23
Abhishek Gupta

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

Wenn das home-Verzeichnis des Benutzers von der Gruppe schreibgeschützt ist, kann sich der Benutzer nicht anmelden.

(Wiedergabe in Ubuntu-Instanz.)

22
Stepan

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 [email protected]<ipaddress.com> 

Wenn ubuntu Benutzer nicht funktioniert, versuchen Sie es mit ec2-user.

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

ssh -i pemfile.pem -l ubuntu dns
7
dc10

Ich kämpfte mit der gleichen Erlaubnis, die Fehler offenbar wegen fehlgeschlagen ist 

key_parse_private2: missing begin marker 

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

Mit den folgenden:

ssh -i ~/myKey.pem [email protected]<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 suchte jedoch bei der Debug-Nachricht vier Zeilen von unten (oben) und wurde irregeführt. Es gibt kein Problem mit dem Schlüssel, aber ich habe ihn getestet und andere Konfigurationen verglichen.

Die ssh config-Datei meines Benutzers setzt den Host über eine unbeabsichtigte globale Einstellung zurück (siehe unten). 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.

5
Ben Paz

Ich habe vergessen, den Benutzernamen (ubuntu) beim Verbinden meiner Ubuntu-Instanz hinzuzufügen. Also habe ich es 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 [email protected]
4
JohnP

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

Jedes Mal, wenn ich eine Instanz gestartet habe, wurde die Erlaubnis verweigert. Ich habe das nicht bestätigt, aber meine Theorie besagt, dass der Server nicht vollständig eingerichtet ist, bevor ich versuche, ssh hineinzufahren. Nach ein paar Versuchen mit Erlaubnis verweigert, warte ich ein paar Minuten und kann mich dann verbinden. Wenn Sie dieses Problem haben, sollten Sie fünf Minuten warten und es erneut versuchen. 

3
Wade Anderson

dasselbe ist mir passiert, aber alles, was passiert ist, ist, dass der private Schlüssel aus dem Schlüsselbund meines lokalen Computers verloren ging.

ssh-add -K 

fügte den Schlüssel erneut hinzu und der ssh-Befehl zum Herstellen der Verbindung kehrte zur Arbeit zurück.

2
eiTan LaVi

Ich bin in Windows mit WINSCP. Es funktioniert sowohl im Datei-Explorer als auch in der PuTTY SSH-Shell, um auf mein Amazon EC2-VPC Linux zuzugreifen. Es hat nichts mit chmod pem file zu tun, da myfile.ppkkonvertiert von PuTTYgen aus der pem-Datei verwendet wird.

2
Chetabahana

In meinem eigenen Fall habe ich Folgendes getan:

chmod 400 <key.pem>

ssh -i <key.pem> [email protected]_public_dns (for debian)

Ich habe anfangs [email protected] part verwendet und ich habe folgende Aufforderung erhalten:

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

Hier ist ein mögliches frustrierendes Szenario, das diesen Fehler erzeugt:

Wenn Sie eine neue Instanz aus einer AMI, die Sie von einer anderen Instanz erstellt haben (beispielsweise Instanz xyz), zu Mittag essen, akzeptiert die neue Instanz nur den gleichen Schlüssel wie Instanz A. Das ist völlig verständlich, aber es wird verwirrend, weil Sie während des schrittweisen Erstellens der neuen Instanz aufgefordert werden, einen Schlüssel (ganz beim letzten Schritt) auszuwählen oder zu erstellen, der nicht funktioniert. 

Unabhängig von dem Schlüssel, den Sie erstellen oder auswählen, wird nur der von Ihnen verwendete Schlüssel, beispielsweise XYZ, von der neuen Instanz akzeptiert.

2
Seeker

Ich hatte auch eine Weile damit zu kämpfen, bis ich folgendes gefunden hatte:

eb ssh

Wenn Sie das aus dem Projektverzeichnis verwenden, ist Bingo-Bango kein Problem, Sie sind in

2
JedA

Wenn Sie versuchen, es zu tun 

ssh -i <.pem path> [email protected]

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

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

Also verwenden

ssh -i <.pem path> [email protected]

1
Jerome Anthony

Ich hatte dasselbe Problem und es ist sehr seltsam. Wenn Sie glauben, dass Sie alles gut machen, dann folgen Sie diesen Anweisungen: Manchmal gibt es Verwirrung hinsichtlich des Benutzers für die EC2-Instanz !! Manchmal bekommst du ec2-user, ubuntu, centos etc. Also überprüfe deinen Benutzernamen für die Machie !!

Mit root anmelden ssh -i yourkey.pem (400 permission) [email protected]<ip> Es wird ein Fehler ausgegeben und der verfügbare Benutzername wird angezeigt. Dann melden Sie sich mit diesem Benutzer an.

1
Manoj Sahu

Dieses Problem kann durch Anmelden an der Ubuntu-Box mit dem folgenden Befehl behoben werden:

ssh -i ec2key.pem [email protected]
1
Prajith

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

ssh -i ~/keys/<key_name> [email protected]

Aber war ein anderer Benutzer :

ssh -i ~/keys/<key_name> [email protected]
1
Andre Araujo

ich hatte den gleichen Fehler, aber eine andere Situation. für mich geschah es aus heiterem Himmel nach langer Zeit, dass ich ssh erfolgreich mit meinem Remote-Computer da draußen durchführen konnte. nach langem Suchen der Lösung für mein Problem waren Dateiberechtigungen. es ist natürlich seltsam, weil ich keine Berechtigungen auf meinem Computer oder dem Remote geändert habe, der zu den Dateien/Verzeichnissen der SSH gehört. also aus dem guten archlinux wiki hier ist es: 

Gehen Sie für den lokalen Computer folgendermaßen vor:

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

Für den Remote-Rechner das:

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

danach begann meine ssh wieder ohne die erlaubnis verweigert (publickey) sache.

1
Elimelech

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. Vergewissern Sie sich, 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 behoben, 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.

1
Mehran

Ich hatte zweimal Schlüssel und SSH-Befehlszeile richtig (ich weiß, weil ich eine funktionierende Ubuntu 14.04-Instanz dupliziere), aber es war einfach nicht möglich, SSH in eine neue Instanz umzuwandeln, selbst nach einer Wartezeit von 5 Minuten, wie oben von Wade Anderson 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 falsch ist.

Wenn Sie also dieses Problem haben, versuchen Sie es.

1
Greg Bell

Mein privater Schlüssel wurde auf Erlaubnis 400 gesetzt und führte dazu, dass Berechtigung abgelehnt wurde, wenn er auf '644' gesetzt wurde.

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

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

Hinweis: auf 644 muss gesetzt sein, es funktionierte nicht mit 400

1
Kuldeep Dangi

Es ist case sensitive. 

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

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

0
Tanmay

Ein weiteres mögliches Problem: Falsche Login-ID

Überprüfen Sie die Verwendungshinweise.

Alle guten Vorschläge oben, aber ich bin darauf gekommen, dass ich eine vorgefertigte Instanz ausgewählt habe. Sehen Sie sich nach dem Starten der Instanz die Verwendungsanweisungen an. Ich habe die Login-ID des privaten Schlüssels falsch verwendet, als in den Anweisungen 'bitnami' verwendet werden sollte (z. B. bitnami @ domain -i key.pem)

0
Mike Q

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 Step 3: Configure instance detail unter Advanced details: nicht ordnungsgemäß gestartet wurde.

Was ich dachte, ich trat ein:

#include
 https://xxxx/bootstrap.sh


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

#include

https://xxxx/bootstrap.sh

Daher wurde der öffentliche Schlüssel auf der Instanzseite nicht erstellt

0
RNA