© Jan Paul Herr, Pixelio.de

Admins müssen sich oft auf einem entfernten Rechner anmelden. Ist ein einfaches Passwort die einzige Hürde beim Login, bleibt ein ungutes Gefühl. Doch unter Linux erlaubt eine ganze Palette von Verfahren mit unterschiedlichen Vor- und Nachteilen eine kryptographisch gesicherte Authentifizierung.

Die Situation kennt jeder: Man ist unterwegs und braucht aus irgendeinem Grund Zugriff auf den PC in der Firma oder Zuhause, auf dem eine wichtige Datei oder E-Mail liegt. Internetzugang gibt es heute fast überall und damit prinzipiell auch eine Zugriffsmöglichkeit. Damit die aber nicht jeder andere Internetnutzer ebenso benutzen kann, gilt es, einen Riegel vorzuschieben.

Der einfachste Schutz ist ein Passwort. Das sollte mindestens acht, besser zwölf Zeichen oder länger sein, neben Buchstaben auch Ziffern oder Sonderzeichen enthalten und nicht in einem Wörterbuch oder Nachschlagewerk vorkommen. Wer ein solches Passwort dann mehrmals jährlich wechselt, ist auf der sicheren Seite. Leider kommen in der Praxis aber oft Passwörter zum Einsatz, die sich eher daran orientieren, dass der Anwender sie sich leicht merken kann. Solche Passwörter halten besserer Cracker-Software allerdings nicht lange stand.

Glücklicherweise gibt es eine ganze Reihe Alternativen zum einfachen Passwort. Asymmetrische Verschlüsselungsverfahren, wie sie im Internet an vielen Stellen die Verbindungen chiffrieren (etwa bei HTTPS oder bei SSH), lassen sich auch verwenden, um einzelne User zuverlässig zu authentifizieren. Weil der Schlüssel hier viel länger ist als beim besten Passwort und weil er aus zufälligen Elementen besteht, bietet er deutlich mehr Schutz.

Grundlagen

Bei der asymmetrischen Verschlüsselung gibt es immer zwei Schlüssel, einen privaten und einen öffentlichen. Was der eine verschlüsselt, kann der andere wieder entschlüsseln. Im klassischen Setup hat ein HTTPS- oder SSH-Server einen privaten Schlüssel und der Client kennt oder bekommt den zugehörigen öffentlichen Schlüssel. Damit können nun beide eine geschützte Verbindung aufbauen. Der Client kann außerdem den Server zweifelsfrei identifizieren, denn wenn der Server die mit seinem öffentlichen Schlüssel chiffrierten Informationen entschlüsseln konnte, muss er im Besitz des privaten Schlüssels sein. Da den nur der echte Server kennt, weiß der Client, dass er mit dem Original spricht.

Auch der umgekehrte Weg ist möglich: Wieder geht’s um ein Schlüsselpaar, aber nun besitzt der Client den privaten Schlüssel. Bei X.509-Zertifikaten (wie sie bei HTTPS und OpenVPN zum Einsatz kommen) spricht man von einem Client-Zertifikat, bei SSH von einem Key-File, auch wenn dieser Begriff streng genommen nicht eindeutig ist. Wer dieses Verfahren zur Authentifizierung von Usern einsetzen will, braucht für jeden User ein eigenes Client-Zertifikat beziehungsweise Key-File. Auch dafür bringt Linux alle nötigen Tools bereits mit.

Unter Linux stehen mehrere Dienste zur Wahl, die alle eine verschlüsselte Verbindung herstellen und es erlauben, den User mit Hilfe eines privaten Schlüssels zu authentifizieren. Im Unterschied zum Passwort reicht dafür Wissen allein nicht mehr aus, sondern der User muss jetzt eben auch im Besitz des Schlüssels sein. Dieser Beitrag stellt die verbreitetsten drei dieser Dienste einander gegenüber. Da sie alle ein vergleichbares Sicherheitsniveau bieten, kann jeder Admin einfach das Tool wählen, das zu den eigenen Anforderungen am besten passt.

