Im Grunde ein einfaches Unterfangen, welches im Internet auf unzähligen Seiten dokumentiert ist. Kurzfassung: Auf dem eigenen Arbeitsrechner einen privaten und öffentlichen Schlüssel erstellen, auf der Synology Diskstation den SSH-Zugang aktivieren, eine Login-Shell einrichten und dort dann unter ~/.ssh/authorized_key den öffentlichen Schlüssel ablegen.
Was ich vor einigen Monaten mit meinem Raspberry Pi erfolgreich und innert kurzer Zeit hingebracht habe, wollte mich gestern während eineinhalb Stunden auf Trab halten. Neu wollte ich auch meinen persönlichen Account mit einem schlüsselbasierten SSH-Zugang ausstatten. Doch während der schlüsselbasierte Login mit dem Raspberry Pi-Konto problemlos funktionierte, wollte es mit dem privaten Konto einfach nicht klappen, obwohl die Konfiguration identisch war.
Lösung
Die nach unzähligen Pröbelversuchen eruierte Ursache: Das Home-Directory meines Benutzers war nicht mit den korrekten Berechtigungen versehen:
VAULT> ls -l /volume1/homes/ ... drwxrwxrwx 6 mario users 4096 Jan 26 10:42 mario ...
Nachdem ich folgenden Befehl ausgeführt hatte, klappte es plötzlich:
$ chmod 755 /volume1/homes/mario
Hierbei handelt es sich um eine im Grunde gut gemeinte Sicherheitsvorkehrung auf Unix-Systemen. Denn wenn andere Benutzer den Public Key eines anderen Benutzers ersetzen könnten, könnten sie sich anschliessen unter dessen Kontext einloggen.
Siehe auch der Beitrag SSH and home directory permissions auf Stackexchange.
Hintergründe
Ein grosses Problem dieser Synology-Box ist es, dass auf ihr ein abgespecktes Linux läuft, welches einerseits die gängigsten Debug-Optionen nicht zur Verfügung stellt (bspw. ein sauberes Logging der Aktivitäten von sshd), andererseits über eine schier unüberschaubare verschachtelte Konfiguration verfügt.
sshd_config
Insgesamt habe ich auf der Kiste drei sshd_config Konfigurationsdateien gefunden:
- /etc/ssh/sshd_config
- /etc.defaults/ssh/sshd_config
- /usr/syno/etc.defaults/ssh/sshd_config
Welche ist nun die richtige? Und welche bleibt auch bei einem Update oder Neustart mit meinen Konfigurationsanpassungen bestehen? Ich weiss es bis heute nicht.
sshd neu starten
Auch hierfür gibt es mehrere Möglichkeiten. Im Netz habe ich zwei Befehle gefunden:
- # killall sshd
- # /usr/syno/etc.defaults/rc.d/S95sshd.sh restart
Wenn ich diese Befehle ausgeführt habe, bin ich natürlich schnurstracks aus der SSH-Session geflogen — logisch. Doch bei der Verwendung von killall hat man sich soeben gerade vollständig vom NAS ausgesperrt.
Glücklicherweise gibt es über das Web-GUI des NAS die Möglichkeit, SSH wieder zu starten:
- Control Panel
- Terminal
- [x] Enable SSH service
Was ich zudem auch realisiert habe: Wenn ich SSH über das GUI neu starte, wird /etc/ssh/sshd_config neu eingelesen. Wenn ich es mit den Kommandozeilenbefehlen neu starte, wird die Konfigurationsdatei irgendwie nicht beachtet …
Verschachtelte Start-Scripts
Wie genau wird nun aber SSH gestartet? Die Synology-Ingenieure haben sich wohl gesagt: „Wieso einfach, wenn es auch kompliziert geht?“ und sich einige verschachtelte Scripts geleistet:
/usr/syno/etc.defaults/rc.d/S95sshd.sh liest einerseits /etc.defaults/rc.subr als auch /usr/syno/etc.defaults/rc.ssh.subr ein. Gestartet wird der SSH-Daemon dann aber, indem das Script /usr/syno/etc.defaults/rc.ssh aufgerufen wird. Dieses Script sourced das bereits erwähnte /usr/syno/etc.defaults/rc.ssh.subr erneut.
Konfigurationsdatei forcieren
Als mir das Debugging zu blöd wurde, habe ich mich entschieden, die Konfigurationsdatei ein für allemal in das eigentliche Startscript /usr/syno/etc.defaults/rc.ssh hartzukodieren:
... $SSHD -f /etc/ssh/sshd_config ...
Debugging in syslog? Fehlanzeige
Wer denkt, dass einem folgende Zeilen beim Debugging in /etc/ssh/sshd_config weiterhelfen, liegt falsch:
... SyslogFacility AUTH LogLevel DEBUG ...
In /var/log/messages, der einzigen von zwei Log-Dateien in diesem Verzeichnis, welche bisher am heutigen Tag aktualisiert wurden, finden sich keine weiterführenden Infos, wieso sich der Benutzer mario nicht Schlüsseln einloggen darf.
Ein Kommentar Kommentare
Ich wollte mir einen User einrichten, der nur dazu dient, dass ich mich mit ihm per SSH auf der Synology einloggen kann um dann dort per wakeonlan einen anderen Server im LAN aufzuwecken. Das Problem ist, dass nur als admins gesetzte user überhaupt SSH nutzen dürfen. Man kann das umgehen, indem man dem User eine andere shell zuweist. Dann muss man kein Admin sein. Trotzdem hat dieser User dann Zugang zu allen Verzeichnissen, wie ein Admin eben. Dies wollte ich per chroot verhindern. Da wäre jetzt die Frage welche Deiner drei angesprochenen Files nun die relevante für den SSH-Zugang ist und ob sie nicht überschrieben wird beim Update der DSM. :) Vielleicht hast DU ja eine Idee. Viele Grüße, Ben