SSH: Verschlüsselter Fernzugriff

(3016 Worte insgesamt im Text)
(21485 mal aufgerufen)  Druckerfreundliche Ansicht [1]

Letzte Änderung: 12.01.2007

Inhalt

Ein Linux-Server ermöglicht Ihnen u.a. auch die Fernwartung des Servers über verschlüsselte Verbindungen. Wir wollen nun einmal zeigen, welche Möglichkeiten und zusätzliche Absicherungsmaßnahmen sich speziell bei SSH-Verbindungen ergeben.


SSH-Server und SSH Programm

Zunächst einmal sollten Sie wissen, dass es sowohl einen SSH-Server (welcher im Allgemeinen unter root-Rechten läuft) wie auch ein SSH-Programm gibt, welches jeder Nutzer einsetzen kann. Der Serverdienst sshd wird Normalerweise immer gestartet. Er wird durch die Datei sshd_config im Verzeichnis /etc/ssh konfiguriert. Wir werden später auf diese Datei zurück kommen.

Zusätzlich gibt es noch einen sicheren FTP-Server, welcher eine verschlüsselte Datenübertragung ermöglicht. Dieser wird über den SSH-Server bei Bedarf gestartet und nennt sich sftp-server.

Das Programm, welches Sie unter Linux nutzen um eine verschlüsselte Verbindung aufzubauen, wird mit dem Befehl ssh aufgerufen. Zusätzlich wird als Parameter noch der Rechnername erwartet. Weitere Parameter wie z.B. der Nutzername auf dem fremden System, bestimmte Portnummern, Kompression oder X-forwarding sind optional.

Besonders bei der verwendeten Kompressionsstärke sollten Sie später einen Kompromiss zwischen der verfügbaren Bandbreite und der Rechenleistung der beteiligten Computer finden. Heutige Computer sind aber meist so leistungsstark, dass die zusätzliche Belastung durch Kompression meist unerheblich ist - die eingesparte Bandbreite während der Übertragung kann aber durchaus nützlich sein.

Auch hier gibt es noch zusätzliche Programme wie etwa sftp -- den sicheren FTP-Client -- oder scp -- das "secure copy". Hiermit können Sie -- ähnlich wie mit dem normalen cp-Befehl -- Dateien und sogar ganze Verzeichnisse geschützt auf ein anderes System kopieren.


SSH-Verbindungen unter Linux

Das Clientprogramm SSH

Für einen einfachen Verbindungsaufbau genügt dann von einem Linux-Client aus der Befehl ssh root@myip.dyndns.org.

Verbindungsaufbau

Der eigentliche Verbindungsaufbau findet dann zunächst über asymmetrische Verschlüsselung statt. Jeder SSH-Server benötigt zu seinem Betrieb ein solches Schlüsselpaar, welches aus einem öffentlichen und einem privaten Schlüssel besteht.

Empfängt der SSH-Server eine Verbindungsanfrage, dann sendet er seinen öffentlichen Schlüssel an den Client. Hat dieser noch keinen Schlüssel vom Server erhalten wird der Nutzer gefragt, ob der öffentliche Schlüssel gespeichert werden soll.

Anfrage zur Speicherung des öffentlichen Serverschlüssels

The authenticity of host 'ssh-server.example.com (10.10.0.14)' can't be established.
RSA key fingerprint is c7:08:14:35:c0:86:7b:a5:b1:b6:4f:1c:e4:73:bc:0f.
Are YOU sure you want to continue connecting (yes/no)?

Wenn Sie sicher sind, dass der übertagene, öffentliche Schlüssel wirklich der Schlüssel des angewählten Servers ist, dann bestätigen Sie die Frage mit einem ausgeschriebenen "yes" - andere Eingaben führen hier zum Abbruch der Verbindung. Wenn Sie unsicher sind, sollten Sie den angegebenen Fingerprint mit der Ausgabe des am Server eingegebenen Befehls ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub überprüfen. Diese müssen identisch sein.

Nun wird der öffentliche Schlüssel des Servers auf dem Client im Heimatverzeichnis des Benutzers unter .ssh/known_hosts gespeichert. Bei allen späteren Verbindungen wird der ssh-Client nur noch überprüfen, ob sich der Schlüssel geändert hat und Sie ggf. mit einer Warnmeldung darauf hinweisen.

Man-in-the-middle Angriff

