Nun wurde von Stefan Deil gefragt, ob es einen Workaround gibt. Zwei Varianten möchte ich hier kurz vorstellen:

1. Proxy-Server

Die Sperre von Userfriendly geschieht auf Basis der IP-Adresse. Anfragen, die nicht aus dem Arcor-Netz kommen, werden ohne Probleme beantwortet. Die einfachste Möglichkeit ist daher, die Anfrage über einen Proxy zu senden, der diese dann an Userfriendly weiterleitet und die Antwort wiederum an den Browser durchreicht. Dieser Proxy muss in den Optionen des verwendeten Browsers eingetragen werden.

In einem Beitrag im Heiseforum wird z.B. ein Proxy der Piratenpartei vorgeschlagen (porn.piratenpartei.de:3128). Angeblich funktioniert selbst der Arcor-eigene Proxy (proxy.arcor-ip.de:8080), was ich aber nicht getestet habe.

Der Nachteil an diesem Ansatz ist, dass der gesamte »Surf-Traffic« nun über einen fremden Rechner geleitet wird, was man aus Gründen der Sicherheit, der eigenen Privatsphäre und/oder der Übertragungsrate nicht unbedingt möchte. Daher möchte ich noch eine zweite Möglichkeit aufzeigen.

2. ssh-Tunnel

Voraussetzung hier ist ein ssh-Zugang auf einen anderen Rechner oder Server, der außerhalb des Adressbereichs von Arcor liegt. ssh ermöglicht es, einen »Tunnel« aufzubauen und einen Port des eigenen Rechners mit diesem zu verbinden. Das Ganze hört sich komplizierter an als es ist. Unter Unix realisiert man den Tunnel mit diesem Befehl:

ssh -L 80:www.userfriendly.org:80 USER@SOME_HOST

Port 80 des eigenen (lokalen) Computers wird an den ssh-Tunnel gebunden, dessen anderes Ende mit Port 80 von www.userfriendly.org verbunden wird. Da es sich dabei um einen so genannten priviligierten Port handelt, benötigt dieser Befehl root-Rechte. USER ist natürlich durch die entsprechende Nutzerkennung zu ersetzen, mit der man sich auf dem entfernten Rechner SOME_HOST anmelden kann. Für Windows-User existiert der ssh-Client PuTTY, der das gleiche leisten sollte, mit dem ich mich aber nicht auskenne — wenn jemand mehr weiß, würde ich mich über einen entsprechenden Kommentar freuen.

Nun muss man noch dafür sorgen, dass Anfragen für Userfriendly auch an localhost und damit über den Tunnel gesendet werden. Das erreicht man am einfachsten mit folgender Zeile in der Datei /etc/hosts (unter Windows heißt die Datei auch »hosts«, ich weiß aber nicht wo sie liegt):

127.0.0.1 www.userfriendly.org

Diese sorgt dafür, dass die Adresse www.userfriendly.org auf die lokale IP des eigenen Rechners aufglöst wird. Jetzt genügt es, eben diese Adresse im Browser der Wahl aufzurufen. Eine Einschränkung gibt es aber leider dennoch: userfriendly ist über die Hosts »www« und »ars« verteilt. Da wir nur einen von beiden umleiten können, ist die Navigation auf der Seite nur eingeschränkt möglich. Prinzipiell kann man auch das in den Griff kriegen, es wird dann nur ein wenig aufwändiger.

Die zweite Variante hat den Vorteil, dass wirlich nur der Traffic von und zu Userfriendly umgeleitet wird; alle anderen Verbindungen bleiben unverändert.

PS. Dilbert und xkcd existieren auch noch… ;-)

den Fingerprint bekommt Ihr Client automatisch bei der ersten Verbindung mitgeteilt.

Kopf -> Tisch

Das GNOME-Environment bringt zwar schon eine entsprechende Funktion mit, die den eigenen Desktop für einen Zugriff von außen freigibt, diese basiert aber leider auf »reinem« VNC, d.h. die Daten der Verbindung werden unverschlüsselt übertragen. In einem LAN mag das gehen, für die Übertragung im Internet habe ich nach einer verschlüsselten Variante gesucht.

Letztlich habe ich mich dafür entschieden, eine VNC-Verbindung über ssh zu tunneln. NX habe ich mir zwar auch angesehen, der Client unterstützt aber leider keine Pubkey-Authentifizierung und war auch sonst in der Bedienung eher umständlich. Das System auf beiden Seiten ist jeweils Debian GNU/Linux »Etch« und so geht es:

1. ddclient

Zunächst muss dafür gesorgt werden, dass man den zu betreuenden Rechner auch erreichen kann. Sofern dieser keine statische IP-Adresse hat, muss man auf Dienste wie z.B. DynDNS oder easyDNS ausweichen.

