Wie behebe ich die Fehler „Permission denied (publickey)“ oder „Authentication failed, permission denied“, wenn ich auf meine EC2-Instance zugreife?

Lesedauer: 7 Minute
0

Wenn ich auf meine Amazon Elastic Compute Cloud (Amazon EC2)-Instance zugreife, erhalte ich die Fehlermeldung „Permission denied (publickey)“ oder „Authentication failed, permission denied“.

Kurzbeschreibung

Die Fehler Permission denied (publickey) und Authentication failed, permission denied treten aus den folgenden Gründen auf:

  • Du verwendest den falschen Benutzernamen für das Amazon Machine Image (AMI), wenn du eine Verbindung herstellst.
  • Du hast falsche Dateiberechtigungen im Betriebssystem (OS) der Instance.
  • Die Datei authorized_keys enthält die falsche öffentliche SSH-Schlüssel-Datei (.pub), oder du hast die Instance ohne Schlüssel gestartet.
  • Die Datei authorized_keys oder der .ssh-Ordner ist nicht richtig benannt.
  • Die Datei authorized_keys oder der .ssh-Ordner wurde gelöscht.
  • (Nur Ubuntu 20.x) Du verwendest AuthorizedKeysCommand in deiner SSH-Konfiguration.

Lösung

Sicherstellen, dass du den richtigen Benutzernamen für das AMI hast

Stelle sicher, dass du einen gültigen Benutzernamen für das AMI verwendest.

Stelle sicher, dass die Dateiberechtigungen im Betriebssystem korrekt sind und dass der richtige öffentliche SSH-Schlüssel in der authorized_keys-Datei enthalten ist

Verwende eine der folgenden Methoden, um deine Konfiguration zu überprüfen.

Verwendung der seriellen EC2-Konsole

Wenn du die serielle EC2-Konsole für Linux aktiviert hast, kannst du die Konsole zur Fehlerbehebung bei unterstützten Nitro-basierten Instance-Typen verwenden. Die serielle Konsole stellt eine Verbindung zu deiner Instance her, ohne dass eine Netzwerkverbindung erforderlich ist. Du kannst über die Amazon-EC2-Konsole oder AWS Command Line Interface (AWS CLI) auf die serielle Konsole zugreifen.

Bevor du die serielle Konsole verwendest, gewähre auf AWS-Kontoebene Zugriff darauf. Erstelle dann AWS Identity and Access Management (IAM. Identitäts- und Zugriffsmanagement)-Richtlinien, die IAM-Benutzern Zugriff auf die Konsole gewähren. Jede Instance, die die serielle Konsole verwendet, muss mindestens einen passwortbasierten Benutzer enthalten. Informationen zur Konfiguration der seriellen EC2-Konsole für Linux findest du unter Konfigurieren des Zugriffs auf die serielle EC2-Konsole.

Wenn die Instance nicht erreichbar ist und du den Zugriff auf die serielle Konsole nicht konfiguriert hast, überprüfe deine Konfiguration mit einer anderen Methode.

Hinweis: Wenn du beim Ausführen von AWS CLI-Befehlen Fehlermeldungen erhältst, findest du weitere Informationen dazu unter Problembehandlung bei der AWS CLI. Stelle außerdem sicher, dass du die neueste Version der AWS CLI verwendest.

Verwendung des Systems Manager Session Manager

Hinweis: Um diese Methode zu verwenden, musst du den SSM Agent installieren. Eine Liste der Voraussetzungen für die Verwendung von Systems Manager findest du unter Schritt 1: Voraussetzungen für den Session Manager erfüllen.

Verwende den AWS Systems Manager Session Manager, um dich bei der Instance anzumelden und Korrekturen vorzunehmen. Führe die folgenden Schritte aus:

  1. Öffne die Systems Manager-Konsole.

  2. Starte eine Sitzung.

  3. Um zu überprüfen, ob die Berechtigungen der Dateien im Stamm-Verzeichnis korrekt sind, führe den Befehl ls -ld aus:

    ls -ld /home/ec2-user/

    Hinweis: Ersetze ec2-user durch deinen Benutzernamen, der auf dem Instance Amazon Machine Image (AMI) basiert.
    Du erhältst eine Ausgabe, die der folgenden ähnelt:

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

    Das folgende Beispiel zeigt eine Liste der richtigen erforderlichen Berechtigungen:
    Verwende (0755/drwxr-xr-x) für das Linux-Stammverzeichnis /home.
    Verwende (0700/drwx------) für das Stammverzeichnis des Benutzers /home/ec2-user/.
    Verwende (0700/drwx------) für die ssh-Verzeichnisberechtigung /home/ec2-user/.ssh.
    Verwende (0600/-rw-------) für die authorized_keys-Dateiberechtigung /home/ec2-user/.ssh/authorized_keys.

  4. Stelle auf deinem lokalen Computer sicher, dass du einen öffentlichen SSH-Schlüssel verwendest.

  5. Wenn die Signatur des öffentlichen SSH-Schlüssels in der Ausgabe nicht vorhanden ist, aktualisiere die Datei authorized_keys, um deinen SSH-Schlüssel zuzulassen. Führe den folgenden Befehl aus:

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

    Hinweis: Ersetze den Beispielschlüssel durch deinen öffentlichen SSH-Schlüssel.

  6. Führe die folgenden Befehle auf der EC2-Instance aus, um die 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. Beende die Sitzung.

  8. Verwende SSH, um eine Verbindung zur Instance herzustellen.