Sollten Sie eine solche Warnung beim Versuch eines Verbindungsaufbaus erhalten, dann sollten Sie zunächst sicherstellen, dass sich das Schlüsselpaar des Servers geändert hat und dann ggf. den zu diesem Server gehörenden Eintrag in der Datei .ssh/known_hosts löschen. Vorher ist aus Sicherheitsgründen keine Verbindungsaufnahme möglich, da hier ein sogenannter "man in the middle"-Angriff stattfinden könnte, bei welchem sich ein anderer Rechner als der eigentlich angewählte Server ausgibt. Wenn sich wirklich das Schlüsselpaar des Servers gendert haben sollte, müssen Sie nach dem Löschen der entsprechenden Zeile den öffentlichen Schlüssel erneut importieren, wie weiter oben beschrieben.
Sie sollten also nach dem einmaligen Austausch des Schlüssels zukünftig nur noch nach dem Passwort für root gefragt werden, da Sie durch das vorangestellte "root@" dem Server mitgeteilt haben, dass Sie sich mit diesem Nutzernamen am System anmelden möchten. Dasselbe Verhalten erreichen Sie übrigens auch, wenn Sie den folgenden Befehl aufrufen: ssh -l root myip.dyndns.org. Wenn Sie den Benutzernamen weglassen, wird der Client versuchen, Sie mit dem Nutzernamen des aktuellen Systems anzumelden. Nun können Sie auf der Konsole des Servers arbeiten.

Im zweiten Schritt möchten wir aber auch mal ein grafisches Programm starten, um z.B. im Konqueror die Homeverzeichnisse zu kontrollieren oder ein wenig zu surfen. Geben Sie dazu auf Ihrem heimischen System den Befehl ssh -X root@myip.dyndns.org ein. Durch das -X wird X11-Forwarding aktiviert. Damit erzeugt das Programm ssh ein Pseudo-Terminal auf dem Zielrechner und setzt die Umgebungsvariable DISPLAY entsprechend. Die graphischen Ausgaben eines Programms werden dann von ssh verschlüsselt weitergeleitet und erscheinen auf dem Clientrechner.

Nach der nun schon bekannten Eingabe des Passworts können Sie nun also auch grafische Programme starten - z.B. den Konqueror mit dem Befehl konqueror. Erwarten Sie aber bitte keinen Geschwindigkeitsrausch - besonders nicht bei Wählverbindungen!

Die Geschwindigkeit können Sie aber durch Kompression erhöhen. Hierbei wird ein ähnlicher Algorithmus wie für gezipte Dateien verwendet. ähnlich dem dortigen Verfahren können Sie auch hier den Grad der Kompression angeben. Wiederholen Sie also die vorherige Anmeldung - nur schalten Sie diesmal mit dem zusätzlichen Parameter "-C" die Kompression ein:

ssh -C -X root@myip.dyndns.org
Vergleichen Sie die Geschwindigkeit, mit der der Konqueror nun startet und arbeitet.

Wenn Sie eine stabile Verbindung eingerichtet haben, können Sie die Einstellungen in einer Konfigurationsdatei ablegen und müssen so nicht bei jeder erneuten Verbindung wieder alle Optionen eingeben. Jeder Nutzer kann so in seinem Heimatverzeichnis im Unterverzeichnis .ssh eine Datei config anlegen und dort entweder für einzelne Rechner, ganze Netzwerke oder global die Optionen für eine Verbindung einstellen.

So könnte eine config-Datei einige globale Optionen konfigurieren, so dass z.B. X11-Forwarding aktiviert ist, als Protokoll das sicherere Protokoll 2 verwendet wird, der Nutzernamen auf dem fremden System vorgeben oder Kompression aktiviert wird.

Host *
StrictHostKeyChecking ask
ForwardX11 yes
UseRsh no
FallBackToRsh no
Compression yes
BatchMode no
KeepAlive yes
User root
Protocol 2

Beachten Sie bitte, dass die hier gezeigten Einstellungen für alle künftigen Verbindungen gelten. Ausnahmen für bestimmte Rechner legen Sie vor diesem globalen Eintrag fest oder geben wieder die Parameter auf der Kommandozeile an. Beim Vorhandensein der oben gezeigten Datei brauchen Sie nun nur noch den Befehl:

ssh myip.dyndns.org
eingeben und Sie werden so mit dem Server verbunden als wenn Sie "ssh -C -X -o protocol 2 root@myip.dyndns.org" eingegeben hätten.

...und wenn Sie nur einen einzelnen Befehl absetzen wollen, dann d�rfte

