Remote Verzeichnisse mit SSHFS auf Debian Squeeze einhängen

Remote Verzeichnisse mit SSHFS auf Debian Squeeze einhängen

Version 1.0

Author: Falko Timme <ft [at] falkotimme [dot] com>, Christian Schmalfeld <c [dot] schmalfeld [at] projektfarm [dot] de>

Follow me on Twitter

Dieses Tutorial zeigt Ihnen wie Sie ein Verzeichnis eines entfernten Servers unter Verwendung von SSHFS auf dem lokalen Server sicher einhängen.  (Secure SHell FileSystem) ist ein Dateisystem, welches Dateien und Verzeichnisse sicher über SSH liefert, sodass lokale Benutzer es benutzen können, als on Sie auf dem lokalen Server wären. Auf dem lokalen Server wird das geteilte Verzeichnis über FUSE eingehängt (Filesystem in Userspace). Ich werde sowohl für den lokalen als auch für den entfernten Server Debian Squeeze nutzen.

Für die Inhalte dieses Tutorials gebe ich keinerlei Garantie!

1 Vorbemerkung

Ich benutze in diesem Tutorial die folgenden zwei Systeme:

• Local system: server1.example.com,
  IP address: 192.168.0.100
• Remote system: server2.example.com,
  IP address: 192.168.0.101

Ich zeige außerdem wie man SSHFS als normaler Benutzer und als root benutzt.

2 Installation SSHFS

server1:

Auf dem lokalen System muss SSHFS wie folgt installiert werden:

apt-get install sshfs

Stellen Sie danach sicher, dass das fuse Kernel Modul geladen wird:

lsmod | grep fuse

root@server1:~# lsmod | grep fuse

fuse                   50625  1

root@server1:~#

3 SSHFS als root benutzen

server1:

Ich möchte nun das Verzeichnis /home/backup des entfernten Servers (server2, Besitzer ist server2s root Benutzer) in das lokale
Verzeichnis /backup als lokaler root Benutzer einhängen.

Fügen Sie als erstes root zur fuse Gruppe hinzu:

adduser root fuse

Erstellen Sie das lokale Verzeichnis /backup und stellen Sie sicher, dass root als Besitzer eingetragen ist (dies sollte es ohnehin schon sein, da Sie diese Befehle als root auführen müssen):

mkdir /backup

chown root /backup

Hängen Sie dann das Verzeichnis /home/backup ins /backup Verzeichnis ein:

sshfs -o idmap=user root@192.168.0.101:/home/backup
/backup

(Sie können den vollen Pfad für das entfernte System benutzen wie oben gezeigt, oder relative Pfade benutzen wie hier:

sshfs -o idmap=user root@192.168.0.101:backup /backup

Benutzen Sie einen relativen Pfad, ist dieser relativ zum Persönlichen Ordner des Benutzers des entfernten System, in diesem Fall
wäre es also /root/backup. Sie können das Verzeichnis des entfernten Servers sogar wie folgt weglassen:

sshfs -o idmap=user root@192.168.0.101: /backup

Dies würde dann zum Persönlichen Ordner des Benutzers des entfernten Systems übersetzt werden – /root in this case.

)

-o idmap=user stellt sicher, dass es egal ist, ob der lokale und der entfernte Benutzer die selbe ID haben – Dateien des entfernten Benutzers haben zugleich den Benutzer des lokalen Systems als Besitzer. Wählen Sie diese Option nicht, könnten Sie Zugriffsberechtigungsprobleme kriegen.

Verbinden Sie sich das erste Mal mit dem entfernten Host wird Ihnen eine Authentizitätswarnung angezeigt (haben Sie sich bereits zuvor über ssh oder scp mit diesem Host verbunden, wird diese nicht angezeigt). In jedem Fall werden Sie nach dem root Passwort von server2 gefragt:

root@server1:~# sshfs -o idmap=user
root@192.168.0.101:/home/backup /backup

The authenticity of host ‚192.168.0.101 (192.168.0.101)‘ can’t be
established.