Das AWSSupport-TroubleshootSSH-Automatisierungs-Runbook ausführen

Verwende AWSSupport-TroubleshootSSH, um nach Problemen zu suchen, die zu Fernverbindungsfehlern zu einem Linux-Computer über SSH führen, und diese zu beheben. Weitere Informationen findest du unter Ich erhalte Fehler, wenn ich versuche, mit SSH eine Verbindung zu meiner EC2-Instance herzustellen. Wie kann ich den AWSSupport-TroubleshootSSH-Automatisierungsablauf verwenden, um SSH-Verbindungsprobleme zu beheben?

Verwendung eines Benutzerdatenskripts, um SSH-Berechtigungen zu reparieren und den richtigen öffentlichen SSH-Schlüssel zur Datei authorized_keys hinzuzufügen

Wichtig: Um diese Methode zu verwenden, musst du die Instance beenden. Wenn du die Instance stoppst, treten die folgenden Effekte auf:

  • Wenn die Instance von einem Amazon Elastic Block Storage (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/RootDeviceStorage.html#display-instance-root-device-type)-Instance-Speicher[ unterstützt wird oder Instance-Speicher-Volumes mit Daten hat, gehen die Daten verloren.
  • Wenn die Instance Teil einer Amazon EC2 Auto-Scaling-Gruppe ist, beendet Amazon EC2 Auto Scaling die Instance möglicherweise. Instances, die du mit Amazon EMR, AWS CloudFormation oder AWS Elastic Beanstalk startest, sind möglicherweise Teil einer Auto-Scaling-Gruppe. Das Beenden der Instance hängt in diesem Fall von den Instance-Skalierungs-Schutzeinstellungen für die Auto-Scaling-Gruppe ab. Wenn die Instance Teil einer Auto-Scaling-Gruppe ist, entferne die Instance vorübergehend aus der Auto-Scaling-Gruppe, bevor du die folgenden Schritte ausführst.
  • Die öffentliche IP-Adresse der Instance ändert sich. Es empfiehlt sich, beim Weiterleiten von externem Datenverkehr an die Instance eine Elastic-IP-Adresse anstelle einer öffentlichen IP-Adresse zu verwenden.

Gehe wie folgt vor, um deine SSH-Berechtigungen zu reparieren:

  1. Öffne die Amazon-EC2-Konsole.

  2. Wähle im Navigationsbereich Instances aus und wähle dann die Instance aus, zu der du eine Verbindung herstellen möchtest.

  3. Stoppe die Instance.

  4. Wähle Aktionen und dann Instance-Einstellungen aus.

  5. Wähle Benutzerdaten bearbeiten.

  6. Gib für Benutzerdaten bearbeiten das folgende Benutzerdatenskript ein:

    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=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: Ersetze os-user durch den Benutzernamen, der dem AMI zugeordnet ist, mit dem du die Instance gestartet hast.

  7. Wähle Speichern.

  8. Stelle auf deinem lokalen Computer sicher, dass du einen öffentlichen SSH-Schlüssel verwendest.

  9. Wenn die Signatur des öffentlichen SSH-Schlüssels nicht in der Ausgabe enthalten ist, füge den Schlüssel zum Benutzerdatenskript hinzu. Wenn die Signatur übereinstimmt, fahre mit dem nächsten Schritt fort.

    Beispiel für ein Benutzerdatenskript mit einem ö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=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
    --//
  10. Starte deine Instance.

Hinweis: Das vorstehende Benutzerdatenskript ist so eingestellt, dass es bei jedem Neustart der Instance ausgeführt wird. Nachdem du wieder Zugriff auf die Instance erhalten hast, entferne das Benutzerdatenskript.

(nur Ubuntu 20.x) Überprüfe den AuthorizedKeysCommand auf die SSH-Konfiguration

In Ubuntu 20.x ist EC2 Instance Connect standardmäßig installiert. Wenn du die Einstellungen AuthorizedKeysCommand und AuthorizedKeysCommandUser für die SSH-Authentifizierung konfigurierst, aktualisiert die EC2 Instance Connect-Installation diese Einstellungen nicht. Daher kannst du EC2 Instance Connect nicht verwenden. Um dieses Problem zu beheben, entferne AuthorizedKeysCommand und AuthorizedKeysCommandUser aus deiner SSH-Konfiguration.

Ähnliche Informationen

Wie kann ich Probleme beim Herstellen einer Verbindung zu meiner Amazon-EC2-Linux-Instance über SSH beheben?

Ich habe meinen privaten Schlüssel verloren. Wie kann ich eine Verbindung zu meiner Instance herstellen?

Wie stelle ich eine Verbindung zu meiner Amazon EC2-Instance her, wenn ich mein SSH-Schlüsselpaar nach dem ersten Instance-Start verliere?

AWS OFFICIAL
AWS OFFICIALAktualisiert vor 4 Monaten