Shell-User nutzen OpenSSH

Einen SSH-Server bringen alle gängigen Distributionen mit, meist läuft er per Default. Standardmäßig erlaubt er zwar Authentifikation per Passwort, doch auch ein Schlüsselpaar für die Authentifizierung ist schnell erzeugt: Der Befehl »ssh-keygen -t rsa« erledigt das.

Bei »Enter file in which to save the key« übernimmt der Admin am besten den Standardwert. Als Nächstes fragt das Kommando eine Passphrase ab. Hier empfiehlt es sich, ein gutes Passwort zu wählen. Es dient dazu, den privaten Schlüssel (Key-File) zu schützen. Sollte dieser jemals in falsche Hände fallen, bietet diese Passphrase den letzten Schutz. Je länger ein Angreifer braucht, um sie zu knacken, desto länger hat der Angegriffene Zeit, den Verlust zu bemerken und den Schlüssel auszutauschen.

Ist der Schlüssel generiert, sollten im Unterverzeichnis ».ssh« des eigenen Homeverzeichnisses die Dateien »id_rsa« (privater Schlüssel) und »id_rsa.pub« (öffentlicher Schlüssel) liegen. Der öffentliche ist nun auf jenen Rechner zu verfrachten, auf den der Nutzer zugreifen will, und dort unter »~/.ssh/authorized_keys« zu speichern. Anschließend sorgt ein »chmod 600 authorized_keys« für den nötigen Schutz. Achtung: Bei zu laschen Berechtigungen – etwa wenn ein »w« für die Gruppe gesetzt ist oder wenn der Benutzer nicht selbst Eigentümer der Datei ist -, weigert sich der SSH-Daemon aus Sicherheitsgründen diesen Schlüssel zu verwenden!

Der private Schlüssel muss auf dem Rechner verfügbar sein, von dem aus der Nutzer zugreifen will. Auf einem USB-Stick ist er stets problemlos greifbar. Läuft der Client unter Linux, baut der Nutzer dann mit »ssh -i keyfile username@server« eine SSH-Verbindung auf. Das Kommando fragt die Passphrase des Schlüssels, nicht das Kennwort des Users ab, bevor sich eine Shell des Servers öffnet. Zum Kopieren von Dateien über die gesicherte Verbindung steht nun »scp« bereit.

SSH und Windows

Gelegentlich muss mancher allerdings einen Windows-Client benutzen. Windows bringt von Haus aus aber keinen SSH-Client mit. Dann ist jener Admin fein raus, der den Windows-SSH-Client Putty [1] auf dem USB-Stick dabei hat. Hierfür eignet sich die portable Version, die sich ohne Installation direkt vom Stick starten lässt [2]. Leider benötigt sie den privaten Schlüssel in einem anderen Dateiformat als OpenSSH.

Die Konvertierung lässt sich über den Putty Key Generator »puttygen.exe« erledigen, den es bei [1] gibt. Unter »Conversions | Import key« kann man seinen privaten Schlüssel laden, wobei die Passphrase nötig ist. Der Button »Save private key« speichert ihn im Putty-eigenen Format. Klug ist es, einen Dateinamen mit der Endung ».ppk« zu wählen. Diese Form des Schlüssels kommt zweckmäßigerweise ebenfalls auf den Stick.

Jetzt lässt sich die Verbindung aufbauen: Ein Doppelklick auf »PuTTYPortable.exe« startet den Client (Abbildung 1). In das Feld »Hostname« gehört der Name des Servers, »Connection Type« muss auf »SSH« eingestellt sein, was automatisch Port 22 auswählt. Unter »Connection | Data | Auto-login username« trägt der Anwender den Usernamen ein, den er verwenden möchte. Unter »Connection | SSH | Auth« wählt er bei »Private Key for authentication« das gerade erzeugte PPK-File aus.

