Ich erhalte die Fehler „Permission denied (Publickey)“ (Berechtigung verweigert (Publickey)) oder „Authentication failed, Permission denied“ (Authentifizierung fehlgeschlagen, Berechtigung verweigert), wenn ich versuche auf meine EC2-Instance zuzugreifen. Wie kann ich dies beheben?

Lesedauer: 7 Minute

Ich erhalte die Fehler „Berechtigung verweigert (publickey)“ oder „Authentifizierung fehlgeschlagen, Berechtigung verweigert“ beim Zugriff auf meine Amazon Elastic Compute Cloud (Amazon EC2)-Instance. Wie kann ich dies beheben?

Kurzbeschreibung

Die Fehler „Berechtigung verweigert (publickey)“ und „Authentifizierung fehlgeschlagen, Berechtigung verweigert“ treten auf, wenn:

Sie versuchen, sich mit dem falschen Benutzernamen für Ihr AMI zu verbinden.
Die Dateiberechtigungen innerhalb des Betriebssystems sind auf der Instance falsch.
Die falsche SSH-Datei (.pub) sich in der Datei authorized_keys befindet.

Auflösung

Sicherstellen, dass Sie den richtigen Benutzernamen für Ihr AMI verwenden

Eine Liste gültiger Benutzernamen finden Sie unter Fehler: Server hat unseren Schlüssel abgelehnt oder Keine unterstützten Authentifizierungsmethoden verfügbar.

Stellen Sie sicher, dass die Dateiberechtigungen innerhalb des Betriebssystems korrekt sind und dass sich der richtige öffentliche SSH-Schlüssel in der Datei authorized_keys befindet

Es gibt vier Methoden zum Ausführen dieser Aufgaben:

Methode 1: Verwenden Sie die serielle EC2-Konsole

Wenn Sie die serielle EC2-Konsole für Linux aktivieren, können Sie damit unterstützte Nitro-basierte Instance-Typen beheben. Die serielle Konsole hilft Ihnen bei der Behebung von Startproblemen, Netzwerkkonfigurations- und SSH-Konfigurationsproblemen. Die serielle Konsole stellt eine Verbindung zu Ihrer Instance her, ohne dass eine funktionierende Netzwerkverbindung erforderlich ist. Sie können über die Amazon-EC2-Konsole oder die AWS Command Line Interface (AWS CLI) auf die serielle Konsole zugreifen.

Gewähren Sie vor der Verwendung der seriellen Konsole Zugriff auf Kontoebene. Erstellen Sie dann AWS-Identity-and-Access-Management-Richtlinien (IAM), die Ihren IAM-Benutzern Zugriff gewähren. Außerdem muss jede Instance, die die serielle Konsole verwendet, mindestens einen kennwortbasierten Benutzer enthalten. Wenn Ihre Instance nicht erreichbar ist und Sie den Zugriff auf die serielle Konsole nicht konfiguriert haben, dann befolgen Sie die Anweisungen in Methode 2, 3 oder 4. Informationen zur Konfiguration der seriellen EC2-Konsole für Linux finden Sie unter Konfigurieren des Zugriffs auf die serielle EC2-Konsole.

Hinweis: Wenn Sie beim Ausführen von AWS-CLI-Befehlen Fehler erhalten, stellen Sie sicher, dass Sie die neueste Version der AWS CLI verwenden.

Methode 2: Verwenden Sie AWS Systems Manager Session Manager, um sich bei der Instance anzumelden und Korrekturen vorzunehmen

Diese Methode aktualisiert Berechtigungen und injiziert Ihren öffentlichen SSH-Schlüssel in die Datei authorized_keys.

Hinweis: Die Installation des SSM Agent ist erforderlich, um diese Methode zu verwenden. Weitere Informationen zum Sitzungsmanager und eine vollständige Liste der Voraussetzungen finden Sie unter Einrichten des Sitzungsmanagers.

1. Öffnen Sie die AWS-Systems-Manager-Konsole.

2. Starte eine Sitzung.

3. Verwenden Sie den Befehl ls -ld, um sicherzustellen, dass die Berechtigungen der Dateien im Verzeichnis home korrekt sind. Das Folgende ist eine Liste der richtigen Berechtigungen:

