Zum wiederholten Male hatte ich diese Woche Probleme, mich per SSH mit einem Server zu verbinden. Es war mit einem anderen User und irgendetwas hat nicht funktioniert. Wenn ich solche Fehler debugge, muss ich immer wieder danach suchen, wie man den Debug-Modus aktivieren kann. Daher schreibe ich das jetzt mal in meinem eigenen Blog auf, damit ich es nächstes Mal schneller wiederfinde.

Starten eines zusätzlichen OpenSSH-Daemon im Debug-Modus

Ihr könnte recht einfach den Debug-Modus im Client aktivieren, aber oft liegt das Problem auch auf dem Server. Um das zu debuggen, könnt ihr den Debug-Modus im Hauptprozess aktivieren. Aber es ist oft einfacher und sicherer, einen zusätzlichen SSH-Daemon unter einem anderen Port und mit aktiviertem Debug-Mode zu starten. Das könnt ihr mit dem folgenden Befehl machen:

/usr/sbin/sshd -ddd -D -p 22222

Ihr müsst hier den vollständigen Pfad zu sshd verwenden. Mit dem -D Parameter wird sshd nicht als Daemon im Hintergrund ausgeführt und ihr könnt die Log-Ausgabe sehen. Mit -ddd wird das maximale Debug-Level aktiviert. Und mit -p 22222 verwenden wir einen anderen Port.

Den Debug-Mode des Clients verwenden

Nachdem wir nun einen Server-Prozess mit aktivierten Debugging haben, der auf einkommende Verbindungen wartet, können wir uns mit einem Client verbinden. Dazu verwenden wir den folgenden Befehl:

ssh -vvv -p 22222 -i ~/.ssh/id_ed25519 user@example.com

In diesem Beispiel verwenden wir den zuvor gesetzten Port 22222. Wir spezifizieren hier auch einen anderen Secret-Key mit -i ~/.ssh/id_ed25519 und schließlich setzen wir mit -vvv auch das maximale Debug-Level für den Client.

Zwei typische Fehler für SSH-Server und Client

Jetzt sollten wir in der Lage sein, die Fehler von Server und/oder Client zu finden. Hier sind zwei typische Fehler, denen ich oft begegne.

Falsche Dateiberechtigungen auf dem Server

Fehler mit SSH sind sehr oft falsch gesetzte Berechtigungen für Dateien und Ordner. Das ist ein typischer:

debug1: trying public key file /home/user/.ssh/authorized_keys
debug1: Could not open authorized keys '/home/user/.ssh/authorized_keys': Permission denied

Wenn ihr diesen Fehler seht, dann habt ihr vielleicht den Public-Key korrekt zu authorized_keys Datei hinzugefügt, die Datei ist aber nicht durch den SSH-Daemon lesbar. Um das zu korrigieren, solltet ihr die Berechtigungen in etwa so anpassen:

chmod 700 /home/user/.ssh/
chmod 644 /home/user/.ssh/authorized_keys

Wenn ihr einen Fehler beim letzten Verbindungsversuch bekommen habt, dann wurde der Server-Prozess vermutlich beendet. Ihr solltet also sicherstellen, dass ihr ihn vor dem nächsten Versuch neu startet.

Falsche Dateiberechtigungen im Client

Auch beim Client führen sehr oft falsche Berechtigungen zu Fehlern. Wenn die Berechtigungen „zu offen“ sind, dann bekommt ihr eine Meldung, die in etwa so aussieht:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for 'id_ed25519' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "id_ed25519": bad permissions
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
user@example.com: Permission denied (publickey).

Die Lösung hierfür ist sehr ähnlichen zum Server. Aber in diesem Fall müsst ihr sicherstellen, dass die Berechtigungen nicht zu weitgefasst sind und nur der User Zugriff auf den Private-Key hat:

chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

Der Public-Key kann auch durch andere lesbar sein. Der zweite Befehl ist also optional.

Fazit

Es gibt viele Probleme, auf die ihr bei der Arbeit mit SSH stoßen könnt. SSH ist wirklich sehr strikt, wenn es um Berechtigungen geht. Wenn ihr den Fehler mit einem zu offenen Private-Key hattet und auf einem Client/Computer arbeitet, auf dem es auch andere User gibt, dann solltet ihr den Key am besten wegwerfen und einen neuen erstellen. Wenn ihr hierzu ssh-keygen verwendet, dann hat das eine Schlüsselpaar auch gleich die richtigen Berechtigungen.

Ich verwende zheutztage nur noch SSH um mich per Terminal zu Servern zu verbinden oder Dateien zu übertragen. Die Verwendung von Schlüsselpaaren ist hierbei oft der beste Weg. Aber diese Berechtigungen können echt schwierig sein. Hoffentlich wisst ihr nun, wie ihr solche Fehler debuggen könnt – genau wie ich, denn jetzt kann ich hier nächstes Mal nachlesen, wie ich den Debug-Modus verwenden kann. 😀