ssh root@myip.dyndns.org ls /tmp
für Sie interessant sein. Sie können also den auszuführenden Befehl einfach nach der Angabe des Zielhosts angeben. SSH kehrt dann nach der Ausführung des Befehls direkt zurück. Die Ausgaben des Befehls landen aber in ihrer lokalen Shell.

Schlüssel automatisch laden

Der Mensch ist faul - und Linuxer sind wahrscheinlich die faulsten... icon_wink
Deshalb ist es einem Linux-Nutzer natürlich viel zu kompliziert, wenn er jedesmal sein Passwort für den SSH-Key eingeben muss. Entsprechend kommt unter Linux nun der sog. ssh-agent ins Spiel. Dieser dient quasi als "Cache" und hält den Schlüssel offen, so dass nur ein einziges Mal während einer Sitzung nach dem Passwort gefragt wird. Wenn man dies nun noch mit einem weiteren Programm namens keychain kombiniert, kann man auch noch beliebig viele Terminals während einer Sitzung öffnen.

#!/bin/bash
if [ -x /usr/bin/keychain ]; then
/usr/bin/keychain ~/.ssh/id_rsa
else
eval ssh-add ~/.ssh/id_rsa
fi
Mehr dazu demnächst...

Secure Copy

Das Programm scp ist eine Mischung aus SSH und CP. Wollen Sie also z.B. Datei test.txt von daheim auf den Server kopieren, dann geben Sie den folgenden Befehl ein scp test.txt root@myip.dnydns.org:/root/ Damit kopieren Sie die Datei in das Heimatverzeichnis von root. Sie können auch mit Wildcards arbeiten:

scp te*.txt root@myip.dnydns.org:/root/

kopiert alle Dateien, welche mit "te" anfangen und mit ".txt" aufhören, ins Heimatverzeichnis von root. Rekursives Kopieren funktioniert mit der Option "-r":

