Diesen Artikel haben wir mit
freundlicher Genehmigung des Rechenzentrums der Humboldt-Universität
zu Berlin den RZ-Mitteilungen Nr. 15 (Dezember 1997) entnommen.
Autor: Alexander Geschonneck
geschonneck@rz.hu-berlin.de
Im Normalfall wird heutzutage jede TCP/IP-Verbindung im Klartext übertragen. Dies betrifft nicht nur die Daten und die Bildschirmausschnitte, die transportiert werden, auch Login und Paßwort gehen so ungeschützt über das Netz. Jede Station, die sich zwischen dem eigenen Rechner und dem Zielrechner befindet, ist in der Lage, diese Informationen mitzuschneiden und zu mißbrauchen. Heutzutage sind in fast jeder UNIX-Distribu- tion dafür geeignete Werkzeuge vorhanden. Viele davon sind sogar frei erhältlich. Daß dies jeden auch nur etwas sicherheitsbewußten Anwender schaudern läßt, dürfte wohl klar sein.
E-Mail und HTTP-Verbindungen kann man ohne Probleme verschlüsseln. Wie sieht es aber mit telnet, rlogin, rsh, rdist und rcp aus? Seit 1995 existiert ein finnisches Programm, das es sich zur Aufgabe gemacht hat, diese Problematik wirksam zu behandeln. Dieses Programm heißt Secure Shell (SSH); sein Einsatz und die Installation sollen im folgenden Artikel näher beschrieben werden.
Mit SSH kann man sich über ein Netzwerk bei einem anderen Rechner anmelden, um dort Befehle auszuführen und Dateien zu transportieren. Es benutzt dabei eine starke Authentifizierung und ermöglicht eine sichere Kommunikation durch unsichere Kanäle.
Durch den Einsatz von starker Authentifizierung werden folgende Gefahren eliminiert:
Abb. 1: Netzwerkmitschnitt ohne SSH
Mit anderen Worten, SSH traut niemals „dem Netz“. Jemand, der in ein Netzwerk eindringt, kann höchstens die SSH-Verbindung unterbrechen, aber nicht die Verbindung übernehmen, die übertragenen Daten mitlesen/mitschneiden und wieder einspielen. Dieser ganze Schutz beruht im wesentlichen auf Verschlüsselung. Daher sollte die vorhandene Option -nocrypt im Echtbetrieb niemals benutzt werden!
SSH wird niemals den normalen Schutz der Workstation oder des Servers übernehmen. Das heißt, wenn es jemandem gelingt, über bekannte Lücken oder durch Administrationsfehler Administratorrechte zu erlangen, kann er auch SSH kompromittieren. Wenn jemand unberechtigten Zugang zu HOME-Verzeichnissen hat, kann die Sicherheit, die SSH dem Nutzer bietet, wirkungslos sein. Dies betrifft vor allem HOME-Verzeichnisse, die per NFS zur Verfügung gestellt werden. NFS ist höchst unsicher und kann leicht kompromittiert werden. Im HOME-Verzeichnis eines jeden Nutzers werden im Unterverzeichnis .ssh/ eigene Client-Konfigurationsdateien, die Public Keys der vertrauenswürdigen Server und der eigene Private Key gespeichert.
Es wird eine zusätzliche Authentifizierungsmethode eingeführt. Der bekannte und bekanntermaßen unzulängliche .rhosts-Mechanismus wird durch RSA Server-Authentifizierung ergänzt. Es ist auch eine pure RSA-Authentifizierung möglich.
Die gesamte Kommunikation zwischen Client und Server wird automatisch und – für den Anwender – transparent verschlüsselt. Diese Verschlüsselung schützt außerdem vor gefälschten Paketen und Versuchen, die Verbindung zu kapern. Unter X11 ist darüberhinaus ein verschlüsseltes X-Forwarding möglich. Durch die RSA Host-Authentifizierung wird der Client bei jedem Verbindungsaufbau vor trojanischen Pferden, die durch gefälschte Routing- und DNS-Informationen eingeschleust werden können, geschützt. Durch die RSA Client-Authentifizierung wird der Server vor gefälschten Paketen geschützt, noch bevor er auf .rhosts oder /etc/hosts.equiv basierende Authentifizierung benutzt.
SSH ist als wirksamer, kompletter Ersatz für rlogin, rsh, rcp und rdist gedacht. In den meisten Fällen ist SSH auch ein telnet-Ersatz!
SSH benutzt ein paket-orientiertes, binäres Protokoll. Es wartet auf Port 22, der offiziell für SSH reserviert ist, auf Verbindungen. Das benutzte Protokoll tauscht zufällige Session Keys unter Einsatz des RSA-Algorithmus aus. Der Rest der Verbindung wird – je nach Konfiguration – mit 3DES, DES RC4-128, TSS oder Blowfish verschlüsselt. RSA wird auch für die Authentifizierung benutzt. Der benutzte Session Key wird aber niemals auf der Festplatte gespeichert; er wird ständig neu erstellt und befindet sich ausschließlich im Hauptspeicher.
Abb. 3: Anmeldung mit slogin
Der SSH-Daemon kontrolliert den Login-Prozeß folgendermaßen:
starke Authentifizierung
SSH kann reine RSA Host-Authentifizierung oder .rhosts zusammen mit RSA Host-Authentifizierung benutzen.
geschützte Privatsphäre
Automatische, für den Nutzer transparente Verschlüsselung der gesamten Verbindung. Host und Client Keys werden mit RSA verschlüsselt. Die Session wird je nach Konfiguration mit 3DES, DES oder IDEA verschlüsselt. Die Verschlüsselung beginnt vor der Paßwortübertragung!
sichere X11 Sessions
$DISPLAY wird auf dem Host gesetzt, und X11-Verbindungen werden automatisch über den verschlüsselten Kanal übertragen.
Port Forwarding
Bidirektionale Umlenkung von normalen TCP/IP-Ports auf die verschlüsselte Verbindung.
Automation
Die unsicheren alten r*-Programme werden komplett durch die neuen ersetzt. Der Nutzer kann wie gewohnt mit .rhosts arbeiten.
Vertraue niemals dem Netz
Ist RSA „eingeschaltet“, wird nur noch dem Privaten Schlüssel getraut.
Host Authentication Key
Der Client kann anhand des gespeicherten Server Keys den Server identifizieren.
User Authentication Key
Der Server kann anhand des gespeicherten Client Keys den Client identifizieren.
Server Key Regeneration
Der Session Key wird regelmäßig neu erstellt und niemals auf der Festplatte gespeichert.
Konfigurierbar
Client wie auch Server sind global und individuell nutzerbezogen konfigurierbar.
rsh Fallback
Wenn kein SSH-Daemon auf dem Zielsystem läuft, kann automatisch das alte (unsichere) r*-Protokoll benutzt werden.
Kompression
Daten können bei Bedarf vor der Übertragung automatisch komprimiert werden.
SSH ist zum gegenwärtigen Zeitpunkt in der Version 1.2.20 vorhanden. Die Entwickler geben folgende Minimalplattformen für den Einsatz an:
386BSD 0.1; i386
AIX 3.2.5, 4.1, 4.2; RS6000, PowerPC
BSD 4.4; weitere Plattformen
BSD/OS 1.1, 2.0.1; i486
BSD/386 1.1; i386
BSDI 2.1; x86
ConvexOS 10.1; Convex
Digital Unix 4.0, 4.0A, 4.0B; Alpha
DGUX 5.4R2.10; DGUX
FreeBSD 1.x, 2.x; Pentium
HPUX 7.x, 9.x, 10.0; HPPA
IRIX 5.2, 5.3; SGI Indy
IRIX 6.0.1; Mips-R8000
Linux 1.2.x, 2.0.x Slackware 2.x, 3.x, RedHat 2.1, 3.0;
i486, Sparc
Linux 3.0.3, 4.0; Alpha
Linux/Mach3, Macintosh(PowerPC)
Linux/m68k (1.2.x, 2.0.x, 2.1.x)
Mach3; Mips
Mach3/Lites; i386
Machten 2.2VM (m68k); Macintosh
NCR Unix 3.00; NCR S40
NetBSD 1.0A, 1.1, 1.2; Pentium, Sparc, Mac68k,
Alpha
OpenBSD 2.0; x86.
NextSTEP 3.3; 68040
OSF/1 3.0, 3.2, 3.2; Alpha
Sequent Dynix/ptx 3.2.0 V2.1.0; i386
SCO Unix; i386 (Client)
SINIX 5.42; Mips R4000
Solaris 2.3, 2.4, 2.5; Sparc, i386
Sony NEWS-OS 3.3 (BSD 4.3); m68k
SunOS 4.1.1, 4.1.2, 4.1.3, 4.1.4; Sparc, Sun3
SysV 4.x; verschiedene Plattformen
Ultrix 4.1; Mips
Unicos 8.0.3; Cray C90
Windows (3.x/95/NT), MacOS, Amiga, OS/2
sshd
Server-Programm, „lauscht“ auf Port 22 auf Verbindungen von Clients, authentifiziert die Verbindungen und startet den Dienst
ssh
Client-Programm, dient zum Verbindungsaufbau mit sshd als rlogin- und rsh-Ersatz
slogin
symbolischer Link zu ssh (rlogin-Ersatz)
scp
kopiert Dateien zwischen SSH-Systemen (rcp-Ersatz)
ssh-keygen
erstellt Authentifizierungsschlüssel für Server und Nutzer
ssh-agent
Authentifizierungsagent; verwaltet online die RSA-Schlüssel
ssh-add
registriert neue Schlüssel beim ssh-agent
make-ssh-known-hosts
Perl-Script,
das im Netzwerk nach öffentlichen Schlüsseln sucht und sie in
/etc/ssh_known_hosts
oder $HOME/.ssh/known_hosts
speichert
Wenn ein Nutzer eine SSH-Verbindung zu einem SSH-System herstellen möchte, kann er u. a. folgende Kommandos auf der Befehlszeile eingeben:
% ssh Zielsystem Befehl_der_auf_dem_Zielsystem_ ausgeführt_werden_soll
oder
% ssh Zielsystem
oder
% xterm -e ssh Zielsystem &
Wenn das Zielsystem kein SSH installiert haben sollte, werden automatisch die adäquaten r*-Programme benutzt. Durch die Angabe der Option -C kann man eine Komprimierung der Verbindungsdaten erreichen. Das Starten der Programme mit der Option -v ermöglicht eine genaue Fehleranalyse durch erweiterte Bildschirm- ausgabe.
Die folgenden Konfigurationsdateien sind für
den Einsatz von SSH von Bedeutung: |
||
Verzeichnis | Dateiname | Verwendung |
/etc/ | ssh_host_key | privater Schlüssel des Servers; nur für root zugänglich |
ssh_host_key.pub | öffentlicher Schlüssel des Servers | |
ssh_random_seed | Verweis für den systemweiten Zufallsnummerngenerator; nur für root zugänglich | |
ssh_known_hosts | systemweite Liste mit bekannten öffentlichen Schlüsseln anderer Systeme; ein System pro Zeile | |
ssh_config | systemweite Konfigurationsdatei für die SSH-Clients | |
sshd_config | Konfigurationsdatei für den SSH-Server | |
sshd.pid | Process-ID des letzten sshd-Prozesses | |
nologin | wenn diese Datei existiert, darf sich nur root auf dem System anmelden; der Inhalt dieser Datei wird allen anderen Nutzern angezeigt, wenn sie abgewiesen werden | |
environment | Umgebungsvariablen, die bei der SSH-Anmeldung gesetzt werden | |
hosts.equiv | systemweite Definition von Nutzern und Hosts, die sich via rlogin/rsh anmelden dürfen, wenn RhostAuthentication oder RhostRSAAuthentication in der /etc/sshd_config gesetzt ist | |
shosts.equiv | gleiche Funktion wie hosts.equiv, aber nur für SSH | |
sshrc | beinhaltet Befehle, die bei der Anmeldung ausgeführt werden, bevor die Shell eines Nutzers gestartet wird | |
$HOME/ | .rhosts | ermöglicht nutzerbezogene RhostAuthentication, wenn
es in der /etc/ config_sshd gesetzt ist |
.shosts | gleiche Funktion wie .rhosts, aber nur für SSH | |
.Xauthority | wird von SSH benutzt, um das Authorization Cookie für den X11-Server zu speichern; SSH überprüft, daß die X11-Forward-Verbindungen dieses Cookie betreffen; wenn die X11-Verbindung aufgebaut wurde, wird dieses Cookie durch das richtige X11-Cookie ersetzt; alle X11-Verbindungen gehen automatisch durch diesen verschlüsselten Kanal, den der SSH-eigene X11-Proxy-Server bereitstellt; SSH setzt $DISPLAY auf den Server mit einer Displaynummer, die größer als 0 ist | |
$HOME/.ssh/ | known_hosts | nutzerbezogene Liste mit bekannten öffentlichen Schlüsseln anderer Systeme; ein System pro Zeile; gilt als Ergänzung der systemweiten /etc/ssh_known_hosts, wenn StrictHostKeyChecking in /etc/sshd_config abgestellt ist. |
identity | privater Schlüssel des Nutzers; wird mit ssh-keygen erstellt und ist durch eine Passphrase geschützt | |
identity.pub | öffentlicher Schlüssel des Nutzers; entsteht bei der Erstellung des privaten Schlüssels | |
authorized_keys | nutzerbezogene Liste öffentlicher Schlüssel (identity.pub) von Nutzern, die ohne Angabe eines Paßwortes Zugang zu diesem Nutzer-Account haben | |
random_seed | Verweis für den nutzerbezogenen Zufallsgenerator; sollte nur für den Nutzer lesbar / schreibbar sein und von ihm nicht verändert werden | |
ssh_config | nutzerbezogene Konfigurationsdatei für den SSH-Client | |
environment | Umgebungsvariablen, die bei der SSH-Anmeldung gesetzt werden; wird nach /etc/environment abgearbeitet | |
rc | nutzerbezogene Variante von /etc/sshdrc |
Angesichts der Gefahren, die herkömmliche telnet- oder rlogin-Verbindungen beinhalten, sollte sich jeder überlegen, diese überholten Programme durch verschlüsselungsfähige abzulösen. Installation, Konfiguration und Einsatz der Programme wie SSH sind einfach und gewährleisten Erfolg bei der sicheren Übertragung von Daten über unsichere Kanäle.