RSA key fingerprint is 25:d8:7a:ee:c2:4b:1d:92:a7:3d:16:26:95:56:62:4e.

Are you sure you want to continue connecting (yes/no)? <– yes

root@192.168.0.101’s password: <– server2_root_passwort

root@server1:~#

Überprüfen Sie nun, ob das Verzeichnis des entfernten Servers in /backup eingehängt wurde:

mount

root@server1:~# mount

/dev/sda1 on / type ext3 (rw,errors=remount-ro)

tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)

proc on /proc type proc (rw,noexec,nosuid,nodev)

sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)

udev on /dev type tmpfs (rw,mode=0755)

tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)

devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)

fusectl on /sys/fs/fuse/connections type fusectl (rw)

root@192.168.0.101:/home/backup on /backup type fuse.sshfs
(rw,nosuid,nodev,max_read=65536)

root@server1:~#

df -h

root@server1:~# df -h

Filesystem            Size  Used Avail Use% Mounted on

/dev/sda1              29G  1.2G   26G   5% /

tmpfs                 249M     0  249M   0% /lib/init/rw

udev                  244M  100K  244M   1% /dev

tmpfs                 249M     0  249M   0% /dev/shm

root@192.168.0.101:/home/backup

29G  1.2G   27G   5% /backup

root@server1:~#

Sieht die Ausgabe in etwa so aus, hat es funktioniert.

Um das Verzeichnis auszuhängen, führen Sie folgenden Befehl aus:

fusermount -u /backup

3.1 Ein Private/Public Key Paar auf server1 erstellen

Natürlich wollen Sie nicht jedes Mal das Passwort eingeben, wenn Sie die geteilten Dateien einhängen. Deshalb können Sie ein Paar aus privatem und öffentlichem Schlüssel erstellen und den öffentlichen auf server2 übertragen, sodass Sie nicht mehr nach dem Password gefragt werden.

server1:

Erstellen Sie ein Paar aus privatem und öffentlichem Schlüssel auf server1.example.com:

ssh-keygen

root@server1:~# ssh-keygen

Generating public/private rsa key pair.

Enter file in which to save the key (/root/.ssh/id_rsa): <– ENTER

Enter passphrase (empty for no passphrase): <– ENTER

Enter same passphrase again: <– ENTER

Your identification has been saved in /root/.ssh/id_rsa.

Your public key has been saved in /root/.ssh/id_rsa.pub.

The key fingerprint is:

b4:22:48:21:99:72:65:3e:1d:93:6f:9a:5c:5f:70:61 root@server1.example.com

The key’s randomart image is:

+–[ RSA 2048]—-+

|.o..o o.    E.   |
|+..+ ..o  …    |
|… o …  o     |
| . . . .+.  .    |
|  . …=S. .     |
|     .+.  .      |
|                 |
|                 |
|                 |

+—————–+

root@server1:~#

Es ist wichtig, dass Sie keine Passphrase eingeben, da das Einhängen sonst nicht ohne menschliche Interaktion funktioniert. Drücken Sie deshalb einfach auf ENTER!

Als nächstes kopieren Sie Ihren öffentlichen Schlüssel nach server2.example.com:

ssh-copy-id -i $HOME/.ssh/id_rsa.pub
root@192.168.0.101

Überprüfen Sie nun auf server2 ob server1s öffentlicher Schlüssel korrekt übertragen wurde:

server2:

cat $HOME/.ssh/authorized_keys

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDVdvyYlzgTkjZhDK8S+EZ1fVU/lvLlayKya/u+NY9w6WerYlCxX6nMN9b
eTXddmlTXg6uXGYAEEnFA36JlOcXz0cr7D8KEzW1vwRtZFJzZ/oH71aDKgrY7M4yRaCsKdElrF+pbq1JT84pEmlOKluVlqG
SGvn1Y0W/vrDgl9/j852tkqqIwUg+RjxRbxf13IwWhNOrIiNAFnxhKT9kMVXl9m5Gv5EYk130JNC/uSKTo8uxk5Z+Rq4m7v
aIqx0hk8zfLodZ5h4vDnUpwjIhEH+L+3OogeC5bm4zbAYTf4L/5dfobuSsWF88kO/6jAurKmoHShSA5n1YyJoE6ODAgvbpb 
root@server1.example.com