scp -r /root/* root@myip.dnydns.org:/root/

Beachten Sie aber bitte, dass bei allen Kopiervorgängen alle auf dem Zielsystem vorhandenen Dateien überschrieben werden! Prüfen Sie also vorher auf dem anderen Rechner, ob nicht fälschlicherweise Dateien überschrieben werden könnnen.

Auch scp bietet Möglichkeiten zur Komprimierung der Daten oder zur Verwendung eines anderen Ports (normalerweise wird auch hier immer Port 22 genutzt). Mit scp -C -P 222222 test.txt root@myip.dyndns.org:/root/ kopieren Sie also die Datei test.txt verschlüsselt und komprimiert über den Port 222222 auf den Server ins Heimatverzeichnis von root.

Mehr Informationen zum Programm scp erhalten Sie mit dem Befehl man scp.

Secure FTP

Das Programm sftp dient als sicherer Ersatz für FTP. Wie bei einer normalen FTP-Verbindung können Sie verschiedene Dateien und Verzeichnisse zwischen den beiden Zielsystemen hin- und herkopieren, löschen oder verschieben. Die Daten werden dabei ebenfalls über die verschlüsselte Verbindung übertragen und auf Wunsch auch während der Übertragung komprimiert. Mit SFTP-fähigen Clients können Sie also wie mit einem üblichen FTP-Client arbeiten - nur sind hier die Daten und Passörter im Gegensatz zu normalen FTP geschützt.

Mit dem Befehl

sftp -C root@myip.dyndns.org
starten Sie eine verschlüsselte und komprimierte FTP-Sitzung, die Sie mit dem Befehl quit wieder verlassen können.

Auch hier liefert der Befehl man sftp weitere Informationen zur Benutzung des Programms. Hier werden auch die einzelnen Befehle beschrieben, die während einer SFTP-Sitzung genutzt werden können.


Der SSH Server

Wir wollen uns hier nur mit den für den Alltag relevanten Konfigurationsmöglichkeiten des SSH-Servers beschäftigen. Weitere Informationen zu den einzelnen Optionen entnehmen Sie bitte der Manpage zur Konfigurationsdatei (man sshd_config).

Alle Einstellungen nehmen Sie in der Datei /etc/ssh/sshd_config vor. Bitte erstellen Sie vor �nderungen immer eine Sicherheitskopie der laufenden Konfiguration!

Zusätzlich sollten Sie sich ganz genau überlegen, ob Sie sich wirklich über SSH auf dem Server anmelden sollen, wenn Sie die Konfiguration dieses Servers bearbeiten. Der Server muss nach jeder Änderung in der Konfigurationsdatei die Konfiguration neu laden. Dies betrifft zwar keine laufenden Sitzungen - aber im schlimmsten Fall "sägen Sie sich genau den Ast ab, auf welchem Sie gerade sitzen".

Editieren Sie die Datei mit einem beliebigen Editor ihrer Wahl, z.B. kate oder dem vi. Zunächst können Sie den Server ein wenig absichern, indem Sie die Zeile #Protocol 2,1 editieren. Indem Sie die # und die 1 entfernen nimmt der Server zukünftig nur noch Verbindungsanfragen von Clients entgegen, welche das sichere Protokoll 2 verwenden. Die Zeile sieht anschließend so aus: Protocol 2

Wenn Sie eine statische IP-Adresse besitzen sollten können Sie sogar noch weitere Einschränkungen vornehmen und hier die Adresse eintragen von welcher der Server zukünftig nur noch Verbindungen akzeptieren soll.

Weiter unten in der Datei sshd_config können Sie von der Passwort-Authentifizierung auf eine Authentifizierung mit PublicKey, Kerberos oder anderen Verfahren umstellen. Damit entfällt für Hacker die Möglichkeit eines Wörterbuchangriffs auf den Server. Im weiteren Verlauf dieser Beschreibung wird die Umstellung auf das PublicKey-Verfahren beschrieben. Für andere Verfahren lesen Sie bitte die Manpage mit dem Befehl man sshd_config.

Dazu muss aber zunächst einmal sichergestellt sein, dass die anvisierte Authentifizierungsmethode auch funktioniert. Denn für die Authentifizierung mit PublicKey-Verfahren benötigt zunächst jeder Benutzer, welcher sich später auf den Server anmelden können soll, ein Schlüsselpaar.


ssh-keygen - Schlüsselpaar erzeugen

Das mit ssh-keygen erzeugte Schlüsselpaar dient später als einzige Authorisierungsquelle. Sie sollten also die erzeugten Schlüssel sicher verwahren und niemanden Zugriff darauf gestatten!

Erzeugen Sie mit dem Befehl

ssh-keygen -t rsa -b 2048
ein 2048 Bit langes RSA-Schlüsselpaar. Sie müssen anschließend den Pfad für die späteren Schlüsseldateien angeben [Enter file in which to save the key (/home/hugo/.ssh/id_rsa):]. Sie können hier die Vorgabe verwenden oder sich auch einen sprechenden Namen für Ihr Schlüsselpaar überlegen. Geben Sie dann aber den vollen Pfad zur Datei an. Für das Beispiel werden die Vorgabe einfach übernommen indem [Enter] gedrückt wird.

Nun werden Sie zweimal nach einer "passphrase" gefragt. Wenn Sie an dieser Stelle einfach [Enter] drücken, wird ein Schlüssel ohne Passwort generiert - dies sollten Sie aus Sicherheitsgründen nicht tun, sondern sich wirklich ein langes Passwort überlegen. Zur Sicherheit müssen Sie diese Passphrase erneut eingeben, bevor das Schlüsselpaar erzeugt wird.

Als Ergebnis sollten Sie zwei Dateien erhalten:

id_rsa Dies ist die private Schlüsseldatei.
id_rsa.pub Dies ist der öffentliche Schlüssel

Die Datei mit der Endung "pub" dürfen Sie an alle weitergeben.

Den privaten Schlüssel id_rsa sollten Sie - auch wenn er durch die Passphrase geschützt ist - nicht aus der Hand geben!

Hinterlegt man nun den eigenen öffentlichen Schlüssel auf dem Server in der Datei ~/.ssh/authorized_keys, so ist es möglich, sich mittels des PublicKey-Verfahrens am Server anzumelden.


Schlüssel hinterlegen

Wenn Sie sich zukünftig als root am Server anmelden und dabei das PublicKey-Verfahren nutzen möchten, müssen Sie nun Ihren öffentlichen Schlüssel in die Datei authorized_keys im Unterverzeichnis .ssh des Heimatverzeichnisses von root kopieren.

Kopieren Sie dazu den öffentlichen Schlüssel auf eine Diskette, die Sie dann am Server mounten oder nutzen Sie den Befehl scp, um den Schlüssel direkt auf den Server zu kopieren. Das Einfügen in die Datei authorized_keys (die Datei existiert am Anfang noch nicht) geschieht am elegantesten mit dem Befehl:

cat id_rsa.pub >> /root/.ssh/authorized_keys

- wenn sich der öffentlichen Schlüssel im aktuellen Verzeichnis befindet.

Eine weitere, elegant Möglichkeit bietet der Befehl ssh-copy-id. Bei diesem Befehl handelt es sich um ein Shell-Skript, welches den öffentlichen Schlüssel auf einem fremden Rechner hinterlegen soll und damit genau das tut, was wir im Absatz vorher per Hand gemacht haben. (Da der Befehl allerdings nicht unter allen Systemen verfügbar ist, ist die manuelle Methode sicherlich auch nicht schlechter.) Um den Schlüssel id_rsa.pub in der Datei .ssh/authorized_keys des Benutzers root auf dem Server myip.dyndns.org zu hinterlegen, geben Sie als normaler Nutzer den folgenden Befehl ein:

ssh-copy-id -i ~/.ssh/id_rsa.pub root@myip.dyndns.org

Geben Sie anschließend das Passwort von root ein und ssh-copy-id nimmt ihnen die weitere Arbeit ab.

Um Sicherheitslücken zu vermeiden, sollten Sie darauf achten, dass die Datei authorized_keys nur vom jeweiligen Benutzer lesbar ist. (Der SSH-Server achtet übrigens auch darauf und schaltet auf Passwortanmeldung um, wenn die Rechte dieser Datei nicht stimmen! Wenn der Serveradmin dann eine Anmeldung mit Passwort nicht zuläßt stehen Sie vor einem verschlossenem System - ohne Schlüssel.) Dies stellen Sie mit dem Befehl sicher:

chmod 600 authorized_keys

Nun sollten Sie sich über das PublicKey-Verfahren am Server anmelden können.

Hierfür sind die folgenden normalerweise auskommentierten Werte (dies sind die Standardwerte) in der Datei /etc/ssh/sshd_config verantwortlich:

RSA-Authentifizierung mittels PublicKey-Verfahren ist also per default aktiviert (und steht in der Datei noch vor der Passwort-Authentifizierung) und der SSH-Server sucht die öffentlichen Schlüssel im Homeverzeichnis des entsprechenden Nutzers in der Datei .ssh/authorized_keys.

Sie sollten also nach einem ssh -X -C root@myip.dyndns.org nach Ihrer Passphrase für den Schlüssel und nicht mehr nach dem Passwort von root gefragt werden.

Nun kann am SSH-Server auch die Authentifizierung mittels Passwort abgeschaltet werden. Hierzu muss in der Datei /etc/ssh/sshd_config die Zeile

#PasswordAuthentication yes
geändert werden in
PasswordAuthentication no

Anschließend sollte der SSH-Server noch von dieser Änderung durch den Befehl rcsshd reload erfahren. Nun werden Benutzer ohne PublicKey zwar immer noch nach dem Passwort gefragt - aber anmelden kann man sich auch mit dem korrekten Passwort eines Nutzers nicht mehr. Nur noch Nutzer mit einem auf dem System hinterlegten PublicKey haben Zugang zum Server.


SSH-Verbindung unter Windows

Unter Windows benötigen Sie die beiden Programme "Putty [14]" und "Puttygen [15]", welche Sie hier herunterladen können.

Schlüsseldatei für Putty [16] nutzbar machen

Um die Schlüsseldatei id_dsa mit Putty überhaupt nutzen zu können, benötigen Sie das Programm "Puttygen [17]".

Nach dem Start drücken Sie auf "Load" um die Datei "id_dsa" zu laden.

Startseite von Puttygen

Anschließend geht es weiter mit der Suche nach der Datei. Sie sollten die Datei auf Diskette, USB-Stick oder CD speichern und auf das Speichermedium gut Acht geben!

Schlüsseldatei suchen

Im nächsten Schritt erzeugen Sie jetzt aus der Datei einen Schlüssel, mit welchem Putty etwas anfangen kann. Das geht mit einem Klick auf "OK" ganz schnell...

Schlüsseldatei erzeugen

Jetzt müssen Sie die neu erzeugte Datei für Putty nur noch abspeichern. Dazu wählen Sie im Hauptfenster Save private-key und wählen am besten wieder das transportable Speichermedium auf welchem sich auch schon die andere Schlüsseldatei befindet. Die Parameter können Sie ignorieren, da Puttygen nur den schon vorhandenden Schlüssel angepaßt und keinen neuen generiert hat. Dieser vorhandene Schlüssel sollte sowieso ein RSA-Schlüssel der Version 2 sein...

Parameter für den neuen Schlüssel

Jetzt geht es ans Abspeichern. Um es sich bequem zu machen geben Sie auch hier keine Passphrase ein.

kein Passwort

Vergeben Sie einen schönen Namen für die neue Datei...

neue Datei speichern

...und schon sind Sie mit den Vorarbeiten fertig.


Putty konfigurieren

Um mit Putty in den Genuß der passwortlosen Authentifizierung zu kommen müssen Sie noch ein paar Angaben in Putty selbst machen. So müssen Sie u.a. den Speicherort der Schlüsseldatei angeben - sonst kann Putty sie nicht finden. Das geht unter "Connection" >> "SSH" >> "Auth" >> "Private key file for authentication":

Speicherort der Schlüsseldatei angeben

Weiter geht es mit dem passenden Nutzernamen. Diesen stellen Sie unter "Connection" >> "Auto-Login Username" ein:

Auto-Login Nutzername einstellen

Um sicherzustellen, dass Putty und der Server die Verbindung mit der neuen Verschlüsselung (Version 2) verschlüsseln, weisen Sie Putty entsprechend an.

Nutzername

Jetzt geht es ans Abspeichern der Einstellungen, damit Sie sie nicht jedes Mal wieder eingeben müssen. Geben Sie vorher noch die richtige IP-Adresse des Servers und den Port an. Dann brauchen Sie sich wieder nur einen aussagekräftigen Namen zu überlegen und auf "Save" zu drücken.

Achten Sie allerdings bei dynamischer IP-Vergabe darauf, dass Sie bei zukünftigen Sitzungen die IP wieder anpassen müssen!
Wählen Sie dazu die gespeicherte Sitzung, drücken Sie auf "Load" und ändern Sie dann einfach nur die IP-Nummer.

Bei einer festen IP oder der Fernwartung über DynDNS können Sie selbstverständlich auch den Namen eintragen.

IP, Protokoll und Namen eingeben

Jetzt fehlt nur noch eine passende Verknüpfung auf dem Desktop und dem automatisierten Anmelden steht nichts mehr im Wege.

Die ganz Bequemen können unter den "Eigenschaften" der Verknüpfung hinter einem @ noch den gespeicherten Namen angeben - dann nimmt Putty diese Werte automatisch beim Start als Parameter an und nach dem Doppelklick auf das Ikon ist man sofort "drin".

automatisierte Anmeldung

Vielen Dank für Teile der ursprünglichen Anleitung und für den Tip mit dem @ an Lutz Worch und Helmut Hullen!




  

[ zurück zu Linux allgemein [18] | Index [19] ]

Kommentare

Einen Kommentar hinzufügen


Links
  [1] http://www.linux-schulserver.de/index.php?name=Sections&req=viewarticle&artid=3&allpages=1&theme=Printer
  [2] http://www.linux-schulserver.de/#sshinhalt
  [3] http://www.linux-schulserver.de/Sections-article3-p2.phtml
  [4] http://www.linux-schulserver.de/Sections-article3-p3.phtml
  [5] http://www.linux-schulserver.de/Sections-article3-p3.phtml
  [6] http://www.linux-schulserver.de/Sections-article3-p4.phtml
  [7] http://www.linux-schulserver.de/Sections-index-req-viewarticle-artid-3-page-4.phtml#sftp
  [8] http://www.linux-schulserver.de/Sections-article3-p5.phtml
  [9] http://www.linux-schulserver.de/Sections-article3-p6.phtml
  [10] http://www.linux-schulserver.de/Sections-article3-p7.phtml
  [11] http://www.linux-schulserver.de/Sections-article3-p8.phtml
  [12] http://www.linux-schulserver.de/Sections-article3-p8.phtml
  [13] http://www.linux-schulserver.de/Sections-article3-p9.phtml
  [14] http://the.earth.li/%7Esgtatham/putty/latest/x86/putty.exe
  [15] http://the.earth.li/%7Esgtatham/putty/latest/x86/puttygen.exe
  [16] http://the.earth.li/~sgtatham/putty/latest/x86/putty.exe
  [17] http://the.earth.li/%7Esgtatham/putty/latest/x86/puttygen.exe
  [18] http://www.linux-schulserver.de/index.php?name=Sections&req=listarticles&secid=5
  [19] http://www.linux-schulserver.de/index.php?name=Sections