Es war einmal ein guter Freund, der weilte zur Zeit der Herrschaft des Kaisers Hu Jintao in China. Er war von seinen Hauptleuten wegen wichtiger Geschäfte in eine kleine Stadt in der chinesischen Provinz beordert worden. Höchstens 4 Millionen Seelen umschloß der Ort, und das Leben an den langen Winterabenden war unendlich öd und trist. Der Freund vermochte nicht in der Zunge des gemeinen Volkes zu reden, auch ging jeder des Abends seiner Wege und den Freund dürstete es nach Neuigkeiten, die seine Seele zu erquicken vermöchten. Wie froh war er, als er in seiner bescheidenen Herberge einen Internetanschluß fand! Aber groß war sein Erschrecken, als er die Neuigkeiten des Tages von CNN hören wollte und von der Wikipedia nähere Informationen über die Stadt begehrte, in der er gerade weilte. Denn Kaiser Hu hatte nicht wollen leiden, daß seine Untertanen ihre Zeit mit Tand und Glitzer vertäten anstatt die Wohlfahrt des Hofes und der kaiserlichen Manufakturen zu mehren, und seine Präfekten und Minister angewiesen, streng gegenüber jeder Anmaßung und Hoffahrt in seinem Volke zu sein. Da wurde der Freund sehr traurig und haderte mit seinem Schicksal.

Sie werden das Problem vielleicht auch aus Ihrer Firma kennen: hinter Proxy und restriktiver Firewall ist Schluß. Der im folgenden vorgestellte Weg ist oft auch in solchen Fällen gangbar, um das Firmennetz zu verlassen, aber ich will Sie nicht dazu verleiten, Ärger mit Ihrem Arbeitgeber heraufzubeschwören. Gegen den freien Zugang zu wichtigen Informationen aus einem chinesischen Hotel heraus wird aber auch Ihr Arbeitgeber nichts haben.

Im konkreten Fall ergaben Tests:
1. Grundsätzlich funktionierte der Zugriff auf HTTP- und HTTPS-Seiten außerhalb Chinas. Nur bei einigen Domains (wie z.B. wikipedia.org oder cnn.com) kamen immer leere Seiten zurück.
2. DNS lieferte auch zu den inkriminierten Domains die richtigen IP-Adressen (erste Überraschung).
3. Der Zugriff mit SSH-Protokoll (Secure Shell) auf Port 22 eines Servers außerhalb von China funktionierte ebenfalls (zweite, große Überraschung).

Übertrieben hohen Wert scheint die chinesische Führung also auch nicht darauf zu legen, Kommunikationsversuche zu unterbinden. Wer also irgendwo einen Linux-Server sein eigen nennt, ob gemietet draußen im Internet oder daheim hinter einer Firewall, ist fein raus, denn er kann sich auf seine Reise vorbereiten. Im folgenden wird die Einrichtung einer abhörsicher verschlüsselten Verbindung beschrieben, die Zugriff auf einen in Freiheit lebenden Webproxy und gegebenenfalls noch weitere Dienste und Protokolle erlaubt.

Einrichtung des Servers

Auf dem Linux-Server muß nur der Proxy Squid zusätzlich installiert werden, denn der SSH-Server gehört zum Standardumfang jeder Linux-Installation. Für den genannten Zweck muß Squid nur Verbindungsaufnahmen von localhost unterstützen, man kann den Proxy also restriktiv konfigurieren und den Zugriff auf Port 3128 (den Standardport von Squid) von außerhalb im Paketfilter (zum Beispiel iptables) unterbinden. Wer den Proxy von außen zugänglich machen will, tut gut daran, den Zugriff auf Squid mit einem Paßwort zu schützen. Das geschieht durch entsprechend gesetzte Optionen in der Konfigurationsdatei squid.conf, die in Kommentaren innerhalb der Konfigurationsdatei bereits vorgeschlagen werden. Außerdem ist eine spezielle Paßwortdatei für Squid anzulegen.

SSH wird durch Änderungen an der Datei sshd_config eingerichtet. Ich rate grundsätzlich dazu, die Option AllowUsers zu verwenden und ChallengeResponseAuthentication sowie PasswordAuthentication auszuschalten. Der Nutzer meldet sich dann nicht mit einem Paßwort an, sondern ausschließlich durch Vorweisen seines Schlüssels. Ich empfehle außerdem, die autorisierten Schlüssel der Nutzer nicht unterhalb des Heimtverzeichnisses des jeweiligen Nutzers abzulegen, sondern zentral. Dazu erstellt man ein Verzeichnis /etc/ssh/authorized_keys (Zugriffsrechte 0755) und ändert eine weitere Option in der sshd-Konfigurationsdatei: AuthorizedKeysFile /etc/ssh/authorized_keys/%u.

