dreckhände

 Oft ist es ja nur der Rechner in der anderen Ecke des Lab, dessen desktop ich mal eben vor mir sehen möchte, und lieber nicht hinübergehen. Aber es funktioniert im wesentlichen ganz genau so mit einer Kiste, die hunderte Kilometer entfernt ist: eben mal vnc aufmachen.

Ich bin da, nach einigen Versuchen, mal auf tightvnc gestossen, der sich flink installieren und einrichten lässt und prima mit dem kdrc harmoniert. Und tightvnc laesst sich klaglos durch einnen ssh-Tunnel schicken, und das beruhigt schon. 

Ich gehe hier mal davon aus, dass zu dem entfernten Rechner ohnehin eine ssh-Verbindung besteht und Passworte dank authentification keys kein Thema sind.

Auf dem entfernten Rechner ist tightvnc schnell installiert, mit debian reicht ein

apt-get install tightvncserver  (als root)

und dann startet man den server zum initialisieren als der user, mit dem man auf dem entfernten Rechner aktiv sein will. 

vncserver

Man darf/muss ein Passwort festlegen, notieren! - man wird bei jeder Verbindung danach gefragt werden. Erstmal fertig.
Um jetzt konkret eine Session zu öffnen, gebe ich, als user, auf der console des entfernten Rechners

tightvncserver -nolisten tcp -localhost -geometry 1152x864 -nevershared :2
und kontrolliere den Erfolg mit
ps aux|grep vnc

Xtightvnc :2 -desktop X -auth /home/user/.Xauthority -geometry 1152x864 -depth 24 -rfbwait 120000 -rfbauth /home/user/.vnc/passwd -rfbport 5902 -fp /usr/share/fonts/X11/misc/,/usr/share/fonts/X11/Type1/,/usr/share/fonts/X11/75dpi/,/usr/share/fonts/X11/100dpi/ -co /etc/X11/rgb -nevershared -nolisten tcp -localhost :2

der rfbport (5902) und die Nummer des desktops (:2) sind die beiden Daten, die ich in dieser Ausgabe kontrolliere, dann bin ich mit dem Server soweit fertig und wechsele zu einer Shell des lokalen Rechners, auch hier als passender user.

krdc vnc:/127.0.0.1:2 & ssh user@host.domain.tld -N -C -L 5902:127.0.0.1:5902

und pling öffnet sich der kdrc mit der Passwortabfrage und dann baut sich der entfernte Desktop auf. Bei langameren Verbindungen (dsl rauf und schmales dsl runter) vereinfacht es die Maussteuerung, wenn man im krdc oben "Local Cursor" aktiviert. 

Datenaustausch mit dem Server, das ist vom Windows-Desktop her in der Regel ein Job für WinSCP , vom Linux CLI tar und scp. Wenn man sich einmal die kleine Mühe gemacht hat, sshd für authorized_keys einzurichten, ist das alltagstauglich komfortabel.

rsync hat seine Stärken beim Backup. Aber zuweilen wäre es am praktischsten, ein entferntes Verzeichnis lokal zu mounten und das geht mit sshfs. sshfs ist ein FUSE-Modul, mit dem man entfernte Rechner über SSH in das eigene Dateisystem einbinden kann. Der Vorteil gegenüber einer ssh-Shell ist, dass man damit die Dateien und Verzeichnisse auf dem entfernten Rechner sehr komfortabel editieren, kopieren oder verschieben kann – genau wie die Dateien und Verzeichnisse auf den lokalen Festplatten. Auf dem Server braucht es dazu ein sftp-Programm, das aber in der Regel schon vorhanden ist.

Lokal muss FUSE eingerichtet sein, sshfs installiert, der Benutzer muss der Gruppe fuse zugeteilt sein und ein mount point muss bereitstehen.

sudo apt-get install sshfs
sudo mkdir /media/Verzeichnisname
sudo chown Benutzername /media/Verzeichnisname
sudo adduser Benutzername fuse

Will man sich vergewissern, dass die ssh-Verbindung klappt, ruft man zum Test erst mal eine shell

ssh server.tld 
exit

und dann ist man auch schon startklar,

sshfs server.tld:/pfad  /media/Verzeichnisname

bindet das entfernte Verzeichnis ein. Um es später wieder zu lösen, gibt man

fusermount -u  /media/Verzeichnisname

Es gibt noch zahlreiche Optionen, darunter -p Portnummer und -o idmap=user, um den lokalen Benutzer auf eine UID auf dem server abzubilden. Und weil ssh problemlos mit IPv6 zurecht kommt, kann sshfs dies natürlich auch.