Zurück auf server1, versuchen Sie erneut die geteilten Dateien oder Verzeichnisse einzuhängen (stellen Sie sicher, dass diese ausgehangen sind bevor Sie den Befehl benutzen):

server1:

sshfs -o idmap=user root@192.168.0.101:/home/backup
/backup

Sollte alles richtig funktionieren, werden Sie nicht nach einem Passwort gefragt:

root@server1:~# sshfs -o idmap=user
root@192.168.0.101:/home/backup /backup

root@server1:~#

3.2 Die geteilten Daten direkt beim Systemstart einhängen

server1:

Wollen Sie die geteilten Dateien nicht ständig manuell einhängen, besteht die Möglichkeit diese automatisch beim Systemstart einzuhängen (vorausgesetzt Sie sind den Anleitungen aus Kapitel 3.1 gefolgt, ansonsten ist ein automatisches Einhängen nicht möglich, da Sie nach einem Passwort gefragt werden). Normalerweise würden Sie hierzu /etc/fstab modifizieren, doch leider ist das Netzwerk noch nicht aktiv, wenn der /etc/fstab Prozess beim hochfahren gestartet wird.

Um dies zu umgehen fügen Sie den Mountbefehl einfach zu /etc/rc.local hinzu, welches die Letzte Datei ist, welche beim Systemstart bearbeitet wird. Zu dieser Zeit ist das Netzwerk bereits aktiv:

vi /etc/rc.local

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

/usr/bin/sshfs -o idmap=user root@192.168.0.101:/home/backup /backup
exit 0

Sie können dies testen indem Sie Ihr System neustarten:

reboot

Nach dem Neustart können Sie mit

mount

und

df -h

einsehen ob die geteilten Dateien eingehängt wurden.

4 SSHFS als normaler Benutzer benutzen

server1:

Ich werde den lokalen Benutzer falko benutzen und das zu teilende Verzeichnis /home/someuser/backup, dessen Besitzer someuser ist, in das lokale Verzeichnis /home/falko/backup einhängen.

Erstellen Sie den Benutzer falko, wenn dieser noch nicht existiert (oder benutzen Sie einen bereits vorhandenen):

adduser falko

server2:

Erstellen Sie dann den Benutzer someuser auf server2, wenn dieser noch nicht existiert:

adduser someuser

Loggen Sie sich dann als someuser ein…

su someuser

…, begeben Sie sich in someuser’s Persönlichen Ordner und erstellen Sie das backup (/home/someuser/backup) Verzeichnis –
stellen Sie sicher, dass someuser als Besitzer eingetragen ist (es sollte ohnehin so sein, da Sie die Befehle als someuser) ausführen:

cd

mkdir ~/backup

chown someuser ~/backup

Sie können das someuser Konto nun verlassen:

exit

server1:

Fügen Sie als erstes falko zur fuse Gruppe hinzu

adduser falko fuse

Loggen Sie sich nun als falko ein:

su falko

Create the local /home/falko/backup directory and make sure it’s owned by falko (it should be anyway as you are running these commands as falko):

cd

mkdir ~/backup

chown falko ~/backup

Hängen Sie dann das /home/someuser/backup Verzeichnis in /home/falko/backup ein (immernoch als Benutzer falko) – Sie können für das zu teilende Verzeichnis entweder den vollen oder einen relativen Dateipfad angeben:

sshfs -o idmap=user someuser@192.168.0.101:backup
~/backup

oder

sshfs -o idmap=user
someuser@192.168.0.101:/home/someuser/backup ~/backup