Wer einen Server daheim verwendet, muß den Zugriff auf Port 22 des Servers in der Firewall freischalten und sollte außerdem dafür sorgen, daß der heimatliche Internetanschluß unter einem Namen im Internet sichtbar ist. Das kann über die Nutzung eines Dynamischen DNS-Dienstes geschehen. Für die Anmeldung der IP-Adresse bei solchen Diensten nach Adreßwechsel (z.B. nach der täglichen Zwangstrennung und Wiedereinwahl) sorgt das Linux-Paket ddclient.

Wer auf seinem Linux-Server den Port 443 frei hat, weil er keine HTTPS-Seiten ausliefert, kann den SSH-Dienst auch auf Port 443 betreiben. Das hat Vorteile, falls das hier beschriebene Verfahren einmal eingesetzt wird, um durch einen widerborstigen Proxy hindurch eine Verbindung herzustellen. Port 443 (HTTPS) wird von den meisten Proxies durchverbunden, ohne daß geprüft wird, ob das Protokoll wirklich HTTPS ist, während der Ausgang durch Port 22 in fast allen Firmen-Firewalls aus gutem Grund gesperrt ist. Wenn der Server auch noch ein gut ausgebauter Internetserver mit Apache SSL ist, und der Port 443 daher nicht frei ist, kann man von seinem Provider eventuell eine zweite IP-Adresse bekommen, unter der dann auch der Port 443 verfügbar ist.

Einrichtung des Clients

Auf dem Windows-Client wird das Programmpaket PuTTY installiert. Mit puttygen erzeugt man zuerst einen Schlüssel. Der öffentliche Schlüssel wird aus dem Fenster von puttygen in die Datei /etc/ssh/authorized_keys/ichselbst (für den Nutzer mit dem Login-Namen ichselbst, Zugriffsrechte auf die Datei 0600, Eigentümer ist ichselbst) kopiert. Wenn man innerhalb der SSH-Verbindung nur bestimmte TCP-Tunnel zulassen möchte, kann man dies durch Voranstellen der permitopen-Option erreichen.

Mit dem Programm putty wird eine neue Sitzung eingerichtet. Wir gehen im Beispiel davon aus, daß wir uns entschieden haben, für SSH den Port 443 zu mißbrauchen. Als Nutzername für die Anmeldung wird der Login-Name auf dem Linux-Server eingetragen.

Der Ablagepfad des zuvor generierten Schlüssels wird eingetragen und die Endpunkte des Tunnels festgelegt. Im Beispiel sieht man, daß der lokale Port 3128 (L3128) mit dem Port 3128 auf dem Linux-Server (127.0.0.1:3128) verknüpft ist. Die lokale IP-Adresse 127.0.0.1 bezieht sich dabei auf das jenseitige Ende des Tunnels.

Wer mit dem beschriebenen Verfahren noch einen Firmen-Proxy zu durchqueren hat, muß diesen unter dem Punkt "Proxy" auch noch eintragen. Bitte nicht verwirren lassen durch so viele Proxies und nicht vergessen, diese PuTTY-Einstellungen zu speichern!

Bevor wir zu den Einstellungen im Browser kommen, zeigen wir noch, wie man PuTTY so konfiguriert, daß es als SOCKS 5-Server fungiert. Wozu das gut ist, wird auch gleich erklärt. Vorerst belassen wir es aber noch bei den bisherigen Einstellungen (L3128 127.0.0.1:3128).

Zuerst wird die SSH-Verbindung aufgebaut. Der Browser (auf Reisen hoffentlich Firefox) wird auf den lokalen Proxy 127.0.0.1:3128 konfiguriert (linkes Bild). Damit sollte die Verbindung durch die Große Chinesische Mauer also funktionieren. Den Test sollte man aber schon einmal zuhause durchführen.

Wer Schwierigkeiten mit der Namensauflösung hat (z.B. weil die chinesische Führung beschließt, in dieser Hinsicht die Zügel etwas straffer anzuziehen), kann PuTTY auch als SOCKS-Server verwenden. Firefox hat den Vorteil, die DNS-Namensauflösung auch über den SOCKS-Server vornehmen zu können. Die dafür erforderlichen Einstellungen im Browser sind in den Bildern gezeigt.

Wir hoffen, daß Ihnen diese Hinweise auf Ihren Reisen in merkwürdige Länder etwas helfen. Wir freuen uns natürlich über Ihre Anmerkungen und Hinweise. Wenn Sie Fälle kennen, wo eine Verbindungsaufnahme mit dem SSH-Protokoll unterbunden wurde und wo stattdessen httptunnel oder stunnel funktionierte (bzw. SSH getunnelt durch einen httptunnel, der Phantasie sind ja keine Grenzen gesetzt), dann würden wir gern auch Ihre Konfigurationsanleitung veröffentlichen.