Das Linux-Heimverzeichnis /home sollte beispielsweise (0755/drwxr-xr-x) lauten.
Das Heimverzeichnis des Benutzers, /home/ec2-user/, sollte beispielsweise (0700/drwx------) lauten.
.ssh-Verzeichnisberechtigung, /home/ec2-user/.ssh sollte beispielsweise (0700/drwx------) lauten.
Die Dateiberechtigung „authorized_keys“, /home/ec2-user/.ssh/authorized_keys, sollte beispielsweise (0600/-rw-------) lauten.

Das Folgende ist ein Beispiel für den Befehl ls -ld und die resultierende Ausgabe. In diesem Beispiel ist ec2-user der Benutzername. Ändern Sie den Benutzernamen gemäß Ihrem spezifischen AMI.

$ ls -ld /home/ec2-user/
drwx------ 3 ec2-user ec2-user 4096 Apr  1 08:31 /home/ec2-user/

4. Überprüfen Sie auf Ihrem lokalen Computer den öffentlichen SSH-Schlüssel.

5. Wenn die Signatur des öffentlichen SSH-Schlüssels in der Ausgabe nicht vorhanden ist, dann aktualisieren Sie die Datei authorized_keys, um Ihren SSH-Schlüssel zuzulassen. Ersetzen Sie im folgenden Beispiel den Beispielschlüssel durch Ihren öffentlichen SSH-Schlüssel.

$ echo 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDVogCW5eZogRp+vF6Ut360b0bYyTmqgYaCXOyiW77I916AS5jFL3zsCtONbGn4hnG/UGGWXpLfUV85qpVJb38fskPZNuyZtjGjXM2W7qqbCZ1N9HBb6IPBaL97tmqBi+8rD7mSkoHc40sIV+KxkQSvD6AAFjQruCjxzfGIApnOvuj6IMsVEuFHBx4QhkbCzafxo02D9BZT4+dMy7tmyuC+UiNEQpgfFoszl+4VNFTIPlQQyn6CpUiV/rFXIadXsHqc+UOdVnfEXP+30YL75RHabze/1F5MY6t94AEcmcb05Dq4vwN9IjcxKmwgvxLOXzryytepvHQU+PobBEXAMPLE' >> /home/ec2-user/.ssh/authorized_keys

6. Führen Sie die folgenden Befehle auf Ihrer EC2-Instance aus, um Berechtigungen zu korrigieren.

$ sudo chown root:root /home
$ sudo chmod 755 /home
$ sudo chown ec2-user:ec2-user /home/ec2-user -R
$ sudo chmod 700 /home/ec2-user /home/ec2-user/.ssh
$ sudo chmod 600 /home/ec2-user/.ssh/authorized_keys

7. Beenden Sie die Sitzung.

8. Verbinden Sie sich mit SSH mit der Instance.

Methode 3: Führen Sie das AWSSupport-TroubleshootsSH-Automatisierungsverfahren aus

AWSSupport TroubleshootSSH installiert das Amazon-EC2Rescue-Tool. Nach der Installation überprüft das Tool einige Probleme und behebt sie, die beim Herstellen einer Verbindung mit einem Linux-Computer über SSH zu Remote-Verbindungsfehlern führen. Weitere Informationen finden Sie unter Wie kann ich den Automatisierungsworkflow für AWSSupport TroubleshootSSH verwenden, um SSH-Verbindungsprobleme zu beheben?

Methode 4: Verwenden Sie ein Benutzerdatenskript, um SSH-Berechtigungen zu reparieren und der Datei authorized_keys den richtigen öffentlichen SSH-Schlüssel hinzuzufügen

Wichtig

Wenn Ihre Instance durch den Instance-Speicher gesichert ist oder über Instance-Speicher-Volumes verfügt, die Daten enthalten, gehen die Daten verloren, wenn die Instance gestoppt wird. Weitere Informationen finden Sie unter Bestimmen des Root-Gerätetyps Ihrer Instance.
Wenn Ihre Instance Teil einer Gruppe von Amazon EC2 Auto Scaling ist, kann das Stoppen der Instance sie dann beenden. Instances, die mit Amazon EMR, AWS CloudFormation oder AWS Elastic Beanstalk gestartet wurden, können Teil einer AWS-Auto-Scaling-Gruppe sein. Die Beendigung der Instance in diesem Szenario hängt von den Instance-Skalierungsschutzeinstellungen für Ihre Auto-Scaling-Gruppe ab. Wenn Ihre Instance Teil einer Auto-Scaling-Gruppe ist, entfernen Sie die Instance vorübergehend aus der Auto-Scaling-Gruppe, bevor Sie mit den Auflösungsschritten beginnen.
Durch das Stoppen und Starten der Instance wird die öffentliche IP-Adresse Ihrer Instance geändert. Es ist eine bewährte Methode, beim Weiterleiten von externem Datenverkehr an Ihre Instance eine Elastic-IP-Adresse anstelle einer öffentlichen IP-Adresse zu verwenden.

