Ein Tunnel ist grundsätzlich eine Röhre, die zwei Punkte in Verbindung bringt. Bei der SSH bedeutet dies die Verbindung eines SSH-Clients zu einem SSH-Server in einer Weise, daß darüber keine direkte Terminalverbindung (shell login) erfolgt, sondern diese Verbindung von anderen Programmen aus genutzt werden kann.

Der Tunnel muß entweder auf der Server-Seite der Verbindung permanent bereitgestellt oder von der Client-Seite aus initiiert werden.

Auf beiden Seiten sind zueinander kompatible Versionen der SSH erforderlich. Dazu genügt es im Normalfall, wenn auf beiden Seiten eine SSH der Version 1.x oder 2.x vorhanden ist. Die Versionen 1.x und 2.x unterscheiden sich in der Protokollsicherheit und insbesondere auch in den zugrunde liegenden Lizenzbestimmungen - die Version 2.x darf nicht mehr für gewerbliche Zwecke kostenlos verwendet werden.

Für die Authentifzierung eines Benutzers (d. h., der Feststellung, ob ein Benutzer tatsächlich der ist, für den er sich ausgibt), ist der klassiche Weg ein Passwort. Darüber hinaus kann man die Passworteingabe bei manchen Diensten umgehen, in dem man serverseitig vorgibt, welche Benutzer von wo aus freien Zugang bekommen sollen - aber das ist z. B. bei Terminalverbindungen nicht immer sinnvoll und auch nur machbar, wenn die IP-Adresse der Seite, die die Verbindung initiiert, bekannt und statisch ist (z. B. rlogin - Datei .rhosts), für eine Umgebung mit dynamischer Adressvergabe ist dies nicht geeignet. Bei Verbindungen über telnet, rlogin usw. wird das Passwort allerdings unverschlüsselt übertragen, kann somit von Personen mit hinreichend krimineller Energie an einer geeigneten Stelle des Internet unter Umständen mitgeschnitten werden.

Die SSH (secure shell!) ist nicht wie z. B. die Bourne Shell (sh) oder C-Shell (csh) und ähnliche ein weiterer Kommandozeileninterpreter, sondern eigentlich ein sicherer Weg, um eine Shell oder Shell-Funktionen auf einem entfernten Rechner auszuführen, lehnt sich vom Namen her deshalb an die remote shell (rsh) und remote login (rlogin) an (ssh/slogin).

Auf dem Server muß in jedem Fall ein SSH Daemon (sshd) laufen, der über ein eigenes Protokoll die Verbindung vom Client entgegennimmt und bedient. Es bietet sich an, den sshd als daemon im Hintergrund laufen zu lassen - der Start über einen Internet ``super-server'' (unter Unix normalerweise der inetd) könnte aufgrund relativ zeitintensiver Rechenprozesse beim Start sonst durch massive "Anstürme" auf den Port effektiv au&szer;er Betrieb gesetzt werden (denial of service attack).

Die Authentifizierung kann über einen der nachfolgend beschriebenen Wege erfolgen:

In einer Datei hosts.equiv (meist unter /etc abgelegt) sind Rechner eingetragen, die das lokale System als vertrauenswürdig ("trusted") einstufen soll. Dann werden Benutzer von diesen Rechnern, die sich per rlogin anmelden möchten bzw. per rsh Aufrufe auf dem Rechner starten wollen, ohne Passwort zugelassen, wenn für sie ein gleichnamiges lokales gütiges Login existiert. Die Echtheitsprüfung der Rechner erfolgt auf Basis der IP-Adresse. In der Datei .rhosts im home directory eines Benutzers kann jeder Benutzer selbst die Hosts und Benutzernamen eintragen, denen er Zugang ohne Passwort ermöglichen will.

Diese Variante ist allgemein unsicher, ermöglicht vergleichsweise einfache Angriffe und ist deshalb normalerweise abgeschaltet.

Diese Variante baut auf der unter 2.1.1 beschriebenen Technik auf, ergänzt diese aber um eine Echtheitsprüfung durch host keys. Dabei wird auf jedem Rechner beim ersten Aufruf von ssh oder sshd ein privater und ein öffentlicher Schlüssel für den Rechner selbst erzeugt und gespeichert, damit er künftig immer wieder verwendet werden kann.

Ist der Zugang nach .rhosts bzw. .shosts auf dem Server freigegeben, überprüft SSH die host keys - wenn diese gegenseitige Überprüfung positiv beendet wird, ist ein Zugang ohne Eingabe des Benutzerpassworts möglich. Diese Variante wird nicht bei einer Einwahl mit einem Zugang per dynamischer Adressvergabe funktionieren, da hier zwar der host key stimmt, aber meistens nicht zum host passen wird. Die host key Authentifizierung ist die einfache Variante für die Anmeldung auf Rechnern mit statischen IP-Adressen.

