Ausgangspunkt war die Notwendigkeit einige UNIX-Rechner über ein Datennetz zu administrieren, dessen Nutzerkreis nicht 100%-ig transparent ist. Da der Nutzerkreis nicht überschaubar ist und damit auch die physischen Möglichkeiten in andere Netzwerk zu gelangen nicht eingeschätzt werden können, wurde ein restriktiver Ansatz gewählt. Bisher wurden die Administrationszugänge über einen TCP-Wrapper geschützt, was zumindest Adress-Spoofing vorbeugt. Gegen Sniffer-Werkzeuge bietet das allerdings keinen Schutz. Als Ausweg bietet sich die Nutzung kryptografischer Methoden an. Diese können auch, im Falle der SSH, mit dem erwähnten TCP-Wrapper kombiniert werden.
Die Dokumentation soll im Folgenden recht ausführlich den Prozess von Installation und Konfiguration beschreiben. Ich habe bewusst eine detaillierte Form gewählt. Der Leser möge sich nicht entmutigen lassen. Ich habe, nach etwas Übung, zur Administration von 11 UNIX/Linux-Hosts und einen Laptop ca. 6 Stunden benötigt. Die Kompilierung der SSH-Sourcen auf einer RM400E benötigte ca. 1,5 Stunden. Dabei ist für spätere Installationen auf anderen RM-Rechnern ein Packaging (pkgmk) sinnvoll. Auf Linux-Rechnern liegen zwei SSH-Pakete bei. OpenSSH weicht allerdings etwas vom hier Beschriebenen ab, während SSH selbst wie hier beschrieben funktioniert. Auf dem PC geht die Installation naturgemäß schnell über die Bühne. Auch die Konfiguration ist, wenn man erstmal weiß wo man hingreifen soll, schnell gemacht. Was zumindest für den Autoren am meisten Zeit gefressen hat, war das Literaturstudium um den Einstieg in die Thematik zu bekommen.
Konzep Tunneling
Die Wahl fiel relativ schnell auf die Secure Shell. Sie bietet sich an, den Datenverkehr zwischen Client und Server kryptografisch zu sichern. Außerdem ist sie ein gängiges Produkt die unsicheren r-Utilities zu ersetzten. Sie ist zumindest für den nicht-kommerziellen Bereich frei verfügbar. Im kommerziellen Umfeld müssen Lizenzen erworben werden. Sie kann als Mischprodukt in Windows- und
UNIX-Umgebungen eingesetzt werden. Im Sinne eines VPN ist sie sicher nicht einsetzbar, denn dort würde der Administrationsaufwand zu hoch. Für den Zweck sensible Zugänge zu UNIX-Rechnern abzudichten, erscheint sie aber als probates Mittel.
Sie bietet als Windows-Client einen Terminalzugang und einen grafischen scp-Client. Der Terminal-Client kennt naturgemäß keine Siemens Terminal 97801. Damit sind Programme mit pseudografischer Oberfläche wie fmli, HIT oder Werkzeuge wie less nicht korrekt darstellbar. Also musste eine Lösung in Verbindung mit Terms97801 geschaffen werden. Durch die Fähigkeit der SSH TCP-Verbindungen zu tunneln (mit UDP oder non-IP Protokollen geht das nicht), kann man Terms97801 über den normalen Telnet-Port nutzen ohne auf Verschlüsselung zu verzichten. Diese Fähigkeit könnte z.B. auch zum Sichern einer POP-Verbindung verwendet werden. Aber das steht auf einem anderen Blatt.
Kurz eine Bemerkung zum Bild, also zum Tunneling. TCP-Verbindungen sind virtuelle voll-duplex Verbindungen, also muss es je einen Kanal für Senden und Empfangen geben. Eine TCP-Verbindung wird durch einen Sourcesocket und einen Targetsocket beschrieben. Ein Socket ist die Kombination aus IP-Adresse und Portnummer. Server-Portnummern sind standardisiert. Source-Portnummern werden vom Client i.d.R. aus dem Bereich unbelegter Portnummern genommen.
Im Beispiel läuft das nun wie folgt ab. Es wird zuerst vom lokalen ssh-Client eine Verbindung von Port 7512 auf Port 22 (SSH-Dämon) des UNIX-Hosts erstellt. Diese Verbindung ist kryptografisch gesichert. Nun muss also noch Terms97801 eine Verbindung zum Port 7512 auf localhost erstellen (Port 1111). Danach werden alle telnet-Daten über den Tunnel zum Server übertragen. Dort liefert sie der SSH-Dämon (Port 3520 als Client) an den Telnet-Server (Port 23) aus. Es ist problemlos möglich, mehrere Sitzungen auf einem UNIX-Host aufzubauen.
netstat auf dem NT-Client:
TCP NTCLIENT:1111 localhost:7512 ESTABLISHED
TCP NTCLIENT:7512 localhost:1111 ESTABLISHED
:
TCP NTCLIENT:1110 UNIXHOST:22 ESTABLISHED
netstat auf dem UNIX-Server:
Active Internet connections (including servers)
Prot Recv Send Local Address Foreign Address (state)
tcp 0 0 localhost.telnet localhost.3520 ESTABLISHED
tcp 0 0 localhost.3520 localhost.telnet ESTABLISHED
tcp 0 44 UNIXHOST.22 NTCLIENT.1110 ESTABLISHED
tcp 0 0 *.22 *.* LISTEN
TCP-Wrapper Dateien (TCP-Wrapper Support muss mit einkompiliert sein)
Konfigurationsdateien (Client)
ssh2_config unter /etc/ssh2 oder ~/.ssh2
globale oder nutzerspez. Client-konfiguration
~/.ssh2/identification
stellt klar welcher Schlüssel der eigene ist
hostkeys unter /etc/ssh2 oder ~/.ssh2
öffentl. Schlüssel der remote Rechner (key_22_hostname.pub)
knownhosts unter /etc/ssh2 oder ~/.ssh2
öffentl. Schlüssel der remote Rechner die für hostbased-Anmeldung zugelassen sind
Prinzip der Verschlüsselung einer Verbindung
Der Client meldet sich beim Server und gibt bekannt unter wessen Account er eine Verbindung will.
Im Wesentlichen laufen hier 4 Schritte ab:
Der Server sendet eine sogenannte Challenge zum Client um seine Identität zu prüfen.
Der Client berechnet aus seinem privaten Schlüssel und der Challenge den Authenticator und sendet ihn an den Server zurück.
Das Shared Secret wird ausgetauscht um den Session Key zu generieren.
Der Server nimmt den öffentlichen Schlüssel des Accounts (nur den hat der Client) und prüft den Authenticator dagegen. Nun wird die Datenübertragung symmetrisch verschlüsselt. Dieser Schlüssel wird zyklisch neu generiert.
Der eigentliche Datentransfer läuft mit symmetrischer Verschlüsselung. Das langsamere asymmetrische Verfahren wird nur zur Schlüsselgenerierung verwendet.
Bezugsquellen
Die Secure Shell wird von der Firma SSH Communications Security
entwickelt. Wie öfter bei erfolgreichen Entwicklungen im Bereich der Public Domain Software (GPL-Lizenz), werden diese
Produkte früher oder später kommerziell. Ein jeder mag selbst herausfinden wie teuer ihm Sicherheit zu stehen kommt.
Der Distributor für Deutschland ist die Firma Seicom.
Benötigt wurden für das Beispiel:
SSH Server für UNIX (Sourcen) Version 2.3.0 bzw. 3.2.0
Konfiguration SSH auf dem Unix-Rechner (RM3/400 5.44/45)
Es wird hier nur der Teil beschrieben, der für eine Client-Anbindung eines NT-Laptops als Administratorarbeitsplatz benötigt wird.
Kompilierung
Zuerst das übliche: Sourcen entpacken, configure aufrufen (--without-x weil Reliant-UNIX nicht alle X-includes hat, die die Sourcen voraussetzen) anschließend make und make install. Verwendet wurde ein gcc version 2.7.2. Ein paar kleine Probleme gab es zu lösen.
ld: system error: not enough memory to allocate 12234592 bytes
Ein Blick auf die Werte von ulimit -a zeigt den Schwachpunkt. Hier war es das Datensegment, was auf 65 MB begrenzt war. Der Wert kann für die Dauer der Kompilierung auf unlimited gesetzt werden.
Da 97801-Terminal einige vorausgesetzte Fähigkeiten nicht besitzen, werden sie als nicht erkannt eingestuft und der Default vt100 genommen. Das ist kein Beinbruch. In ./lib/sshreadline/sshreadline.c sollte man aber die Warnung auskommentieren.
/* es fehlen einige terminfo-Einträge beim 97801 */
/* ssh_warning("Need basic cursor movement capability, using "vt100"); */
use_builtin = TRUE; /* vt100 */
Alle Kommandos, Man-Pages etc. erhalten noch einen symbolischen Link ala ssh
ssh2.
Konfiguration
Im Beispiel soll gezeigt werden, wie eine root-Kennung für ssh vorbereitet wird. Zuerst muss der Server eingerichtet werden. Als Verzeichnis für server-relevante Daten dient /etc/ssh2. Dort stehen u.a. die Konfigurationsdaten ssh2_config und sshd2_config. Beide werden mit Beispielen ausgeliefert. Außerdem bietet die Dokumentation genug Informationen. Nun muss ein Serverschlüssel generiert werden. Das geschieht per:
ACHTUNG!
Der Hostkey hat keine Passphrase. Damit wird er nur durch die Filesystemrechte geschützt. Die Alternative wäre eine Passphrase zu vergeben. Dann dürfte aber kein operatorloser Reboot erfolgen, denn dann würde der Rechner beim Hochfahren diese Passphrase haben wollen und warten.
Sie sollten sich den Fingerprint des Schlüssels notieren um ihn später beim Tausch der öffentlichen Schlüssel parat zu haben.
ssh-keygen2 -F /etc/ssh2/hostkey.pub
Als Nächstes benötigt man ein Start-Stop-Skript für die ssh. Das Beispiel ist mit Kommentaren versehen.
Starten Sie nun den sshd. Richten Sie ein Verzeichnis $HOME/.ssh2 ein. Da ReliantUnix-Systeme i.A. kein /usr/local-Verzeichnis kennen, muss PATH und SUPATH in /etc/default/login um /usr/local/bin erweitert werden.
Als nächstes wird der Nutzerschlüssel für root erzeugt. Danach müssen noch die öffentlichen Schlüssel zwischen den Kommunikationspartnern verteilt werden. Beides kann per ssh-pubkeymgr erledigt werden. Der Mitschnitt zeigt, was dabei abläuft. Der lokale Rechner wird nun in die Datei authorization (Key root-NODENAME.pub) eingetragen. Dann muss noch der lokale öffentliche Schlüssel von root kopiert werden per:
cp id_dsa_1024_a.pub root-NODENAME.pub. Fertig zum lokalen Test ! Später muss noch in der $HOME/.ssh2/authorization der Laptop eingetragen werden, z.B. "key ntuser-laptop_dsa_1024_a.pub".
Test
Prinzipiell sollte man alle Varianten der lokalen Anmeldung mal durchspielen. Dann ist man erstmal was den lokalen Server angeht auf der sicheren Seite. Hier die folgenden Mitschnitte:
# ssh -l root NODENAME
Host key not found from database.
Key fingerprint:
ximor-ruvyc-tedul-pulem-bycuc-hytoz-copuc-kamoz-fymic-kegif-zoxux
You can get a public key's fingerprint by running
% ssh-keygen -F publickey.pub
on the keyfile.
Are you sure you want to continue connecting (yes/no)?
Host key saved to /.ssh2/hostkeys/key_22_NODENAME.pub
host key for NODENAME, accepted by root Tue Aug 13 2002 14:29:36
Passphrase for key "/.ssh2/id_dsa_1024_a" with comment "1024-bit dsa, root@NODENAME, Tue Aug 13 2002 14:26:57":
warning: Authentication failed.
Disconnected; connection lost (Connection closed.).
Beim 2. Login funktioniert es dann. Damit ist nun die Möglichkeit gegeben sich auf der Maschine per ssh anzumelden.
# ssh -l adv NODENAME pwd
Passphrase for key "/.ssh2/id_dsa_1024_a" with comment "1024-bit dsa, root@NODENAME, Tue Aug 13 2002 14:26:57":
Authentication successful.
/
ssh als rsh-Ersatz. Die Authentication successful Nachricht kann per Konfiguration unterdrückt werden.
# scp -p datei root@NODENAME:/tmp
Passphrase for key "/.ssh2/id_dsa_1024_a" with comment "1024-bit dsa, root@NODENAME, Tue Aug 13 2002 14:26:57":
datei | 742B | 0.7 kB/s | TOC: 00:00:01 | 100%
Datei(en) kopieren per scp statt rcp.
# sftp root@NODENAME
Passphrase for key "/.ssh2/id_dsa_1024_a" with comment "1024-bit dsa, root@NODENAME, Tue Aug 13 2002 14:26:57":
sftp> quit
Ebenfalls eine Dateiübertragung aber per sftp. Scp nutzt im übrigen auch den sftp-Server.
# ssh -l root -s test NODENAME
Passphrase for key "/.ssh2/id_dsa_1024_a" with comment "1024-bit dsa, root@NODENAME, Tue Aug 13 2002 14:26:57":
Authentication successful.
Testing SSH-Subsystems
Das war der Test eines Subsystems, ähnlich sftp. Die Konfigurationseinträge sind dafür:
Ist die ständige Eingabe der Passphrase nicht nervend ? Diese Arbeit nehmen uns sogenannte Agenten ab. Wie's geht steht hier.
Die normale Arbeit per slogin/ssh mit aktivem Agent funktioniert gut. Die ssh benötigt zur besseren Bilddarstellung folgende Variable in .ssh2/environment:
COLUMNS=80
LINES=24
LANG=De_DE.88591
Damit laufen die Anwendungen: shell, less, vi, mc, ncftp und Screens sauber. Bei manchen fmli-Oberflächen verrutschen die Tastaturlabel in die 25. Zeile.
Hinweis !!! Unter Reliant-Unix blockieren ssh-Aufrufe als cron-jobs. (An einer fehlerhaften Environment kann es nicht liegen. Versuche mit -n bzw. -o "BatchMode yes" brachten nichts. Auch ForcePTYAllocation brachte nichts. Auch diverse Newsgroups halfen nicht. Ich denke, dass das Problem eher im ReliantUnix zu suchen ist, denn die gleichen Sourcen bereiten unter Linux kein Problem.)
Sollen nun andere UNIX-Systeme eingebunden werden, läuft die hier beschriebene Prozedur auf jeder Maschine ab. Per ssh-pubkeymgr muss der remote Host in die Datei authorization eingetragen werden und der lokale öffentliche Schlüssel des Nutzers an den remote Host übertragen werden. Dann ist eine durch Public Key Verschlüsselung gesicherte Verbindung möglich. Bei den Methoden Password und Hostbased erfolgt auch eine Verschlüsselung der Verbindung. Jedoch ist die Verschlüsselung nicht so stark und gerade Hostbased hat noch einige andere Schwächen.
Administration auf dem Client-Rechner (WinNT4 SP6)
Die SSH wird zunächst per setup installiert. Dabei wird auch der persönliche Schlüssel generiert.Nun muss der öffentliche Teil des Schlüssels auf den/die Zielrechner (also die Unix-Hosts mit einem SSH-Server) übetragen werden. Dazu benutzt man am besten den SCP-Client (siehe unten).
Mit der Funktion Quick Connect muss man sich ein erstes Mal am Server anmelden. Da der Server und auch der Client sich (noch) nicht kennen, muss als Authentisierungsmethode Password ausgewählt werden. Bei erfolgreicher Verbindungsaufnahme wird das Kennwort abgefragt und die Hostschlüssel ausgetauscht.
Das folgende Bild zeigt den gespeicherten Host-Schlüssel unter Settings Global Settings Server Authentication Host Keys.
Jetzt kennt erstmal der Laptop den Server. Für eine Public Key Anmeldung muss aber noch der öffentliche Schlüssel des Nutzers auf den Server geladen werden.
Das kann mittel der Upload-Funktion unter Settings Global Settings User Authentication Keys erledigt werden. Setzen Sie am Besten den Haken für eine Kontrollansicht der authorization - Datei. Dort muss ein Eintrag für den Laptop auftauchen, z.B. key NT_USER-LAPTOP_dsa_1024_a.pub. Auf der Serverseite taucht dann in $HOME/.ssh2 eine Datei NT_USER-LAPTOP_dsa_1024_a.pub
Hat der Upload des Schlüssels funktioniert, kann beim nächsten Anmelden auf Public Key Anmeldung umgeschalten werden. Am Besten kommt man, wenn man sich für einen Server ein Profile definiert (siehe links darüber).
Darin braucht man lediglich Hostname, Username und Authenisierungsmethode festlegen. Danach kann man per Click auf eines der Profile direkt eine Verbindung herstellen und den grafischen SCP-Client nutzen. Wie das letztlich ausschaut, zeigt folgendes Bild.
Administration der Terms97801
Die Einrichtung des Terms97801 für SSH-Betrieb ist einfach. Da es sich um einen Quick-Hack handelt, wird hier von einer gewissen Verzeichnisstruktur ausgegangen. So muss Terms97801 in c:\terms22\97801 installiert sein. Wenn nicht, muss im VB-Code Hand angelegt werden. In diesem Verzeichnis gibt es ein Unterverzeichnis connections. Dort befinden sich die einzelnen ini-Dateien für die jeweiligen Rechner. Die Namen sind: hostname.domain(1.Teil).ini. Entsprechend wird aus dem VB-Programm Terms mit der Option -i aufgerufen.
Verbesserung des Bedienkomforts
Alle Operationen mit ssh/scp bedingen die Eingabe der Passphrase. Um das zu automatisieren, gibt es verschiedene Ansätze. Der praktikabelste ist die Nutzung eines Agenten. (Zum Für und Wider der Alternativen sei auf die Literatur verwiesen.) Wichtig ist, das Agent-Forwarding zu nutzen.
UNIX-Seite
Der ssh-Agent muss zu Beginn einer Nutzersitzung gestartet werden. Zum Schluss sollte der Prozess der speicherresident ist, beendet werden. Folgende Eintragung in $HOME/.profile regelt das.
trap 'test -n "$SSH2_AGENT_PID" && kill -TERM $SSH2_AGENT_PID' 0
:
if [ "$SSH_AUTH_SOCK" = "" ]
then
eval `ssh-agent`
/sbin/tty > /dev/null && ssh-add2 && ssh-add2 -l
fi
Windows-NT Seite
SSH Accession ist eine frei verfügbarer abgespeckter SSH-Agent, der aber für unseren Zweck vollkommen ausreicht.
Der Agent sollte auch hier zu Beginn geladen werden. Das löst ein Eintrag im autostart.
Eventuelle muss ein wenig mit der Verzögerungszeit experimentiert werden, damit alles seine richtige Reihenfolge hat. Einziges Problem ist, dass die Passphrase erst bei der ersten Verwendung abgefragt wird. Um das zu umgehen, habe ich ein kleines Programm geschrieben,
dass eine eigentlich sinnlose ssh-Anwendung auf einen Rechner mit SSH-Server startet. Damit ist die Passphrase-Abfrage vor der ersten ernsten Anwendung erledigt. Der VB-Sourcecode steht hier.
Nach erfolgreicher Eingabe der Passphrase steht der Private Key zur Verfügung. Man sollte SSH Accession nach eigenem Empfinden administrieren, z.B. als Icon im Systemtray. Zumindest einmal sollte man sich die Eigenschaften des Private Key anschauen. Danach funktioniert die passwortlose Arbeit mit scp, ssh etc.
Informationsquellen
Weitere Informationsquellen zum Thema SSH sind:
SSH - The Secure Shell The Definitive Guide von O'Reilly (gibt es inzwischen auch in deutsch)
To: majordomo@clinet.fi
Subject: (leer)
(un)subscribe ssh
Garantieausschluss;
Diese Informationen sind sorgfältig zusammengestellt. Sie basieren auf der Praxiserfahrung des Autoren. Trotzdem erhebt diese Web-Seite keinen Anspruch auf Vollständigkeit, Fehlerfreiheit oder etwa den eines gültigen Kochrezeptes für den Einsatz beim Leser. Der Gebrauch dieser Informationen geschieht auf eigenes Risiko.
UNIX-Umgebungen eingesetzt werden. Im Sinne eines VPN ist sie sicher nicht einsetzbar, denn dort würde der Administrationsaufwand zu hoch. Für den Zweck sensible Zugänge zu UNIX-Rechnern abzudichten, erscheint sie aber als probates Mittel.
ssh2.
Der Agent sollte auch hier zu Beginn geladen werden. Das löst ein Eintrag im autostart.
Eventuelle muss ein wenig mit der Verzögerungszeit experimentiert werden, damit alles seine richtige Reihenfolge hat. Einziges Problem ist, dass die Passphrase erst bei der ersten Verwendung abgefragt wird. Um das zu umgehen, habe ich ein kleines Programm geschrieben,
dass eine eigentlich sinnlose ssh-Anwendung auf einen Rechner mit SSH-Server startet. Damit ist die Passphrase-Abfrage vor der ersten ernsten Anwendung erledigt. Der VB-Sourcecode steht 
Nach erfolgreicher Eingabe der Passphrase steht der Private Key zur Verfügung. Man sollte SSH Accession nach eigenem Empfinden administrieren, z.B. als Icon im Systemtray. Zumindest einmal sollte man sich die Eigenschaften des Private Key anschauen. Danach funktioniert die passwortlose Arbeit mit scp, ssh etc.