seeseekey.net - Invictus Deus Ex Machina

Möchte man sich auf einem Linux-Server per SSH Schlüssel anmelden, so kopiert man im ersten Schritt seinen Schlüssel auf den entfernten Server:

ssh-copy-id -i ~/.ssh/id_rsa.pub ssh-nutzername@example.org

Anschließend kann man sich mittels:

ssh ssh-nutzername@example.org

ohne Passworteingabe auf den Rechner einloggen. Sollte dies nicht der Fall sein, gibt es ein Problem. So kann es passieren das man trotz SSH-Schlüssel ein Passwort eingeben soll. Um die Ursache zu diagnostizieren hilft es “ssh” im Verbose-Modus zu benutzen:

ssh -v ssh-nutzername@example.org

Im diesem Modus werden viele Debuginformationen ausgegeben, welche helfen können das Problem einzugrenzen. Das man Passwörter trotz eines SSH Schlüssels eingeben muss, liegt manchmal an falsch konfigurierten Dateirechten im “.ssh” Ordner auf dem entfernten Rechner. Die einfachste Möglichkeit ist es hier den Ordner komplett zu entfernen, damit er vom System nochmal angelegt wird. Dazu muss der Schlüssel natürlich mittels “ssh-copy-id” wieder auf dem Rechner angebracht werden. Alternativ ist es auch möglich die Rechte für diesen Ordner neu zu setzen:

chmod 700 /home/seeseekey/.ssh/
chmod 600 /home/seeseekey/.ssh/authorized_keys

Wenn der Verbose-Modus nicht die gewünschten Ergebnisse bringt, so sollte sich die Logdatei /var/log/auth.log” angeschaut werden. Dort kann man dann z.B. solche Meldungen bewundern:

Sep 21 01:47:35 service sshd[34221]: Authentication refused: bad ownership or modes for directory /home/seeseekey

In diesem Fall lag es nicht nur am “.ssh” Verzeichnis, sondern auch an dem Homeverzeichnis des Nutzers. Ein:

chmod 700 /home/seeseekey/

wirkt in einem solchen Fall wahre Wunder. Danach sollte auch die Authentifikation per SSH-Schlüssel wieder funktionieren.

5 Kommentare

  1. Oder es kann auch sein, dass das Zertifikat selbst noch mit einem Passwort geschützt ist, dann muss man natürlich dieses eingeben.

    Oder ist es üblich, SSH-Zertifikate ohne Passwort zu erstellen? Habe da bisher noch nicht so viel gemacht, würde aber generell auf Zertifikate setzen, damit niemand einfach das Passwort abhört.

    Antworten

    • Das Passwort lässt sich auch nicht ohne weiteres abhören, da die Verbindung verschlüsselt ist – egal ob mit Authentifikation per Passwort oder Zertifikat gearbeitet wird. Ein mit einem Passwort verschlüsseltes Zertifikat hat natürlich den Vorteil, das selbst im Falle des Abhandenkommens derjenige mit dem Zertifikat nicht all zu viel anfangen kann.

      Antworten

    • Hallo Linuxpresso:

      Ob man das SSH-Zertifikat zusätzlich mit einem Passwort schützt, hängt auch vom Anwendungsfall ab. Für die Nutzung in Skripten ist das Passwort hinderlich, deshalb werden Zertifikate sehr oft ohne Passwort angelegt.

      Antworten

  2. Du bist mit einem BSD oder OSX unterwegs, richtig? Die Linux-Versionen von SSH weisen einen nämlich auf solche Probleme hin und bieten Lösungsvorschläge an. War neulich unter OSX auch mal überrascht warum es nicht ging.

    Antworten

Schreibe einen Kommentar

You have to agree to the comment policy.