Die Authentifizierung eines Benutzers mit einem oder mehreren Benutzerschlüsseln funktioniert analog zu der Echtheitsprüfung mit Rechnerschlüsseln, aber einem kleinen Unterschied: ein Benutzer muß ein persönliches Schlüsselpaar erzeugen. Dieses Schlüsselpaar besteht aus einem öffentlichen ("public") und einem privaten Schlüssel: der public key wird auf allen Rechnern hinterlegt, die einem Benutzer, der den dazu passenden private key mitbringt, Zugang (ohne Passworteingabe) gewähren sollen. Zum Erzeugen eines solchen Schlüsselpaares dient das Programm ssh-keygen, der private Schlüssel liegt üblicherweise in .ssh/identity, der dazugehörige public key liegt in .ssh/identiy.pub und öffentliche Schlüssel, denen Zutritt gewährt werden soll, müssen in .ssh/authorized_keys eingetragen werden.

Achtung: das Programm ssh-keygen erwartet beim Erzeugen eines Schlüsselpaares eine passphrase, ein Kennwort, mit dem der private Schlüssel auf der Festplatte gesichert wird. Man kann dieses Feld leer lassen, dann wird nie nach einer passphrase gefragt werden. Besser ist aber, sich mit dem ssh-agent vertraut zu machen, der (z. B. bei der Anmeldung) einmalig die passphrase erfragt und dann den damit entschlüsselten private key für andere Prozesse bei Bedarf bereitstellt.

Die Grundidee ist, daß ein Benutzer bei der Anmeldung mittels einer Seriennummer über einen Authentifizierungsserver überprüft wird und keine öffentlichen keys lokal bekannt sein müssen.

Ich setze an dieser Stelle eine laufende UUCP-over-IP-Konfiguration mit Taylor UUCP voraus. Mir ist nicht bekannt, daß andere UUCP-Implementationen UUCP-over-IP unterstützen und ich betrachte Taylor UUCP als de facto Standard.

An einer bestehenden UUCP-über-IP-Konfiguration muß eigentlich nicht viel geändert werden: es muß lediglich der Eintag in der Datei sys auf dem lokalen Rechner so abgeändert werden, daß die Verbindung für das UUCP-Zielsystem nicht mehr über die IP-Adresse bzw. den Hostnamen des Zielrechners auf den UUCP-Port erfolgt, sondern auf den lokalen Rechner und den weitergeleiteten Port:

system sax
call-timegrade z AllTimes
chat login: \L Password: \P
protocol t
port type tcp
#address sax.sax.de
address 127.0.0.1
port service 44444
commands rmail rnews


Der ursprüngliche Eintrag wurde auskommentiert stehengelassen, um den Unterschied zu verdeutlichen.

Es ist natürlich sinnvoll, den SSH-Aufruf entweder in einem Script vorher ausführen zu lassen oder die erforderlichen Einstellungen in der Konfigurationsdatei für SSH (ssh_config) entsprechend einzutragen.

Der erste Schritt, um UUCP über eine verschlüsselte SSH-Verbindung zu sax.sax.de laufen zu lassen, ist das Erzeugen eines neuen Schlüsselpaares, daß ohne Verschlüsselungsmantra (passphrase) genutzt werden kann. Das erreicht man mit ssh-keygen:

mw@theatre:/home/mw 678 $ ssh-keygen
Initializing random number generator...
Generating p: ............++ (distance 130)
Generating q: .......++ (distance 94)
Computing the keys...
Key generation complete.
Enter file in which to save the key (/home/mw/.ssh/identity): uucp.key
Enter passphrase: (Leereingabe, also 1 x Enter)
Enter the same passphrase again: (dito)
Your identification has been saved in uucp.key.
Your public key is:
1024 33 133903226487936036068107189442272513503126890581198060504786340415583155492058067019690939110609705800820957393827530238990873660654263685410407615469487066793865888759452753694644416994810962105715588754062698419817473439169059018673200810315317349095664304155285481483471933905819513462779551854638227029159 mw@theatre.sax.de
Your public key has been saved in uucp.key.pub
mw@theatre:/home/mw 679 $

man pages auf sax.sax.de:

• hosts.equiv(5) bzw. rhosts(5)
• sshd(8)
• ssh(1)
• ssh-keygen(1)
• ssh-agent(1)
• uucico(8)

Info-Seiten über UUCP auf sax.sax.de ("info uucp")