-o idmap=user stellt sicher, dass es egal ist, ob der lokale und der entfernte Benutzer die selbe ID haben – Dateien des entfernten Benutzers haben zugleich den Benutzer des lokalen Systems als Besitzer. Wählen Sie diese Option nicht, könnten Sie Zugriffsberechtigungsprobleme kriegen.

Verbinden Sie sich das erste Mal mit dem entfernten Host wird Ihnen eine Authentizitätswarnung angezeigt (haben Sie sich bereits zuvor über ssh oder scp mit diesem Host verbunden, wird diese nicht angezeigt). In jedem Fall werden Sie nach dem root Passwort von server2 gefragt:

falko@server1:~$ sshfs -o idmap=user
someuser@192.168.0.101:/home/someuser/backup ~/backup

The authenticity of host ‚192.168.0.101 (192.168.0.101)‘ can’t be
established.

RSA key fingerprint is 25:d8:7a:ee:c2:4b:1d:92:a7:3d:16:26:95:56:62:4e.

Are you sure you want to continue connecting (yes/no)? <– yes

someuser@192.168.0.101’s password: <– server2_someuser_passwort

falko@server1:~$

Überprüfen Sie nun, ob die Dateien korrekt in /home/falko/backup eingehangen wurden:

mount

falko@server1:~$ mount

/dev/sda1 on / type ext3 (rw,errors=remount-ro)

tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)

proc on /proc type proc (rw,noexec,nosuid,nodev)

sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)

udev on /dev type tmpfs (rw,mode=0755)

tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)

devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)

fusectl on /sys/fs/fuse/connections type fusectl (rw)

root@192.168.0.101:/home/backup on /backup type fuse.sshfs
(rw,nosuid,nodev,max_read=65536)

someuser@192.168.0.101:/home/someuser/backup on /home/falko/backup type
fuse.sshfs (rw,nosuid,nodev,max_read=65536,user=falko)

falko@server1:~$

df -h

falko@server1:~$ df -h

Filesystem            Size  Used Avail Use% Mounted on

/dev/sda1              29G  1.2G   26G   5% /

tmpfs                 249M     0  249M   0% /lib/init/rw

udev                  244M  100K  244M   1% /dev

tmpfs                 249M     0  249M   0% /dev/shm

someuser@192.168.0.101:/home/someuser/backup

29G  1.2G   27G   5% /home/falko/backup

falko@server1:~$

Sieht die Ausgabe ähnlich aus, so sollte alles funktioniert haben.

Um die geteilten Daten auszuhängen, benutzen Sie einen der folgenden Befehle:

fusermount -u ~/backup

oder

fusermount -u /home/falko/backup

4.1 Ein Private/Public Key Pair auf server1 erstellen

Natürlich wollen Sie nicht jedes Mal das Passwort eingeben, wenn Sie die geteilten Dateien einhängen. Deshalb können Sie ein Paar aus privatem und öffentlichem Schlüssel erstellen und den öffentlichen auf server2 übertragen, sodass Sie nicht mehr nach dem Password gefragt werden.

server1:

Erstellen Sie ein Paar aus privatem und öffentlichem Schlüssel auf server1.example.com (noch immer als Benutzer falko):

ssh-keygen

falko@server1:~$ ssh-keygen

Generating public/private rsa key pair.

Enter file in which to save the key (/home/falko/.ssh/id_rsa): <– ENTER

Enter passphrase (empty for no passphrase): <– ENTER

Enter same passphrase again: <– ENTER

Your identification has been saved in /home/falko/.ssh/id_rsa.

Your public key has been saved in /home/falko/.ssh/id_rsa.pub.

The key fingerprint is:

14:14:0b:ba:04:a7:51:1b:67:59:94:d5:01:7e:55:21 falko@server1.example.com

The key’s randomart image is:

+–[ RSA 2048]—-+

|  o.+ +=*+oo.E.oo|

|   = *…+  …  |

|  . +   o . .    |

|   . . .   .     |

|    .   S        |

|                 |

|                 |

|                 |

|                 |

+—————–+

falko@server1:~$