1. Öffnen Sie die Amazon-EC2-Konsole.

2. Wählen Sie im Navigationsbereich Instances und wählen Sie dann die Instance aus, die Sie starten möchten.

3. Stoppen Sie die Instance.

4. Wählen Sie Aktionen, Instance-Einstellungen, Benutzerdaten bearbeiten.

5. Kopieren Sie das folgende Benutzerdatenskript in das Dialogfeld Benutzerdaten bearbeiten und wählen Sie dann Speichern.

Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0

--//
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"

#cloud-config
cloud_final_modules:
- [scripts-user, always]

--//
Content-Type:
    text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="userdata.txt"

#!/bin/bash
OS_USER=@@@@@@
chown root:root /home 
chmod 755 /home
chown $OS_USER:$OS_USER /home/$OS_USER -R
chmod 700 /home/$OS_USER
chmod 700 /home/$OS_USER/.ssh
chmod 600 /home/$OS_USER/.ssh/authorized_keys
--//

Hinweis: Ersetzen Sie den Wert für OS_USER durch den Benutzernamen, der mit dem AMI verknüpft ist, von dem Sie Ihre Instance gestartet haben. Weitere Informationen finden Sie unter Abrufen des Standardbenutzernamens für das AMI, mit dem Sie Ihre Instance gestartet haben, unter Häufige Ursachen für Verbindungsprobleme.

6. Überprüfen Sie auf Ihrem lokalen Computer den öffentlichen SSH-Schlüssel.

7. Wenn die Signatur des öffentlichen SSH-Schlüssels in der Ausgabe nicht vorhanden ist, fügen Sie den richtigen Schlüssel an das Benutzerdatenskript an, das Sie in Schritt 5 erstellt haben. Wenn die Signatur übereinstimmt, können Sie diesen Schritt überspringen. Hängen Sie den öffentlichen SSH-Schlüssel an das Benutzerdatenskript an, wie im folgenden Beispiel gezeigt. Ersetzen Sie den Beispielschlüssel durch Ihren öffentlichen SSH-Schlüssel.

Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0

--//
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"

#cloud-config
cloud_final_modules:
- [scripts-user, always]

--//
Content-Type:
    text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="userdata.txt"

#!/bin/bash
OS_USER=@@@@@@
chown root:root /home 
chmod 755 /home
chmod 700 /home/$OS_USER
chmod 700 /home/$OS_USER/.ssh
chmod 600 /home/$OS_USER/.ssh/authorized_keys
echo 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDVogCW5eZogRp+vF6Ut360b0bYyTmqgYaCXOyiW77I916AS5jFL3zsCtONbGn4hnG/UGGWXpLfUV85qpVJb38fskPZNuyZtjGjXM2W7qqbCZ1N9HBb6IPBaL97tmqBi+8rD7mSkoHc40sIV+KxkQSvD6AAFjQruCjxzfGIApnOvuj6IMsVEuFHBx4QhkbCzafxo02D9BZT4+dMy7tmyuC+UiNEQpgfFoszl+4VNFTIPlQQyn6CpUiV/rFXIadXsHqc+UOdVnfEXP+30YL75RHabze/1F5MY6t94AEcmcb05Dq4vwN9IjcxKmwgvxLOXzryytepvHQU+PobBEXAMPLE' >> /home/$OS_USER/.ssh/authorized_keys
chown $OS_USER:$OS_USER /home/$OS_USER -R
--//

8. Starten Sie Ihre Instance.

Hinweis: Das vorhergehende Benutzerdatenskript wird so eingestellt, dass es bei jedem Neustart der Instance ausgeführt wird. Nachdem Sie wieder Zugriff auf Ihre Instance erhalten haben, entfernen Sie das Benutzerdatenskript.

So entfernen Sie Benutzerdaten: