Backup leicht gemacht: Lokale und entfernte Sicherung mit Dirvish, Rsync und SSH

An mehreren Stellen habe ich hier schon meine ganz persönlichen Backup-Methoden vorgestellt.

  1. Keep it simple
  2. Partimage
  3. Partclone
  4. The Debian Way
  5. Apt-Clone
  6. Live-CDs (z.B. Clonezilla)

Die Reihe könnte man noch eine Weile mit weiteren guten Alternativen fortführen. Oft kombiniere ich auch die ein oder andere Variante, wenn mir Daten besonders wichtig sind. In den vergangenen Wochen habe ich mir endlich Dirvish näher angeschaut, das Rsync und SSH miteinander verbindet und mir wieder einmal die Frage gestellt: “Warum eigentlich nicht früher?”. 🙂 Wer sowieso schon Rsync und SSH kennt, aber sich die vielen Kommandos nicht merken oder sogar Skripte dafür schreiben möchte, kann ganz einfach auf Dirvish zurückgreifen, das diese Probleme schon vor einer Dekade gelöst hat.
Interessant ist Dirvish nicht nur für alle, die gerne nach besonders effizienten Lösungen für die Konsole suchen, sondern es besticht vor allem durch die einfache Konfiguration und der Möglichkeit die Sicherung vollautomatisch per Cron-Job ablaufen zu lassen und kann auch ganz leicht manuell bedient werden.
Im Folgenden beschreibe ich die Sicherung eines Laptops und eines entfernten vServer mit Hilfe von Dirvish, Rsync und SSH. Dabei werden alle Daten auf eine handelsübliche USB-Festplatte gesichert, die an den Laptop angeschlossen ist.

Backup eines lokalen Rechners auf eine USB-Festplatte mit Dirvish

aptitude install dirvish
Nach der Installation von Dirvish, welches auch automatisch Rsync als Abhängigkeit mitinstalliert, könnt ihr mit der Dokumentation in /usr/share/doc/dirvish/HOWTO.Debian.gz und im dazugehörigen Beispiel-Ordner sofort loslegen. Für die gesamte Konfiguration sind lediglich zwei Dateien entscheidend.

master.conf

Die Datei master.conf wird nach /etc/dirvish/master.conf kopiert. Hierin werden alle globalen Einstellungen festgeschrieben.

  • bank: Gibt den Pfad zum Speicherort der Sicherung an. In meinem Fall existieren zwei Verzeichnisse auf einer externen USB-Festplatte, der ich zuvor mit
    tune2fs -L backup /dev/mapper/udisks-uuid-und-noch-mehr-Text
    einen kürzeren und leichter zu merkenden Namen gegeben habe. Wenn man schon dabei ist, kann man sie auch gleich mit luksformat vorher verschlüsseln.
  • exclude: Definiert die Verzeichnisse, die nicht gesichert werden sollen.
  • Runall: Die zuerst angegebenen Namen bezeichnen die sogenannen Schließfächer (vault), in denen die Daten gespeichert werden. Ein Schließfach ist nichts anderes als ein Unterverzeichnis, das man nach dem zu sichernden Dateisystem benennen sollte. Der Zeitstempel definiert nicht den Zeitpunkt der Ausführung, sondern dient lediglich als Bezugspunkt. Sollte das Backup z.B. aus welchen Gründen auch immer später ausgeführt werden, wird die Sicherung auf 22.00 Uhr zurückdatiert, damit die Logik intakt bleibt.
  • expire-default: Kann z.B. never oder +15 days sein und gibt an, wie lange einzelne Sicherungen standardmäßig vorgehalten werden sollen.
  • expire-rule: Wer den Aufbau der Datei crontab kennt, weiß sofort um was es geht. Die erste Zeile besagt, dass am ersten Tag der Woche, dem Montag, erstellte Backups für 3 Monate vorgehalten werden sollen. Man kann mit Hilfe dieser Syntax weitere beliebige Zeiträume und Zeitpunkte definieren.
bank:
	/media/backup/dirvish/laptop
	/media/backup/dirvish/server
exclude:
	lost+found/
	proc/
Runall:
	laptop-root	22:00
	laptop-home	22:00
	server-root	22:00
expire-default: +15 days
expire-rule:
#       MIN HR    DOM MON       DOW  STRFTIME_FMT
	*   *     *   *         1    +3 months
#	*   *     1-7 *         1    +1 year
#	*   *     1-7 1,4,7,10  1
#	*   10-20 *   *         *    +4 days
#	*   *     *   *         2-7  +15 days

Der Laptop

Erstellt nun die zweite Konfigurationsdatei für das Schließfach laptop-root. In diesem Beispiel wäre das
/media/backup/dirvish/laptop/laptop-root/dirvish/default.conf.
Default.conf ist immer richtig und für die meisten Anwendungsfälle vollkommen ausreichend. Es lassen sich aber noch zusätzliche Konfigurationen erstellen (Branch).

client: laptop
tree: /
xdev: 1
index: gzip
log: gzip
image-default: %Y%m%d
exclude:
        /var/cache/apt/archives/*.deb
        /var/cache/man/**
        /tmp/**
        /var/tmp/**
        *.bak
        /proc/**

Die Datei ist ähnlich wie die Datei master.conf aufgebaut. Wichtig sind hierbei vor allem:
client: In diesem Fall laptop. Wenn dieser Name dem Rechnernamen entspricht (hostname), erkennt Dirvish automatisch, dass es sich um ein lokales Backup handelt und verwendet kein SSH.
tree: Welches Verzeichnis gesichert werden soll. In diesem Fall das gesamte Wurzelverzeichnis.
xdev: Kann den Wert 1 oder 0 annehmen. 1 bedeutet, dass die Sicherung auf das angegebene Dateisystem beschränkt bleibt und Dirvish z.B. eingehängten Verzeichnissen nicht folgen wird. Hat man wie ich /home auf eine andere Partition installiert, würde dieses beim Wert 1 nicht gesichert werden. Hierzu muss also ein weiteres Schließfach mit einer neuen default.conf angelegt werden oder man setzt xdev hier auf 0.
Des Weiteren lässt sich der Zeitstempel für das Backup festlegen und Verzeichnisse von der Sicherung ausschließen. Diese Regel gilt zusätzlich zu den in der master.conf getroffenen Einstellungen.
Für das Schließfach “latop-home” müsst ihr noch einmal die Schritte gehen. Hier ändert sich nur der Wert der tree-Variable auf /home und ggf. die ausgeschlossenen Verzeichnisse.

Die erste Sicherung – Initialisieren

dirvish --vault laptop-root --init
dirvish --vault laptop-home --init
Am nächsten Tag könnt ihr dann mit
dirvish-runall
ein neues Backup erstellen, bei dem nur die geänderten Daten gesichert werden. Aufgrund der Verwendung von Hardlinks und der inkrementellen Natur der Datensicherung wird deswegen nur wenig Speicherplatz benötigt. Wird dieser doch einmal knapp, lässt sich mit
dirvish-expire
Platz schaffen, indem die in der master.conf definierten Regeln Anwendung finden.
Wer einen eigenen Heimserver betreibt, kann auch die Einstellungen in /etc/cron.d/dirvish beibehalten, die dafür sorgen, dass Dirvish automatisch um 04.22 Uhr ausgeführt wird. Wer den Rechner nicht 24/7 laufen lässt, sollte die Datei entfernen oder den Cron-Job auskommentieren.

Entfernte Sicherung eines vServers mit Hilfe von SSH

Wenn ihr bis hierher gefolgt seid, dann ist die Datensicherung eures vServers, auf die an euren Laptop angeschlossene USB-Festplatte, ein Kinderspiel.
Ihr benötigt dafür auf jeden Fall das Paket SSH, einen Account auf dem Server und SSH-Schlüssel. Weiterhin gehe ich davon aus, dass ihr wie im alten Beitrag beschrieben den Port des SSH-Servers geändert habt und Root sich nicht anmelden darf.
Diese Beschränkung heben wir nun wieder auf, da wir den kompletten vServer sichern wollen. Aber…Root darf nur ein einzelnes Kommando über SSH ausführen, den Rsync-Befehl, und sonst nichts.

Default.conf des Servers auf dem Backup-Rechner

client: server
rsh: ssh -p 44444 -i '/root/.ssh/id_rsa'
tree: /
xdev: 1
index: gzip
log: gzip
image-default: %Y%m%d
exclude:
        /var/cache/apt/archives/*.deb
        /var/cache/man/**
        /tmp/**
        /var/tmp/**
        *.bak

Der entscheidende Unterschied zu der lokalen Sicherung der Daten des Laptops ist der geänderte Wert für client: und die Variable rsh. Am besten tragt ihr in /etc/hosts einen Alias für eure Server-IP ein und nennt diesen dann schlicht server.
Der Wert für rsh (remote shell) ist der SSH-Befehl, um sich mit einem SSH-Server und dem SSH-Schlüssel zu verbinden, der auf einem Nicht-Standardport Anfragen entgegennimmt.

Auf dem Server

In der Datei /etc/ssh/sshd_config den Wert für PermitRootLogin auf forced-commands-only setzen.
Danach noch dem öffentlichen SSH-Schlüssel in /root/.ssh/authorized_keys eine Bedingung voranstellen, die erfüllt sein muss, damit sich Root anmelden darf. (vor ssh-rsa schreiben)

command="rsync --server --sender -vlHogDtprxe.iLsf --numeric-ids . /",from="10.0.0.5",no-port-forwarding,no-X11-forwarding,no-agent-forwarding 

Mit from= lässt sich sogar die IP-Adresse einschränken, von der sich Root anmelden darf. Der Befehl selbst lässt sich leicht mit htop auf dem Server herausfinden, wenn man ein Dirvish-Backup beobachtet oder man macht es wie Thor Dreier mit einem Hilfsskript, von dem auch dieser exzellente Dirvish-Tipp stammt. Sein Artikel aus dem Jahr 2005 ist auf jeden Fall empfehlenswert.

Fazit

Dirvish ist eine alte, aber noch lange nicht ergraute Lösung zum Sichern von Daten. Mit Hilfe auch gerne etwas älterer Hardware, habt ihr im Handumdrehen eine Backup-Lösung für alle Rechner zu Hause und für das Rechenzentrum in Schweden. 😉

Keychain: Alternative zu Gnome-Keyring um SSH-Schlüssel zwischen Logins zu verwalten


An Gnome ist nicht alles schlecht. Das merkt man spätestens dann, wenn man sich näher mit der Situation von Archivmanagern wie Squeeze oder Xarchiver befasst und diese File-Roller gegenüberstellt. Ähnlich verhält es sich mit Gnome-Keyring und Seahorse. Beide Anwendungen vereinfachen das Verwalten von Passwörtern, GPG- und SSH-Schlüsseln enorm.
Die Kehrseite der Medaille ist, bei einer reinen Fenstermanager-Lösung oder bei LXDE werden viele Gnome-Bibliotheken und Ballast mitinstalliert.
Ich habe bisher noch keine perfekte leichtgewichtige Lösung gefunden, die alle meine Wünsche erfüllt. Insbesondere ist das automatische Entsperren aller Schlüssel im Schlüsselring von Gnome eine große Erleichterung, die ich in dieser Form vielleicht noch bei KDE vermute. Ein leichtgewichtiges Pendant zu Seahorse und Co., das aktiv betreut wird – Fehlanzeige.

Keychain

Ich habe mich mal wieder im Wiki von Arch Linux umgesehen und diesen Eintrag zum Thema SSH-Keys gefunden. Schließlich habe ich mich dafür entschieden mir Keychain näher anzusehen, eine in Shell-Skript geschriebene Anwendung, die meinen Anforderungen am besten gerecht wird.
Bisher sah mein Umgang mit SSH-Schlüsseln so aus. Zuerst wurden sie mit ssh-keygen erzeugt und wie im Artikel zur Absicherung des SSH-Servers beschrieben, dann entweder mit Hilfe von Gnome-Keyring in meinem Schlüsselbund dauerhaft gespeichert oder auf der Konsole mit ssh-agent und ssh-add für die Dauer einer Sitzung entsperrt.
Der Vorteil von SSH-Schlüsseln ist, sie verbessern nicht nur die Sicherheit, sondern sie sind auch bequem zu benutzen. Einmal entsperrt und man kann sich bequem ohne Passworteingabe zu einem entfernten Rechner verbinden.
Keychains Vorteil gegenüber der manuellen Methode ist, dass automatisch beim Einloggen in den Terminal ssh-agent und ssh-add ausgeführt werden. Üblicherweise muss man nach jedem Ab- und Anmelden und Wechsel der Sitzung den SSH-Schlüssel erneut entsperren. Mit Keychain startet ein dauerhafter Prozess des ssh-agent, der für jede neue Sitzung wiederverwendet wird. Das heißt, einmal entsperrt lässt sich der Schlüssel bis zum nächsten Reboot ohne weitere Passworteingabe benutzen.

keychain --quiet id_pc1_rsa id_pc2_rsa
[ -z "$HOSTNAME" ] && HOSTNAME=`uname -n`
[ -f $HOME/.keychain/$HOSTNAME-sh ] &&
        . $HOME/.keychain/$HOSTNAME-sh
[ -f $HOME/.keychain/$HOSTNAME-sh-gpg ] &&
        . $HOME/.keychain/$HOSTNAME-sh-gpg

Dieser Code-Schnipsel wird entweder in der Datei ~/.bash_profile, oder wenn man ZSH benutzt in ~/.zshrc eingefügt. Keychain fügt automatisch die privaten SSH-Schlüssel id_pc1_rsa und id_pc2_rsa dem SSH-Agenten hinzu bzw. GnuPG-Agent, wenn dieser installiert sein sollte. Die Parameter für die laufende Sitzung werden standardmäßig in ~/.keychain/ gespeichert. Die Option –quiet sorgt noch dafür, dass nur Warnungen oder Fehlermeldungen ausgegeben werden, wenn man sich einloggt. Ansonsten würde eine ähnliche Meldung wie diese jedes Mal erscheinen.

* keychain 2.7.1 ~ http://www.funtoo.org
* Found existing ssh-agent: 2797
* Known ssh key: /home/apo/.ssh/id_pc1_rsa
* Known ssh key: /home/apo/.ssh/id_pc2_rsa

Fazit

Keychain ist eine leichtgewichtige Lösung um SSH-Schlüssel über Sitzungsgrenzen hinweg zu entsperren und bequem nutzen zu können. Auch für Cron-Jobs sicherlich eine nützliche Lösung. Das Handbuch man keychain ist empfehlenswert und informativ. Weitere Informationen gibt es wie immer in /usr/share/doc/keychain oder auf der Projektseite. Ich denke, der Gnome-Keyring und Seahorse sind weiterhin die bequemste Möglichkeit. Keychain ist für mich momentan jedoch ein sehr guter Ersatz auf einem leichtgewichtigen System.
Wie geht ihr mit dem Thema Passwörter und Schlüssel um?

SSH: Deaktivieren von StrictHostKeyChecking

Auf meinem Intel-Core-Duo-Rechner benutze ich verschiedene Betriebssysteme und betreibe ein Multiboot-System. Das hilft mir dabei Aufgaben und Software zu trennen, die ich nicht alle gemeinsam unter einem System installieren möchte.
Regelmäßig kommt es jedoch vor, dass ich mich per SSH von einem Laptop zu diesem Rechner verbinde oder Daten per scp austausche. Als vertrauenswürdiges Ziel habe ich dabei meine Debian-Testing-Installation mit Gnome 3 ausgewählt und den dortigen Host-Key zu meiner Datei ~/.ssh/known_hosts hinzugefügt.
Wechsele ich dann zu einem parallel installierten Betriebssystem, begrüßt mich diese Meldung hier.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!

Der SSH-Klient macht hier alles richtig und warnt mich davor, dass die Identifikation des Rechners sich nun geändert hat. Das hat mich bisher nie richtig gestört. Entweder habe ich die Datei .ssh/known_hosts gelöscht oder mich von einem anderen Laptop eingeloggt, der diese Installation als vertrauenswürdig eingestuft hat.
Man kann aber auch das sogenannte StrictHostKeyChecking deaktivieren, indem man sich eine entsprechende Konfiguration in ~/.ssh/config anlegt. Prinzipiell würde ich nie auf die Idee kommen dieses Sicherheitsfeature auszuhebeln, insbesondere dann nicht, wenn ich mich im Internet zu einem entfernten Rechner verbinde. Mein Laptop und der Core Duo stehen jedoch nur wenige Meter auseinander und werden dazu oft noch per Kabel verbunden. Von daher ist das Risiko eines Man-in-the-Middle-Angriffs überschaubar.

Meine Lösung sieht nun so aus:
Ich habe die Datei ~/.ssh/config mit folgendem Inhalt angelegt.

Host loki
         StrictHostKeyChecking no
         UserKnownHostFile /dev/null

Wenn ich nun ssh loki eingebe, wird SSH diesen speziellen Host weniger streng prüfen und ich kann mich problemlos zum selben Rechner verbinden, selbst wenn sich das Betriebssystem geändert hat.
Anstatt loki lässt sich auch 192.168.1.207 schreiben und mit der Wildcard * sogar jeder Rechner von der strengen Überprüfung ausnehmen, was ich aber nicht empfehlen kann.
Eine weitere Möglichkeit bietet der Alias-Befehl.  z.B.

alias insecssh='ssh -o "StrictHostKeyChecking=no" -o "UserKnownHostsFile=/dev/null"


Mit insecssh loki könnte man sich danach auch ohne Anlegen einer config-Datei zum entfernten Rechner verbinden.
Für die eigenen vier Wände ist das erst einmal ausreichend. 😉
Changelog:
01.09.2012 Alias insecssh der GRML-Konfiguration hinzugefügt.

SSH-Schlüssel, Port ändern und Anmeldung als Root verwehren

Nachdem mir meine Zugangsdaten zum vServer übergeben worden waren, war meine erste Aktion mit dem neuen SpielArbeitsgerät den SSH-Zugang abzusichern. Die folgende Anleitung zeigt in Kürze, wie man verhindert, dass Root sich per SSH anmelden darf, SSH auf einem anderen Port lauscht und eine Anmeldung nur noch mit einem gültigen SSH-Schlüssel möglich ist und das Einloggen per Passworteingabe deaktiviert wird.
Diese Prozedur ist bei jedem öffentlich zugänglichen Server sinnvoll, wie ein Vorfall letzte Woche wieder einmal gezeigt hat. In einer größeren Institution wurde ein Server kompromittiert, bei dem sich der Angreifer mit Hilfe einer Wörterbuch-Attacke direkt Rootzugriff über SSH verschaffen konnte, indem er innerhalb weniger Stunden ca. 40.000 Passwörter ausprobieren durfte. Software wie denyhosts, fail2ban oder eine Firewalleinstellung, die nur Zugriff aus “vertrauenswürdigen” Netzen erlaubt und natürlich ein stärkeres Passwort, wäre hier eine Möglichkeit gewesen den Einbruch zu verhindern.
Mein kleines Projekt bietet mir die einfache Möglichkeit auf noch mehr Sicherheit, da außer mir selbst niemand Shellzugriff benötigt und nichts dagegen spricht den berechenbaren Namen des Root-Zugangs zu deaktivieren und nur noch die Authentifizierung per SSH-Public-Key-Verfahren zu erlauben. Bevor das geschieht, muss man natürlich einen weiteren, unprivilegierten Benutzer mit adduser hinzufügen.

Schlüsselerzeugung

ssh-keygen

Ohne weitere Argumente erstellt dieser Befehl einen privaten und öffentlichen RSA-Schlüssel für die SSH-Protokollversion 2 auf dem lokalen Rechner. Bejaht man alle folgenden Fragen, wird das Schlüsselpaar in ~/.ssh/ gespeichert. Ebenso wird man nach einem Passwort gefragt, um den privaten Schlüssel später entsperren zu können. Ich empfehle eines zu setzen, auch wenn man dadurch einmal pro Sitzung das Passwort eingeben muss.

Öffentlichen Schlüssel auf den Server transferieren

ssh-copy-id user@euervps123.de

Der öffentliche RSA-Schlüssel befindet sich danach auf eurem Server in ~/.ssh.

Einloggen

Funktioniert wie bisher,

ssh user@euervps123.de

nur dass ihr jetzt das Passwort zum Entsperren des privaten Schlüssels auf eurem Rechner eingeben müsst. Die Rechte der privaten Schlüsseldatei id_rsa müssen restriktiv sein.

chmod 600 ~/.ssh/id_rsa

Schlüssel ohne Eingabe des Passworts benutzen

Unter Gnome 3 genügte bei mir

ssh-add

auszuführen, um den privaten Schlüssel dem Authentifizierungsagenten, ssh-agent, hinzuzufügen, der hier durch die Anwendung gnome-keyring bereitgestellt wird. Nach einmaliger Eingabe des Passwortschutzes für den privaten Schlüssel ist dieser die gesamte Sitzung ohne weitere Passwortabfrage benutzbar.
Arbeitet ihr ohne X auf der Konsole müsst ihr zuerst den

ssh-agent zsh


mit eurer bevorzugten Shell aufrufen und könnt danach den privaten Schlüssel wieder wie oben beschrieben mit ssh-add für die Sitzung dauerhaft entsperren.

Root-Zugang deaktivieren, Port verändern und Passwort-Authentifizierung abschalten

Hierzu muss die Datei /etc/ssh/sshd_config auf dem Server angepasst werden.
Wichtig! Bevor ihr die Veränderung vornehmt, solltet ihr absolut sicher sein, dass ihr euch mit dem neu generierten Schlüssel anmelden könnt. Ebenso müsst ihr unbedingt die Einstellungen der Firewall so anpassen, dass ein Anmelden über den neuen SSH-Port erlaubt ist. (siehe nächster Beitrag).
Folgende Optionen werden geändert:

Port 44443
PermitRootLogin no
RSAAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication no
X11Forwarding no

Fazit

Der Port kann im Prinzip beliebig gewählt werden. Die Liste der standardisierten Ports hilft bei der Entscheidung. Der Wechsel von Port 22 auf z.B. Port 44443 lässt die Mehrzahl automatischer Programme ins Leere laufen, die nur überprüfen, ob auf dem Standardport ein SSH-Dienst angeboten wird. Anmelden kann man sich ab sofort mit

ssh -p 44443 user@euervps123.de


Das Abschalten der Passwort-Authentifizierung macht Wörterbuch-Attacken aussichtslos. Das Deaktivieren des Root-Logins erzwingt die Anmeldung mit einem unprivilegierten Benutzer, so dass ein Angreifer nicht nur die Hürde des SSH-Schlüssels überwinden, sondern noch ein weiteres Passwort in Erfahrung bringen muss.
Sicherheit ist ein Prozess, heißt es so schön. Für mein spezielles Benutzerszenario funktioniert dieser Weg. Fehlerhaft konfigurierte Dienste und Sicherheitslücken kann aber auch diese Anleitung nicht verhindern.

Links

https://help.ubuntu.com/community/SSH/OpenSSH/Configuring
http://bodhizazen.net/Tutorials/SSH_keys
Sicherer Datentausch: Ein sftp-Server mit chroot

NFS-Dateiserver mit Slitaz

Im Hintergrund wird fleißig an Slitaz 4.0 gewerkelt und vielleicht gerade weil die letzte Cooking-Version vom Mai letzten Jahres stammt, gibt es trotzdem noch ein paar gute Gründe mit der aktuellen stabilen Ausgabe einige Aufgaben zu lösen. Ich habe mich etwas umgesehen und einen NFS-Server mit Slitaz 3.0 eingerichtet, mit dem ich Dateien zwischen den Clients im lokalen Netzwerk, sprich dieser kleinen Hardwaresammlung hier, austauschen kann.
Damit es halbwegs spannend wurde, habe ich den Toshiba Satellite 220CS zum NFS-Server umfunktioniert. Klingt beim ersten Lesen dramatischer als es ist, zum Schluss musste ich nur zwei Pakete installieren und ein Paar Textdateien bearbeiten.

Secure Shell – SSH

Beim lokalen Datenaustausch kommt bei mir im Regelfall immer SSH zum Einsatz und auch für einen sftp-Server finde ich ab und an Verwendung. Wenn ich Zugriff per SSH häufiger benötige, setze ich auch sshfs ein, wodurch sich entfernte Dateisysteme genauso problemlos wie Festplatten oder USB-Sticks einbinden lassen.
Die Secure Shell stellt bei älteren Rechnern eine wahrnehmbare Anforderung an CPU und Arbeitsspeicher, was außer für den Satellite 220CS bisher aber noch kein wirkliches Problem war. Erst bei einem Pentium I mit 16 MB RAM halte ich es für sinnvoll von OpenSSH zu Dropbear zu wechseln, weil man hier die bessere Performance tatsächlich spüren kann.

Network File System – NFS

Benötigt man hingegen keinen vollständigen Zugriff auf einen Rechner, lässt sich auch sehr gut mit dem Network File System leben, das nur geringe Anforderungen an die Hardware stellt. In Slitaz stabilen Repositorien existiert nur das Paket unfs3, welches den NFS-Server für den User Space mit der älteren Version 3 des Protokolls anbietet. Bei Debian hat sich hier seit längerem schon der nfs-kernel-server durchgesetzt, der zuverlässiger und schneller funktionieren soll. Unfs3 hingegen wurde 2010 aus Testing entfernt.
Er wird scheinbar auch nicht mehr weiterentwickelt. Das letzte Update auf sourceforge stammt aus 2009, dennoch eignet sich die Slitaz-Version noch für ein privates Heimnetzwerk mit einer überschaubaren Anzahl von Rechnern, denen man vertrauen kann. Die Installation ist denkbar einfach:

Installation

tazpkg get-install unfs3


Gleichzeitig wird portmap als Abhängigkeit mitinstalliert.

Konfiguration

Damit der NFS-Server beim Booten schon gestartet wird, muss die Datei /etc/rcS.conf editiert werden und in der Zeile RUN_DAEMONS noch die Dienste portmap und unfsd hinzugefügt werden. Meine Einstellungen sehen so aus.

RUN_DAEMONS=”dropbear portmap unfsd “

Der NFS Server lässt sich auch manuell mit
/etc/init.d/unfsd start
starten.
Schließlich werden die Pfade zu den Ordnern, die man freigeben möchte, in /etc/exports eingetragen und dort die entsprechenden Zugriffsrechte gesetzt.

#/home/tux/musik nur lesend für jeden Rechner freigeben
/home/tux/musik     (ro)

#/home/tux/downloads lesend und schreibend freigeben
/home/tux/downloads     (rw)

#/home/tux nur lesend für den Rechner 192.168.0.207 freigeben
/home/tux/     192.168.0.207(ro)

Die weiteren Optionen für die Freigabe werden gut im Artikel NFS im Wiki von ubuntuusers.de beschrieben. Um nicht in jeder Konfigurationsdatei mit einer statischen IP-Adresse zu hantieren, lohnt es sich auch einmalig in /etc/hosts einen Rechnernamen für eine IP festzulegen und nur noch mit diesem Namen zukünftig zu arbeiten. Ändert sich aus irgendwelchen Gründen die IP, muss sie nur noch in /etc/hosts geändert werden.

Zugriff als Client

Auf Debian basierenden Systemen lässt sich eine Freigabe mit folgendem Befehl manuell in ~/nfs einhängen, wenn der Server mit der IP 192.168.0.100 erreichbar ist. Zuvor muss das Paket nfs-common installiert worden sein.
mount 192.168.0.100:/home/tux/musik ~/nfs
Wer gerne automatisch diese Freigabe einbinden möchte, kann dies in der /etc/fstab festlegen. Über nützliche Optionen hierzu, gibt das ubuntuusers.de Wiki ebenfalls Aufschluss.
Mit

showmount -e 192.168.0.100

erhält man als root auch die Liste der Freigaben des Servers.

Fazit

NFS ist selbst auf dem 16 Jahre alten Laptop noch performant genug, um Musikdateien über das Netzwerk verzugslos abspielen zu können. Einen NFS-Server für den Hausgebrauch einzurichten ist gar nicht so schwierig. Fortgeschrittene Optionen wie Kerberos-Unterstützung wird man hier kaum brauchen. Gerade für ein homogenes Netzwerk, in dem UNIX/Linux Rechner zum Einsatz kommen, lohnt sich NFS als unkomplizierte Möglichkeit zur Dateifreigabe.

Eine weitere simple Backup-Methode: Partclone, TinyCore und sshfs

Ein Backup zu machen ist das A und O. Ein Satz, den man regelmäßig liest und dem man auch zustimmen kann, nur um es dann doch auf die lange Bank zu schieben bis es schließlich zu spät ist. So etwas nennt man dann PP, Persönliches Pech. 😮
Die Auswahl für ein Backup reicht von Keep it simple, über “The Debian Way” bis hin zu einer kompletten Linuxdistribution, die Festplatten und Partitionen klonen und wiederherstellen kann.
Auf etwas älteren Laptops wie dem Thinkpad 600 funktioniert für mich auch die Partimage-Methode, indem ich von meinem Debian Stable aus eine weitere Partition sichere und bei Bedarf wieder einspiele.
Trotzdem ich freundlicherweise sogar Bilder zur Verfügung gestellt bekommen habe, wie man mit Hilfe von Clonezilla selbst mit nur 128 MB RAM ein vollständiges Festplattenbackup machen kann, hat dies bei mir leider noch nicht hingehauen.
Da es aber keine Rolle spielt, welche Linuxdistribution man benutzt, sondern nur, DASS es funktioniert, bin ich ziemlich glücklich, dass ich mit TinyCore nun die Möglichkeit habe ein vollständiges Backup durchzuführen.
Dazu muss man lediglich noch die Erweiterungen partclone.tcz und sshfs-fuse.tcz installieren. Partclone bietet gegenüber Partimage den Vorteil mehr Dateisysteme sichern zu können, darunter auch ext4 und btrfs.
Mit Hilfe von SSH lässt sich ein entferntes Dateisystem auf einem anderen Rechner einhängen und das Backup direkt an diesen Computer übertragen. Bei TinyCore muss man entweder die Rechte für den Standardnutzer tc konfigurieren oder mit sudo su als root die folgenden Kommandos ausführen.

Mit dem entfernten Rechner verbinden

mkdir /home/tc/backup
sshfs user@192.168.0.201:/home/user /home/tc/backup

Partition mit Partclone sichern

partclone.extfs -c -d -s /dev/sda2 -o /home/tc/backup/20111205_hal600_sda2.img

Partition mit Partclone wiederherstellen

partclone.restore -d -s /home/tc/backup/20111205_hal600_sda2.img -o /dev/sda2

MBR mit dd sichern

dd if=/dev/sda bs=512 count=1 of=/home/tc/backup/20111205_hal600_mbr.img



Mit den oben genannten Beispielen habe ich sowohl die zweite Partition der Thinkpad 600 Festplatte als auch den MBR und die Partitionstabelle gesichert und mit Hilfe des SSH-Dateisystems an einen entfernten Rechner übertragen. Je nach Interesse lassen sich mit TinyCore noch eine ganze Reihe anderer Möglichkeiten mit älterer Hardware verwirklichen.

Sicherer Datentausch: Ein sftp-Server mit chroot

Vor zwei Jahren wollte ich mehrere 100 MB an Fotos mit ein paar Freunden teilen, die sich nach einem gemeinsamen Urlaub angesammelt hatten. Damals waren Dropbox und ähnliche Dienste noch nicht ganz so präsent wie heute. Außerdem war es eine gute Gelegenheit mehr über FTP- und SSH-Server zu lernen und manch bekennenden Windowsnutzer ordentlich zu verwirren: “Ja, du musst ssh benutzen. Es gibt keine andere Möglichkeit um an die Fotos zu gelangen.” haha 😈
Zu dieser Zeit sollte es unbedingt ein sftp-Server sein, da ich für viele andere Aufgaben sowieso schon ssh einsetzte. Damit spart man sich das Einrichten eines zusätzlichen ftp-Servers und erhält gleichzeitig noch eine sichere Methode zum Datenaustausch dazu.
Die folgende Anleitung beschreibt die Einrichtung eines ssh-Servers, der für eine Gruppe von Benutzern nur als sftp-Server zugänglich sein soll. Alle User werden dabei in einer chroot-Umgebung eingesperrt und Shell-Zugriff verwehrt um die Sicherheit auf dem Server zu erhöhen. Als Beispiel dient mir der Benutzer mika und die Gruppe freunde. Das HowTo sollte mit jeder auf Debian basierenden Distribution funktionieren und sich mit jeder anderen nachvollziehen lassen.

Installation

aptitude install ssh

Anlegen der für sftp berechtigten Nutzer und der Gruppe freunde

adduser mika
addgroup freunde
adduser mika freunde

Absichern des Chroot Verzeichnisses

chown root.root /home/mika

Mikas Heimverzeichnis sollte im Besitz von root sein, damit er effektiv darin eingesperrt ist und er standardmäßig keine Dateien auf dem Server hochladen kann. Da aber ein Datenaustausch auch manchmal in umgekehrter Richtung sinnvoll sein kann, genügt es, einen Ordner wie upload in diesem Verzeichnis zu erstellen und ihn Mika mit

chown mika.mika /home/mika/upload

zu überantworten.

Konfiguration von /etc/ssh/sshd_config

Notwendige Sicherheitsvorkehrungen

    • Port 42123

Der Standardport für SSH ist 22. Mit dieser Variablen lässt sich der Listen Port z.B. auf 42123 für den Server ändern. Das macht den Server zwar kein bisschen sicherer (security through obscurity), hilft aber unter Umständen die Existenz des ssh-Servers zu verschleiern.

    • PermitRootLogin no

Wenn ein Angreifer root werden möchte, muss er mit dieser Einstellung mindestens noch das Passwort eines weiteren Users auf dem Server kennen.

    • PermitEmptyPasswords no

SSH-Nutzer ohne Passwort sind natürlich ein Unding. Obwohl ich mir gut vorstellen kann, dass man das als eine weitere Möglichkeit zu “Was man mit alten Computern machen kann” hinzufügen könnte. Anstatt selbst zu lernen wie man in den eigenen alten Rechner einbricht, könnte man das doch auch andere tun lassen… 😉

    • Subsystem sftp internal-sftp

Das aktiviert sshds internen sftp-Service. Normalerweise verweist Subsystem sftp auf eine ausführbare Binärdatei wie z.B. /usr/lib/openssh/sftp-server. Diese muss durch den internen Dienst ersetzt werden.
Am Ende der /etc/ssh/sshd_config sollte dann folgender Match-Eintrag hinzugefügt werden.

Match group freunde
      ChrootDirectory /home/%u
      X11Forwarding no
      AllowTcpForwarding no
      ForceCommand internal-sftp

Der Match-Block gilt nur für die Gruppe freunde und jeden Nutzer, der sich darin befindet. Mika kann sich deswegen nur per sftp mit dem Server verbinden und landet danach im festgelegten Chroot-Verzeichnis. Der Shell Zugriff mit ssh wird effektiv unterbunden. Das Chroot muss nicht zwangsläufig mit Mikas Homeverzeichnis übereinstimmen und kann beliebig gewählt werden. Der Parameter %u wird durch den eingeloggten Nutzer ersetzt.

Der erste Test

Jetzt ist es an der Zeit den OpenSSH-Server neuzustarten. Als SFTP-Klienten eignen sich später z.B. das Firefox Addon Fireftp, Filezilla, WinSCP für Windows oder ganz einfach das Kommandozeilenprogramm sftp.

/etc/init.d/ssh restart

Danach sollte der sftp-Zugriff für Mika am Beispielrechner 192.168.0.200 funktionieren.

sftp -P 42123 mika@192.168.0.200

und der ssh-Zugriff verwehrt werden

ssh -p 42123 mika@192.168.0.200

DynDNS.org

Es ist zwar schön, dass der Server nun in unserem internen Netzwerk funktioniert, aber irgendwie müssen die Freunde von außerhalb darauf zugreifen können. Die meisten werden sicherlich eine dynamische IP vom Provider zugewiesen bekommen, weshalb es Sinn macht einen kostenlosen DNS-Dienst wie z.B. dyndns.org zu benutzen, um eine leicht zu merkende URL wie z.B. 4freunde.dyndns.org zu erhalten.
Nachdem man sich bei dyndns.org angemeldet hat, muss man dem Dienst auf irgendeine Art noch mitteilen wie die aktuelle IP-Adresse des Heimservers lautet. Dazu bietet sich z.B. ddclient an. Bei der Installation wird man nach Login und Passwort bei dyndns.org gefragt und kann ansonsten die Standardeinstellungen verwenden.
Sollte man eine Firewall einsetzen oder wie ich einen Router mit eingebauter Firewall haben, dann muss nur noch der SSH-Dienst mit Hilfe von PortForwarding an den Zielserver und Port 42123 weitergeleitet werden. Danach kann sich dann Mika von überall auf der Welt mit

sftp -P 42123 mika@4freunde.dyndns.org

auf dem Heimserver einloggen.

Last but not least – Denyhosts

Wenn man seinen Server eine Weile laufen lässt und spaßeshalber mal die Datei /var/log/auth.log öffnet, fallen einem die regen Zugriffsversuche auf…die allesamt nicht von den Freunden stammen. Willkommen im Internet! John Doh und Nihao versuchen mit Brute-Force-Attacken in den ssh-Server einzubrechen. Eine wirksame Methode das zu unterbinden ist z.B. denyhosts oder noch besser gleich den SSH-Port ändern und auf SSH-Schlüssel umstellen.
Bei Debian konnte ich nach der Installation mit den Voreinstellungen sehr gut leben. Die Datei /etc/denyhosts.conf ist aber hervorragend kommentiert und lässt sich leicht an die eigenen Wünsche anpassen. Das Programm registriert fehlgeschlagene Logins und setzt die IP Adresse des Angreifers nach einer festgelegten Anzahl von Versuchen in die Datei /etc/hosts.deny, womit jeder weitere Loginversuch verwehrt wird. Es gibt noch viele weitere Möglichkeiten einen Mißbrauch zu verhindern. Ich fand damals diesen Heise-Artikel zum Thema sehr lesenswert. Wenn man sehr restriktiv ist und vielleicht sogar die IP-Adresse der Freunde kennt, kann man auch alle Zugriffe mit Hilfe von /etc/hosts.allow und /etc/hosts.deny verbieten und nur ausgewählte IPs erlauben.
SSH ist ein ausgesprochen vielseitiges und nützliches Werkzeug. Als Beweis, dass ich nicht der Einzige bin, der positive Erfahrungen mit ssh gemacht hat, hier mal ein Link zu keros Artikel “sperr mich ein baby“.

Meine Quellen

SSH der unverzichtbare Alleskönner

Ich wollte schon länger etwas zu SSH schreiben, denn im Grunde genommen gehört es zu den von mir am meisten benutzten Anwendungen mit Linux. Der OpenSSH- oder Dropbear- Server ist auf jedem meiner Rechner installiert und seit längerer Zeit nutze ich die Secure Shell nicht nur zur Administration des heimischen Rechenzentrums, sondern auch zum Kopieren von Dateien und Mounten entfernter Dateisysteme.
Zu SSH gibt es glücklicherweise schon mehr als genug Informationen im Internet, weswegen ich nicht allzu viel Worte darüber verlieren möchte. Vor einiger Zeit bin ich zufällig schon auf einen Blogeintrag gestoßen, der mir die ganze Arbeit abgenommen hat und den ich wegen seiner übersichtlichen und verständlichen Vorstellung interessanter SSH-Befehle gerne weiterempfehlen möchte.
Der Post heißt “6 nützliche Dinge, die man mit ssh tun kann” und findet sich auf daniel-ritter.de.
Ich denke jeder, der Linux eine längere Zeit benutzt, wird mir zustimmen, dass SSH ein echtes Allroundtalent ist. Insbesondere kann ich mir mit SSH den Overhead eines Samba- oder NFS-Servers sparen. Das scp-Kommando lässt sich genauso wie cp einsetzen um Daten verschlüsselt zwischen zwei Rechnern auszutauschen.
Als Ergänzung eignet sich besonders bei Debian und Ubuntu sshfs , mit dem sich ein entferntes Dateisystem verschlüsselt einhängen lässt. Man sollte nur darauf achten, dass man nach der Installation des Pakets mit dem Benutzer in der Gruppe fuse vertreten ist. Das Einbinden des Dateisystems ist dann genauso einfach wie das Einloggen am SSH-Server.
Zusätzlich hat Daniel noch den SSH-Tunnel und SSH als Socks-Server vorgestellt, mit dem auch in unsicheren Netzen eine sichere Verbindung zu einem Rechner des Vertrauens hergestellt werden kann und mit diesem sich dann z.B. im Internet surfen lässt.
Außerdem gibt es noch die Möglichkeit die Darstellung von X11-Anwendungen auf einem entfernten Rechner an den lokalen Computer weiterzureichen. Hierzu verbindet man sich mit der Option -X mit dem entfernten Rechner und zusätzlich muss X11Forwarding “yes” in /etc/ssh/sshd_config gesetzt sein.
Schließlich existiert sogar noch die Möglichkeit einen sftp-Server als Subsystem von SSH laufen zu lassen, womit man sich auch das Einrichten eines zusätzlichen FTP-Servers sparen kann. Dazu bald mehr.
Wer SSH noch nicht ins Herz geschlossen hat, sollte jetzt damit anfangen. Es lohnt sich. 😉