Abbildung 1: Der Konfigurationsdialog von Putty, dem gängigsten SSH-Client für Windows.

Wer all diese Einstellungen nicht jedes Mal erneut eingeben will, speichert die Session unter einem aussagekräftigen Sessionsnamen. Bei der Portable-Version von Putty landen die Sessions dabei auf dem Stick, statt in der Windows-Registry. Auch »scp« steht bereit, die Putty-Variante heißt »pscp« und ist ebenfalls auf [1] verfügbar. Die Syntax ist prinzipiell die gleiche wie unter Linux, leider ist der komplette Pfad anzugeben, da der Nutzer auf dem Windows-Rechner oft nur Gast ist und die Umgebungsvariable »PATH« nicht dauerhaft erweitern kann. .

Remote-GUI

Klappt die SSH-Verbindung erst einmal mit Key-Authentifizierung, muss der Admin – um einen Sicherheitsgewinn zu erzielen – natürlich die Passwort-Authentifizierung abschalten. Dazu setzt er in »/etc/ssh/sshd_config« die Einstellung »PasswordAuthentication no« und kann dann auch gleich noch »PermitRootLogin no« einstellen.

Die einfachen Fälle sind damit abgedeckt. Wer beispielsweise eine GUI-Anwendung auf dem entfernten Rechner starten will, für den tunnelt SSH normalerweise das X-Window-Protokoll. Auf Linux-Clients ist daher auch dies kein Problem. Das Fenster der entfernt laufenden Anwendung erscheint dann lokal auf dem Desktop. Auf Windows-Clients ist das Problem schon viel komplizierter. Hier ist von Haus aus kein X-Server vorhanden und Cygwin [3] oder andere Alternativen möchte oder darf kaum jemand vorher installieren. Daher bleiben diese Türen normalerweise verschlossen.

Browser-Anwendungen dagegen lassen sich fast immer nutzen, dazu tunnelt der Admin die HTTP-Verbindung einfach durch eine SSH-Verbindung [4]. Dies Verfahren hat den Vorteil, dass der Zugriff auf diese Anwendung ausschließlich authentifizierten Nutzern zur Verfügung steht. Den HTTP-Port muss der Admin dann auch nicht nach außen freigeben, denn der Client redet nur mit seinem Localhost-Interface.

SSH-Tunnel haben allerdings den Nachteil, dass statt der tatsächlichen, jetzt abweichende lokale IP-Adressen im Spiel sind. Damit entstehen Probleme mit vollqualifizierten Links und bei Redirects: Der User muss die URLs manuell umschreiben. Erfahrene Anwender kommen damit zurecht, für weniger versierte Nutzer ist das Setup relativ ungeeignet.

01 <VirtualHost _default_:443>
02         DocumentRoot "/var/www/html"
03         ServerName dunno.dyndns.info
04         ServerAdmin himself@meine-domain.de
05         ErrorLog logs/error_log
06         TransferLog logs/access_log
07         SSLEngine on
08         SSLCipherSuite HIGH:MEDIUM
09         SSLCertificateFile /etc/httpd/conf/ssl.crt 
        dunno.dyndns.info.crt
10         SSLCertificateKeyFile /etc/httpd/conf/ssl.key/dunno.dyndns.info.key
11 </VirtualHost>

HTTPS mit Client-Zertifikat

Sollen auch Endanwender Zugriff aus der Entfernung haben, gibt der Admin ihnen am besten eine vertraute Umgebung, etwa einen Browser. Auf dem entfernten Rechner muss dazu ein Webserver laufen, der Zugriff auf die gewünschten Dateien oder Anwendungen ermöglicht. Wer einfach nur Verzeichnisse freigeben will, hat mit dem installierten Apache schon alles an Bord, was nötig ist. »mod_userdir« ermöglicht beispielsweise die Freigabe von Homeverzeichnissen, die mitgelieferte »httpd.conf« bringt schon ein geeignetes Beispiel mit. Um ein beliebiges Verzeichnis freizugeben, helfen die folgenden Direktiven:

Alias /data/ "/opt/data/"
<Location /data>
  Options Indexes
</Location>

Die Option »Indexes« erlaubt dabei Directory-Browsing, der Benutzer kann sich also im Verzeichnisbaum bis zur gewünschten Datei durchklicken und diese dann herunterladen. Soll es möglich sein, auch Dateien hochzuladen, ist WebDAV ([5], [6]) erforderlich.

01 [booboo@dunno ~]$ umask 077
02 [booboo@dunno ~]$ mkdir ca
03 [booboo@dunno ~]$ cd ca
04 [booboo@dunno ~]$ mkdir newcerts
05 [booboo@dunno ~]$ echo -ne "01" >serial
06 [booboo@dunno ~]$ echo -ne "01" >crlnumber
07 [booboo@dunno ca]$ locate openssl.cnf
08 [booboo@dunno ca]$ cp Pfad/openssl.cnf ./ca.cnf
09 [booboo@dunno ca]$ vi ca.cnf
10 [booboo@dunno ca]$ # Anpassungen wie im Kasten "Zertifikate erstellen"
    beschrieben.
11 [booboo@dunno ca]$ openssl genrsa -des3 -out ca.meine-domain.de.key 2048
12 [...]
13 Enter pass phrase for ca.meine-domain.de.key:********
14 Verifying - Enter pass phrase for ca.meine-domain.de.key:********
15 [booboo@dunno ca]$ openssl req -config ./ca.cnf -new -x509 -days 3650 -key ca.meine-domain.de.key -out ca.meine-domain.de.crt
16 Enter pass phrase for ca.meine-domain.de.key:********
17 [...]
18 Country Name (2 letter code) [GB]:DE
19 State or Province Name (full name) [Berkshire]:Bayern
20 Locality Name (eg, city) [Newbury]:Nuernberg
21 Organization Name (eg, company) [My Company Ltd]:BooBoo
22 Organizational Unit Name (eg, section) []:
23 Common Name (eg, your name or your server's hostname) []:ca.meine-domain.de
24 Email Address []:ca@meine-domain.de
25 
26 [booboo@dunno ca]$ openssl genrsa -out dunno.dyndns.info.key 1024
27 [...]
28 [booboo@dunno ca]$ openssl req -config ./ca.cnf -new -key dunno.dyndns.info.key -out dunno.dyndns.info.csr
29 [...]
30 Common Name (eg, your name or your server's hostname) []:dunno.dyndns.info
31 Email Address []:webmaster@meine-domain.de
32 [...]
33 [booboo@dunno ca]$ openssl ca -config ./ca.cnf -days 730 -in dunno.
   dyndns.info.csr -out dunno.dyndns.info.crt
34 Using configuration from ./ca.cnf
35 Enter pass phrase for /home/booboo/ca/ca.meine-domain.de.key:********
36 Check that the request matches the signature
37 Signature ok
38 Certificate Details:
39     Serial Number: 1 (0x1)
40     Validity
41       Not Before: Apr 18 15:43:35 2009 GMT
42       Not After : Apr 18 15:43:35 2011 GMT
43     Subject:
44       countryName            = DE
46       stateOrProvinceName    = Bayern
47       organizationName       = BooBoo
48       commonName             = dunno.dyndns.info
49       emailAddress           = webmaster@meine-domain.de
50     X509v3 extensions:
51       X509v3 Basic Constraints:
52         CA:FALSE
53       Netscape Comment:
54         OpenSSL Generated Certificate
55       X509v3 Subject Key Identifier:
56         9E:B0:98:FB:CB:34:34:9F:15:AC:6E:F5:91:0D:2A:A1:91:E5:35:1E
57       X509v3 Authority Key Identifier:
58         keyid:73:FA:ED:48:EF:7E:4A:EA:F6:E2:78:EB:A4:2C:9E:A4:46:98:51
59 Certificate is to be certified until Apr 18 15:43:35 2011 GMT (730 days)
60 Sign the certificate? [y/n]:y
61 1 out of 1 certificate requests certified, commit? [y/n]y
62 Write out database with 1 new entries
63 Data Base Updated
64 [booboo@dunno ca]$ openssl genrsa -des3 -out hans.meier.meine-domain.de.key 1024
65 [booboo@dunno ca]$ openssl req -config ./ca.cnf -new -key hans.meier
   .meine-domain.de.key -out hans.meier.meine-domain.de.csr
66 [...]
67 Common Name (eg, your name or your server's hostname)
68 []:hans.meier.meine-domain.de
69 Email Address []:hans.meier@meine-domain.de
70 [...]
71 [booboo@dunno ca]$ openssl ca -config ./ca.cnf -days 730 -in hans.meier.meine-domain.de.csr -out hans.meier.meine-domain.de.crt
72 [...]
73 [booboo@dunno ca]$ openssl pkcs12 -export -in hans.meier.meine-domain.de.crt -inkey hans.meier.meine-domain.de.key -certfile ca.meine-domain
   de.crt -out hans.meier.meine-domain.de.p12
74 Enter pass phrase for hans.meier.meine-domain.de.key:********
75 Enter Export Password:********
76 Verifying - Enter Export Password:********

Absichern mit HTTPS

Im ersten Schritt richtet der Admin auf Apache einen »VirtualHost« ein, der HTTPS spricht. Die Installation des entsprechenden Moduls »mod_ssl« liefert meist eine Datei mit, die eine brauchbare Konfiguration für diesen Zweck enthält und nur noch ein wenig anzupassen ist. Eine minimale Konfiguration zeigt das Listing 1.

Gegenüber dem Standardsetup ist der Servername auf den von außen sichtbaren DNS-Namen abzuändern. Zusätzlich sind die Verweise auf das vorher erzeugte Server-Zertifikat (siehe Kasten “Zertifikate erstellen”) und den zugehörigen privaten Schlüssel zu modifizieren. Außerdem kann der Admin gleich noch die SSL-Cipher-Suite anpassen, sodass nur noch starke Verschlüsselungsverfahren im SSL-Handshake aushandelbar sind. Danach ist der Apache Webserver neu zu starten.

dir       = /home/booboo/ca
certificate   = $dir/ca.meine-domain.de.crt
private_key   = $dir/ca.meine-domain.de.key

Jetzt ist es an der Zeit, den Zugriff per Browser mit HTTPS zu testen. Dabei kommt noch eine Zertifikatswarnung, da der Browser der eigenen CA im Moment noch nicht vertraut. Deshalb bindet der User »ca.meine-domain.de.crt« im Browser ein. In Firefox 3 findet sich der richtige Menüpunkt dafür unter »Extras | Einstellungen… | Erweitert | Verschlüsselung | Zertifikate anzeigen | Zertifizierungsstellen | Importieren«. Diesem Zertifikat kann er dann ruhigen Gewissens und für alle Verwendungszwecke vertrauen.

Nach dem nächsten Restart des Browsers sollte der Zugriff ohne Zertifikatswarnung funktionieren. Hat das geklappt, ist die Konfiguration der Client-Authentifizierung an der Reihe. Dazu fügt man folgende Zeilen innerhalb des gerade erzeugten Virtual-Host-Abschnitts ein:

SSLCACertificateFile /etc/httpd/conf/ssl.crt/ca.meine-domain.de.crt 
<Location />
  Order allow,deny
  Allow from all
  SSLVerifyClient require
</Location>

Jetzt ist erneut ein Restart fällig. Ein Zugriff per Browser sollte danach zunächst nicht mehr möglich sein. Anschließend importiert man das Client-Zertifikat samt privatem Schlüssel (»hans.meier.meine-domain.de.p12«) in den Browser, ebenfalls im Zertifikatsmanager unter »Ihre Zertifikate | Importieren«. Dabei ist das zuvor beim Erstellen vergebene Passwort nötig. Firefox übernimmt den Passwortschutz aber leider nicht.

Damit das Zertifikat nicht vollkommen ungeschützt ist, empfiehlt es sich, ein Master-Passwort zu setzen. Das geht unter »Extras | Einstellungen… | Sicherheit«. Dieses Paswort fragt der Browser dann immer ab, bevor er das Client-Zertifikat benutzt. Der Zugriff auf den HTTPS-Server sollte wieder funktionieren.

Wer unterwegs via Browser und HTTPS auf einen dafür vorbereiteteten entfernten Rechner zugreifen will, braucht ebenfalls immer das Client-Zertifikat. Auch dafür dürfte meist ein USB-Stick die beste Lösung sein.

Um auf dem Client-Rechner, auf dem der Reisende meist nur Gast ist, den Browser nicht komplett umkonfigurieren zu müssen, eignet sich für die meist anzutreffenden Windows-Rechner die portable Version von Firefox [7]. Sie lässt sich auf dem Stick installieren, sodass sie direkt von dort startbar ist. Diese Version konfiguriert der User- wie oben beschrieben – mit CA-Zertifikat, Client-Zertifikat und Master-Passwort. Die Startseite stellt er am besten gleich auf die URL des entfernten Rechners ein. Jetzt muss er unterwegs nur noch irgendeinen Rechner mit Internetzugang finden, den USB-Stick anstecken, im Explorer auf »FirefoxPortable.exe« doppelklicken und im Browser das Master-Passwort eingeben. Schon ist er verbunden.

Wer unterwegs mit Linux arbeitet, muss bei dieser Lösung kleine Abstriche machen. Eine gut gepflegte und immer aktuelle portable Firefox-Version für Linux gibt es derzeit nicht. Prinzipiell ist das Problem aber durchaus lösbar, wie [10], [11] zeigen.

01 auth SHA1
02 # nur Zertifikate erlauben, deren CN passt
03 tls-remote hans.meier.meine-domain.de
04 # IP-Adresse, Port und Protokoll fuer Listener
05 local 192.168.0.3
06 port 1194
07 proto udp
08 # Interface
09 dev tun0
10 # CA-Zertifikat
11 ca ca.meine-domain.crt
12 # Server-Zertifikat und -Key
13 cert dunno.dyndns.info.crt
14 key key/dunno.dyndns.info.key
15 # Diffie hellman parameter
16 dh dh1024.pem
17 # VPN-Subnetz fuer Client-IP-Adressen: ein freies Subnetz verwenden
18 server 192.168.29.0 255.255.255.0
19 # Zuordnung Client zu IP wird hier gespeichert
20 ifconfig-pool-persist ipp.txt
21 # push: Optionen, die dem Client beim Verbindungsaufbau mitgegeben werden
22 # Default-Gateway auf das VPN setzen
23 push "redirect-gateway"
24 # zu verwendender DNS-Server, falls im Heim-Netz vorhanden
25 push "dhcp-option DNS 192.168.27.3"
26 # Praefix, fuer Hostnames ohne Domain
27 push "dhcp-option DOMAIN home.meine-domain.de"
28 # Keep alive pings ueber VPN schicken
29 keepalive 10 120
30 # Daten-Kompression im VPN einschalten
31 comp-lzo
32 # Maximale Anzahl gleichzeitiger Clients
33 max-clients 10
34 # Status-File
35 status openvpn-status.log
36 # Log-Level (0-9)
37 verb 3

OpenVPN

Die dritte Variante verwendet OpenVPN. Der Client ist zwar sowohl unter Linux als auch unter Windows verfügbar, allerdings erfordert er immer eine Installation. Für Systeme, auf denen der Anwender nur Gast ist, eignet sich diese Methode also eher nicht. Für moderne Nomaden, die ihr Net- oder Notebook immer dabei haben und sich unterwegs via UMTS, GPRS oder einfach nur per WLAN ins Internet einklinken, hat diese Variante allerdings Vorteile: Steht die VPN-Verbindung erst einmal, ist das mobile Gerät virtuell ins entfernte LAN integriert. Ohne weitere Konfiguration lassen sich also sofort alle dortigen Netzwerkdienste nutzen.

Die IP-Adressen sind dabei die gleichen wie bei einer direkten Verbindung ins LAN. Umkonfigurieren ist also nicht notwendig. Das Beispiel setzt wieder auf X.509-Zertifikate (siehe Kasten “Zertifikate erstellen”) zur Authentifizierung der Nutzer und zur Verschlüsselung der Verbindung. OpenVPN ist in den meisten Distributionen bereits enthalten und über das Paketmanagement schnell installiert. Ein kommentiertes Beispiel für ein Server-Konfigurationsfile findet sich in Listing 3. Den Daemon startet »/etc/init.d/openvpn start«.

Der Client verwendet in seiner Konfiguration grundsätzlich die gleichen Schlüsselwörter (Listing 4). Anschließend baut »/usr/sbin/openvpn –config /etc/openvpn/dunno.dyndns.info.c2n.conf« die Verbindung auf. Das Terminalfenster lässt der Admin offen, solange er die VPN-Verbindung benötigt, und drückt dann dort [Ctrl]+[C], um die Verbindung zu beenden. Selbstverständlich ist OpenVPN deutlich mächtiger, als dieses kurze Beispiel zeigt. Die im Internet verfügbaren Dokumentation, etwa [8], erklärt Weiterführendes.

01 cd /etc/openvpn
02 remote dunno.dyndns.info
03 port 1194
04 proto udp
05 dev tun0
06 # Server darf Einstellungen per push setzen
07 pull
08 # Configuration fuer Client
09 tls-client
10 auth SHA1
11 ca ca.meine-domain.de.crt
12 cert hans.meier.meine-domain.de.crt
13 key key/hans.meier.meine-domain.de.key
14 comp-lzo yes
15 verb 3
16 # spezielles Script von Ubuntu, um resolv.conf bei Verbindungsauf-
17 # und -abbau dynamisch anzupassen
18 up /etc/openvpn/update-resolv-conf
19 down /etc/openvpn/update-resolv-conf
20 tls-remote dunno.dyndns.info

Knoppix auf dem Stick

Wer eine Lösung sucht, die ohne Notebook funktioniert, andererseits aber Sicherheitsbedenken hat, weil Windows-Rechner, die er möglicherweise temporär verwenden könnte, häufig mit Schädlingen infiziert sind, der zieht vielleicht eine weitere Lösung in Betracht: Knoppix [9] in der aktuellen Version 6.0.1 lässt sich sehr einfach auf einem USB-Stick installieren und dort anpassen. Alle bisher vorgestellten Lösungen sind auch mit dieser Distribution realisierbar.

Nachteile: Nicht alle PCs booten von USB-Sticks und der Zugriff auf das Internet ist jeweils separat zu konfigurieren. Solange der PC per Ethernet mit einem DSL-Router verbunden ist, funktioniert das aber meist automatisch.

Lösungen zur sicheren Authentifizierung mit Hilfe kryptographischer Mittel sind unter Linux reichlich vorhanden. Auch Clients mit Windows lassen sich gut gesichert anbinden. Welche der hier vorgestellten Methoden die beste ist, richtet nach dem Einsatzzweck. Solange von außen nur die so gesicherten Dienste zugänglich sind, braucht niemand Bedenken zu haben. (jcb)