Posts Tagged ‘NAS’

Samstag, 13. September 2025

Synology NAS: TOTP-Code wird nicht (mehr) akzeptiert

Vorletzte Nacht wollte ich mich seit Langem wieder einmal in mein Synology NAS einloggen.

Das Administrator-Konto habe ich mit einem Time-based One-Time Password (TOTP) geschützt.

Leider wurde der von 1Password gelieferte Code irgendwie nicht akzeptiert. Die Fehlermeldung habe ich mir leider nicht notiert, doch eine Google-Suche leitete mich zu folgendem Artikel:

Why is my mobile device’s time different from my Synology NAS?

Zum Glück hatte ich auf dem NAS den Zugang zu einem Mail-Server konfiguriert und dem Administratorenkonto eine Email-Adresse hinterlegt. Deshalb wurde mir auf dem Login-Screen neben der Fehlermeldung die Möglichkeit angeboten, einen Einmal-Code emailen zu lassen. Das tat ich auch, und konnte mich mit dem Code einloggen.

In den Benutzerkonto-Einstellungen starte ich dann den Versuch, die Zwei-Faktor-Authentifizierung zu deaktivieren, und erneut einzurichten.

1Password auf meinem Mac erkannte den QR-Code leider nicht (das Problem besteht seit dem Upgrade auf 1Password 8, und auf macOS Sequoia: höchst enttäuschend, so ein nützliches Feature!), weshalb ich kurzerhand 1Password auf meinem iPhone verwendete. Die Kamera erkannte den QR-Code und fügte den Seed dem Login-Eintrag hinzu. Doch als ich den Code zur Bestätigung in das dafür vorgesehene Formular eintrug und absendete, erhielt ich folgende Fehlermeldung:

Code authentication failed. Please make sure the verification code you entered is correct or try synchronizing the system time of your mobile device and DSM. Refer to this article for details.

Was zum Teufel?!

Doch der aufmerksame Leser wird die Antwort vermuten: Für einmal war die Fehlermeldung wirklich hilfreich, und akkurat: Die Zeit des NAS ging eine halbe bis eine Minute hinter der tatsächlichen Uhrzeit nach. Für TOTP „tödlich“.

Dies sieht man im Control Panel unter Regional Options. Dort gibt es auch die Möglichkeit, einen NTP-Server zu erfassen. Der war in meinem Fall tatsächlich erfasst und lautete auf time.google.com — doch im Status-Feld unterhalt stand nicht „Normal“ in grüner Schrift.

Ich erfasste deshalb die IP eines lokalen Linux-Servers, auf welchem NTP läuft, speicherte die Einstellungen, und forcierte die Aktualisierung der Uhrzeit. Danach klappte das generieren und verifizieren des TOTP-Codes problemlos.

Gleich anschliessend passte ich die NTP-Einstellungen auf allen Synology NAS in meinem Fuhrpark an, um dieses Problem künftig zu vermeiden. Jetzt muss ich einfach nur sicherstellen, dass die lokalen NTP-Server stetig funktionieren.

Tags: , , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 26. Januar 2014

Das Mac OS X Home-Verzeichnis mit rsync über SSH auf eine Synology Diskstation sichern

Nachdem ich den schlüsselbasierten Login hingekriegt hatte, stand ich bereits wieder vor dem nächsten Problem: Mein rsync-Script zur Sicherung meines Mac OS X Home-Verzeichnis in einen Unterordner auf meinem Home-Verzeichnis auf dem Synology NAS brach mit folgender Fehlermeldung ab:

...
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
ERROR: module is read only
...

Wieso denn das? Mit dem Synology-Konto meines Raspberry Pi klappt die ganze Chose problemlos!

Mit den Hinweisen unter Rsync over ssh: “ERROR: module is read only” suddenly appeared wurde ich auf den richtigen Pfad gelenkt: Ich musste meinem Benutzer mittels des Synology Web-GUIs Schreibrechte auf den Homes-Ordner geben:

  1. Control Panel
  2. Users
  3. %BENUTZER% auswählen
  4. Edit
  5. Privileges Setup
  6. homes
  7. [x] Read/Write
  8. OK

Seither klappt die rsync-Synchronisierung. Ob ich aber damit eine Sicherheitslücke geöffnet habe?

Tags: , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 26. Januar 2014

Sich schlüsselbasiert per SSH auf einer Synology Diskstation einloggen

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:

  1. Control Panel
  2. Terminal
  3. [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.

Tags: , , , , , , , , , ,
Labels: Linux

1 Kommentar | neuen Kommentar verfassen