Es ist wichtig, dass Sie keine Passphrase eingeben, da das Einhängen sonst nicht ohne menschliche Interaktion funktioniert. Drücken Sie deshalb einfach auf ENTER!

Als nächstes kopieren Sie Ihren öffentlichen Schlüssel nach server2.example.com:

ssh-copy-id -i $HOME/.ssh/id_rsa.pub
someuser@192.168.0.101

Überprüfen Sie nun auf server2 ob server1s öffentlicher Schlüssel korrekt übertragen wurde:

server2:

cat /home/someuser/.ssh/authorized_keys

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC+YpgpAaFYDYV2N0j4xteTx44tsz1pnSSQZPa0GkBi/KTuAJVT8DV4Jzh/
HvJnNXvoyT6cEcnJa6p1SQTpn3Xt7b5ItA2ckDYTm78q1HZwX3htrkDUPrKGRwfzovyf/HKop0kHawU+Fox1nmtM9xIEVBCP
ERBKL0TZjGuqfEo0m6lkatVChI8RIu9+wH9I8VZCHalz+QdjQ8Mp/ckdGfVdAry4SyFicjg4eVzTq7s54yXupcSio7v2Ql95
XO6azWzrU+G7VsI3UM0GMH9aXxjikx3dusmvLN9jBkL096Sheik1C7DOGVVsP6upCRVTcY6AB4J8VEmumdI4tnsSsr+x 
falko@server1.example.com

Zurück auf server1, versuchen Sie erneut die geteilten Dateien oder Verzeichnisse einzuhängen (stellen Sie sicher, dass diese ausgehangen sind bevor Sie den Befehl benutzen):

server1:

Sollte alles richtig funktionieren, werden Sie nicht nach einem Passwort gefragt:

sshfs -o idmap=user
someuser@192.168.0.101:/home/someuser/backup ~/backup

falko@server1:~$ sshfs -o idmap=user
someuser@192.168.0.101:/home/someuser/backup ~/backup

falko@server1:~$

4.2 Die geteilten Daten direkt beim Systemstart einhängen

server1:

Wollen Sie die geteilten Dateien nicht ständig manuell einhängen, besteht die Möglichkeit diese automatisch beim Systemstart einzuhängen (vorausgesetzt Sie sind den Anleitungen aus Kapitel 3.1 gefolgt, ansonsten ist ein automatisches Einhängen nicht möglich, da Sie nach einem Passwort gefragt werden). Normalerweise würden Sie hierzu /etc/fstab modifizieren, doch leider ist das Netzwerk noch nicht aktiv, wenn der /etc/fstab Prozess beim hochfahren gestartet wird.

Um dies zu umgehen fügen Sie den Mountbefehl einfach zu /etc/rc.local hinzu, welches die Letzte Datei ist, welche beim Systemstart bearbeitet wird. Zu dieser Zeit ist das Netzwerk bereits aktiv. Um /etc/rc.local zu editieren brauchen Sie Rootrechte:

su

vi /etc/rc.local

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

/usr/bin/sshfs -o idmap=user root@192.168.0.101:/home/backup /backup
cd /home/falko && su -c "/usr/bin/sshfs -o idmap=user someuser@192.168.0.101:/home/someuser/backup /home/falko/backup" falko
exit 0

Wie Sie sehen, habe ich den Befehl

cd /home/falko && su -c „/usr/bin/sshfs -o
idmap=user someuser@192.168.0.101:/home/someuser/backup
/home/falko/backup“ falko

hinzugefügt, anstatt nur

/usr/bin/sshfs -o idmap=user
someuser@192.168.0.101:/home/someuser/backup /home/falko/backup

da der sshfs Befehl von falko ausgeführt werden muss und nicht von root!

Sie können die Einstellungen nun testen nachdem Sie Ihr System neustarten:

reboot

Nach dem Neustart können Sie mit

mount

und

df -h

kontrollieren, ob die Dateien und Verzeichnisse korrekt eingehangen wurden.

5 Links

• SSHFS: http://fuse.sourceforge.net/sshfs.html
• Debian: http://www.debian.org/