Ist der betreffende Rechner direkt mit dem Internet (ohne Router) verbunden, gibt es hier keine Hürden:

# aptitude install ddclient

installiert ddclient, das sich mit einer ganzen Reihe von Diensten verwenden lässt. Debconf fragt direkt nach allen relevanten Konfigurationsparametern, die man später wie gewohnt durch den Aufruf von dpkg-reconfigure ddclient noch ändern kann. ddclient meldet dann die aktuelle IP-Adresse an den jeweiligen Dienst, sobald eine Internetverbindung hergestellt wird.

Ein wenig komplizierter wird es, wenn ein Router ins Spiel kommt. In diesem Fall muss sich nämlich dieser um das Update beim DNS-Dienst kümmern — ob der jeweilige Router dies kann, ist der entsprechenden Dokumentation zu entnehmen. Darüber hinaus muss noch ein Port Forwarding eingerichtet werden, d.h. alle Verbindungen auf einen Port am Router werden zu einem Port eines der angeschlossenen Rechner weitergeleitet. Auch hierfür sei auf die Dokumentation des Herstellers verwiesen.

2. ssh

Sofern noch nicht vorhanden, muss auf dem Zielrechner ein ssh-Server installiert werden:

# aptitude install openssh-server

Aus Sicherheitsgründen sollte auf jeden Fall der Login für root gesperrt und auch Passwort-Logins deaktiviert werden. Diese Zeilen müssen dafür in /etc/ssh/sshd_config stehen:

PermitRootLogin no
PasswordAuthentication no
UsePAM no

Als nächstes ist ein Schlüsselpaar zu erzeugen und dessen öffenlicher Teil den autorisierten Schlüsseln des zu betreuenden Benutzerkontos hinzuzufügen:

$ ssh-keygen -t dsa -f /path/to/id_file
# cat /path/to/id_file >> /home/username/.ssh/authorized_keys

Den geheimen Teil des Schlüssels sollte man auf keinen Fall auf dem PC des Anwenders zurücklassen! Die Gefahr, dass der Schlüssel und damit der Zugang zu dem Rechner in Hände gerät, in die er nicht gehört, ist groß. Am besten erzeugt man sich ein entsprechendes »Support«-Schlüsselpaar zu Hause und nimmt es auf einem USB-Stick mit.

3. VNC

Als letztes muss noch der VNC-Server installiert werden:

# aptitude install x11vnc

Als letztes muss noch ein Passwort für diesen vergeben werden. Dazu füht man im Kontext des zu betreuenden Nutzers folgenden Befehl aus:

$ x11vnc -storepasswd ~/.vnc/passwd

Das Passwort ist wichtig, da sonst ein Zugriff auf den VNC-Server durch andere Benutzer, die auf dem gleichen PC angemeldet sind, möglich wäre.

Damit ist die Konfiguration abgeschlossen und man kann sich mit dem Rechner verbinden.

4. Eine Verbindung aufbauen

Wir befinden uns jetzt wieder am eigenen PC und möchten den Desktop unseres Nutzers auf unseren Monitor holen. Dazu wird zunächst der VNC-Server auf dem entfernten Rechner gestartet und dessen Port (5900) auf (den eigenen) localhost umgeleitet:

$ ssh -C -i /path/to/id_file -L 5900:localhost:5900 USER@HOST "x11vnc -localhost -display :0 -rfbauth ~/.vnc/passwd"

Zur Erklärung:

• -C komprimiert die übertragenen Daten
• /path/to/id_file muss ersetzt werden durch den Pfad zum privatekey
• -L 5900:localhost:5900 leitet Port 5900 des entfernten Rechners auf Port 5900 von localhost um
• USER und HOST sind durch den Benutzernamen und den (dynamischen) Hostnamen zu ersetzen
• Der Rest der Zeile ist das Kommando, das auf dem entfernten Rechner ausgeführt werden soll: starten des VNC-Servers und Bereitstellung des Displays :0 auf localhost

Das Ergebnis sollte eine Meldung sein, dass der VNC-Server erfolgreich gestartet wurde und auf Verbindungen wartet.

Nun kann man sich mit einem VNC-Client der Wahl (z.B. vncviewer) am Server anmelden:

$ vncviewer localhost

Nach Eingabe des Passwortes ist man nun mit dem Desktop des entfernten PCs verbunden.

Noch ein Hinweis

Ich möchte ausdrücklich darauf hinweisen, dass selbstverständlich das Einverständnis des jeweiligen Benutzers vorliegen muss, bevor man sich mit dessen Computer verbindet!