Posts Tagged ‘Synology’

Sonntag, 26. Januar 2014

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

Link zu diesem Artikel

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

Link zu diesem Artikel

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

Mittwoch, 18. September 2013

Den Raspberry Pi mit rsync über SSH auf die Synology DiskStation sichern

Link zu diesem Artikel

Als Gedankenstütze nachfolgend einige Lösungen für Probleme, die sich mir in den Weg stellten:

Mac OS X

$ ssh-keygen -t rsa -b 2048 -f id_rsa_dashboard_vault

Die Aufforderung, ein Passwort für den Private Key zu generieren, bestätigt man mit ENTER — der Private Key wird so nicht zusätzlich mit einem Passwort geschützt, weil dies den automatisierten Login von Raspberry Pi auf die DiskStation verhindern würde.

Der Befehl erstellt zwei Dateien:

  • id_rsa_dashboard_vault
  • id_rsa_dashboard_vault.pub

Synology DiskStation

Als erstes richtet man sich über die Web-Oberfläche einen normalen Benutzer dashboard ein, in dessen Home-Verzeichnis die Backup-Daten geschrieben werden.

Hierzu müssen dem Benutzer Schreibrechte auf /homes gegeben werden. Ansonsten sieht man sich beim Starten des Backup-Scripts (s. unten) mit folgender Fehlermeldung gegenüber:

ERROR: module is read only

Quelle: Rsync over ssh: “ERROR: module is read only” suddenly appeared

Wichtig ist weiter, dass der SSH-Zugang über die Web-Oberfläche aktiviert wurde.

/etc/passwd

Dem neu erstellten Benutzer müssen wir nun eine gültige Login-Shell zuweisen:

...
dashboard:x:1029:100::/var/services/homes/dashboard:/bin/ash

Erfasst man hier ein nicht existierendes Login-Shell, kriegt man beim Debugging des publickey SSH-Logins folgende komische Infos ans Gesicht geworfen:

...
Authentication succeeded
...
Permission denied
...

Um sicher zu gehen, dass die Login-Shell richtig konfiguriert ist, macht man als auf der DiskStation eingeloggter User root folgendes:

# su dashboard

Wechselt man in ein neues Shell, ist /etc/passwd korrekt konfiguriert.

/var/services/homes/dashboard/.ssh/authorized_keys

In dieser Datei legen wir den Public Key ab (id_rsa_dashboard_vault.pub).

/etc/ssh/sshd_config

Wahrscheinlich müsste man hier gar nichts anpassen, beim Debugging habe ich es dann doch getan (wohl unnötigerweise):

$ cat sshd_config | grep -v "^#" | sort
AllowTcpForwarding no
AuthorizedKeysFile	.ssh/authorized_keys
ChallengeResponseAuthentication no
ChrootDirectory none
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_rsa_key
LogLevel INFO
Match User root
    AllowTcpForwarding yes
Protocol 2
PubkeyAuthentication yes
Subsystem       sftp    internal-sftp -f DAEMON -u 000
SyslogFacility AUTH
UseDNS no
UsePAM yes

Raspberry Pi

/root/.ssh/config

Host vault
   Hostname 10.0.44.44
   User dashboard
   IdentityFile ~/.ssh/id_rsa_dashboard_vault

In der Datei ~/.ssh/id_rsa_dashboard_vault legt man den Private Key ab.

Login überprüfen

Dies sollte nun ohne Eingabe eines Passwortes möglich sein:

$ ssh vault

Bei einer Fehlermeldung helfen die Optionen -v, -vv und -vvv weiter:

$ ssh -v vault

/usr/local/bin/backup.sh

Folgendes Script sichert / (root) des Raspberry Pis auf den Host vault in den Pfad /volume1/homes/dashboard/backups/. Auf dem Raspberry Pi nicht mehr vorhandene Dateien werden auf der DiskStation gelöscht.

#!/bin/sh

RSYNC=`which rsync`

if [ ! -e "$RSYNC" ]
then
	echo "rsync binary not found: '$RSYNC'"
	exit 1
fi

TODAY=`date +"%F_%T"`
SNAPSHOTFILE="/var/log/rsync/$TODAY.snapshot.txt"
#touch "$SNAPSHOTFILE"
echo "$TODAY" > "$SNAPSHOTFILE"

if [ ! -f "$SNAPSHOTFILE" ]
then
	echo "Could not create snapshotfile '$SNAPSHOTFILE'"
else
	echo "Snapshotfile created at:"
	ls -l "$SNAPSHOTFILE"
fi

LOGFILE="/var/log/rsync/$TODAY.log.txt"
EXCLUDEFILE="/usr/local/bin/backup-exclude.txt"

SOURCE="/"
DEST="vault:/volume1/homes/dashboard/backups/"

echo "Running rsync ..."
$RSYNC -avz --log-file="$LOGFILE" --exclude-from="$EXCLUDEFILE" --delete -e ssh "$SOURCE" "$DEST" 
echo "Backup complete."

exit 0

/usr/local/bin/backup-exclude.txt

proc/*
sys/*
dev/*
tmp/*
run/*
mnt/*

Quelle: Can a Raspberry Pi be used to create a backup of itself?

/etc/crontab

...
4 0 * * *	root	/usr/local/bin/backup.sh

Hiermit wird das Backup-Script täglich um 4 Uhr morgens ausgeführt.

Links

Tags: , , , ,
Labels: Linux

1 Kommentar | neuen Kommentar verfassen

Newer Entries »