SSH−WIN PC−Benutzeranleitung - Forschungszentrum Jülich

http://www.kfa−juelich.de/zam/docs/tki/tki_html/t0348/tki−0348all.htm Page: 1 

FORSCHUNGSZENTRUM JÜLICH GmbH 

Zentralinstitut für Angewandte Mathematik 

D−52425 Jülich, Tel. (02461) 61−6402 

Beratung und Betrieb, Tel. (02461) 61−6400 

Technische Kurzinformation 

FZJ−ZAM−TKI−0348 

Rudolf Theisen 

05.10.1999 

SSH−WIN PC−Benutzeranleitung 

Überblick 

1 Übersicht über SSH−WIN und seine Installation unter Windows 95/98 bzw. NT 

2 Interaktive SSH−Verbindung mit Paßwort−Authentisierung 

2.1 Überprüfung des RSA−Rechner−Schlüssels des SSH−Servers 

2.2 Paßwort−Authentisierung 

3 Interaktive SSH−Verbindung mit RSA−Authentisierung 

3.1 Erzeugung eines RSA−Schlüsselpaars 

3.2 Aufbau einer SSH−Verbindung mit RSA−Authentisierung 

4 Ausführung eines Befehls auf einem entfernten SSH−Server 

5 Tunnelung anderer Dienste über SSH−WIN 

5.1 Tunnelung von X11−Anwendungen 

5.1.1 Start der entfernten X11−Anwendung und deren Tunnelung 

5.1.2 Start eines X−Term−Fensters auf einem entfernten Rechner 

durch entfernte Befehlsausführung 

5.2 Tunnelung weiterer TCP/IP−Dienste, dargestellt am FTP−Dienst 

5.2.1 Konfiguration und Start des SSH−Tunnels zur sicheren 

Übertragung der FTP−Befehle 

5.2.2 Konfiguration und Start des WS_FTP−Client−Programms 

Hinweis: Dieses ist die Kurzfassung des Benutzerhandbuches BHB 0160 . 

1 Übersicht über SSH−WIN und seine Installation unter Windows 95/98 bzw. NT 

SSH−WIN ist ein kostenloses, windowsfähiges Secure Shell Client−Programm. Es wird 

von Cedomir Igaly entwickelt (s. Originale Homepage der SSH−WIN−Software 

(http://public.srce.hr/~cigaly/ssh) (161.53.2.130)) 

SSH−WIN unterstützt folgende Secure Shell Funktionen: 

Interaktiver Zugriff (Sicherer Telnet−Ersatz; s. Kap. 2 und 3) 

Ausführung eines Befehls auf einem entfernten Rechner (Sichere Remote 

Execution; s. Kap. 4)


Sichere Tunnelung von X11−Anwendungen (s. Kap. 5.1) 

Sichere Tunnelung von Diensten mit bekannten Port−Nummern (s. Kap. 5.2). 

SSH−WIN beherrscht also − im Gegensatz zur käufliche PC SSH−Version von Data 

Fellows − die sichere Befehlsausführung; beide können aber keinen sicheren File−Transfer 

(scp−Programm bei der SSH−UNIX−Versionen). Man kann aber die Benutzer−Kennung 

und das Paßwort, die beim FTP−Aufruf im Klartext über Port 21 übertragen werden, 

sichern, indem man Port 21 über eine vorher aufgemachte SSH−Verbindung übermittelt 

("tunnelt"; s. Kap. 5.2). 

Hinweis: Den sicheren File−Transfer bietet die SSH−DOS−Version 1.2.14 von 

Jonathan Chen, die Sie als interner FZJ−Benutzer z.B. unter 

ftp://ftp.kfa−juelich.de/pub/security/ssh/pc/ssh−dos/ finden bzw. auf die Sie als 

FZJ−Benutzer noch bequemer per Explorer über \\PCSRV\public\ssh\ssh−dos\ 

bzw. Q:\ssh\ssh−dos\ zugreifen können. 

Externe können auf diese Software nur per 

http://www.fz−juelich.de/zam/net/security/software/ssh/pc/ssh−dos/ zugreifen. 

Windows 95/98 bzw. NT−Benutzer können SSH−WIN mit dem Installationsprogramm 

SecureShell.exe recht einfach installieren: 

Holen Sie sich das Installations−Programm SecureShell.exe entweder vom 

FZJ−FTP−Server 

(ftp://ftp.kfa−juelich.de/pub/security/ssh/pc/ssh−win/SecureShell.exe) oder mit dem 

Explorer von \\PCSRV\public\ssh\ssh−win\SecureShell.exe bzw. 

von Q:\ssh\ssh−win\SecureShell.exe oder als Nicht−FZJ−Benutzer von 

http://www.fz−juelich.de/zam/net/security/software/ssh/pc/ssh−win/SecureShell.exe 

auf Ihren PC (in ein beliebiges Verzeichnis) und starten Sie dieses entweder über 

den Explorer oder über 

−−> Start −−> Ausführen... . Dieses leitet Sie durch die Installation: 

Anzeige: "User Information" 

Falls die Felder "Name:" und "Company:" noch leer sind, tragen Sie dort einen 

beliebigen Text ein. Erst dann können Sie mit Next bzw. ENTER weiter. 

Anzeige: "Choose Destination Location" 

Voreingestellt wird SSH−WIN nach C:\Programme\Secure Shell 

installiert. Wenn Sie ein anderes Verzeichnis bevorzugen, können Sie das mit der 

Browse...−Schaltfläche suchen und festlegen. Weiter mit Next bzw. ENTER. 

Anzeige: "Select Program Folder" 

Voreingestellt erscheint SSH−WIN später unter der Bezeichnung "Secure Shell" in 

Ihrer Programm−Übersicht. Sie können im Feld "Program Folders:" eine andere 

Bezeichnung eintragen. Weiter mit Next bzw. ENTER. 

Anzeige: "Start Copying Files" 

Hier werden Ihnen die drei Files angezeigt, die nun installiert werden sollen. 

Weiter mit Next bzw. ENTER. 

Diese werden nun installiert. 

Anzeige: "Setup Complete" 

Mit Next bzw. ENTER bestätigen Sie diese Installations−Abschlußmeldung. 

Beschaffen Sie sich nun in das SSH−WIN−Arbeitsverzeichnis (vorein.: 

C:\Programme\Secure Shell) vom FTP−Server die Liste der aktuellen SSH− 

Rechner−Schlüssel ftp://ftp.kfa−juelich.de/ssh_known_hosts.FZJ und nennen Sie diesen 

File um in known.hosts.


Für externe Benutzer bieten wir nur die SSH−Rechner−Schlüssel der Cray−Rechner und 

des zentralen AIX−Rechners an. Diese Sammlung können Sie in der Version vom 27.09.99 

von 

http://www.fz−juelich.de/zam/net/security/software/ssh/aix−und−cray−ssh_known_hosts 

bekommen. Speichern Sie diese im SSH−WIN−Arbeitsverzeichnis (s.o.) als 

known.hosts. 

Sie können aber auch ganz auf diese SSH−Rechner−Schlüssel verzichten und interaktiv 

diejenigen übernehmen, die Ihnen beim ersten SSH−Verbindungs−Aufbau vom jeweiligen 

Ziel−Rechner angeboten werden. Dabei aber müssen Sie darauf hoffen, daß Sie diese schon 

vom richtigen Ziel−Rechner angeboten bekommen. Es besteht dann aber die Gefahr, daß 

ein anderer Rechner sich für den Ziel−Rechner ausgibt und dann alles mitlesen kann 

(Man−in−the−Middle−Attack). 

Wer PGP installiert hat, kann sich dort auch noch die digitale Signatur 

(aix−und−cray−ssh_known_hosts.asc) dieser reduzierten SSH−Schlüssel−Sammlung 

holen, lokal abspeichern und mit dem Aufruf 

pgp aix−und−cray−ssh_known_hosts.asc 

aix−und−cray−ssh_known_hosts 

prüfen. 

Im nächsten Kapitel wird gezeigt, wie Sie sofort mit SSH eine sichere interaktive 

Verbindung zu einem Zielrechner aufbauen können und sich dort wie bisher mit Ihrem 

Paßwort ausweisen. Im 3. Kapitel wird dann die vom ZAM empfohlene 

RSA−Authentisierung mit Hilfe Ihres privaten SSH−Schlüsselpaares vorgestellt. 

2 Interaktive SSH−Verbindung mit Paßwort−Authentisierung 

Wenn Sie SSH−WIN mit Hilfe des Installationsprogramms SecureShell.exe 

installiert haben, können Sie es ganz normal über 

−−> Start −−> Programme −−> Secure Shell starten. Sie können es aber auch über den 

Explorer starten (ssh32.exe bzw. ssh32 Anwendung (ca. 262 KB)). 

Als erstes wird Ihnen die Nutzungs−Erklärung des Autors angezeigt , die Sie mit OK oder 

ENTER beenden. Daraufhin wird Ihnen innerhalb der SSH−WIN−Bedienoberfläche 

diejenige SSH−Verbindungsmaske angezeigt, die Sie als letzte mit der Save−Schaltfläche 

in der Registry abgespeichert hatten. Beim allerersten SSH−WIN−Aufruf ist diese 

natürlich noch − bis auf Ihren PC−Benutzernamen − leer. Füllen Sie die 

SSH−Verbindungsmaske aus:


Bild: 2.1 Verbindungs−Profile für einen SSH−Zugriff mit Paßwort−Authentisierung 

Erklärungen dazu: 

Der Ziel−Rechner (1) und Ihre dortige Benutzer−Kennung (2) sind einzutragen. 

Das voreingestellte Verschlüsselungsverfahren Idea ist gut (3). 

Den Kompressions−Schieber (compression Level) ist unbedingt auf "Min." 

zu stellen (4), d.h. die Kompression abschalten. Diese verzögert nur alles unnötig 

und macht zu AIX−Rechnern nur Ärger! 

Wenn Sie auf dem Zielrechner keine X−Anwendung starten wollen, sollten Sie 

vorsichtshalber das "X11 Forward" immer abschalten. Wenn ein Angreifer an 

den Inhalt von $HOME/.Xauthority auf dem entfernten Rechner kommt, kann er 

mitunter damit Ihrem lokalen X−Server Befehle senden, die dann bei Ihnen lokal 

ausgeführt werden (s. Ulrich Flegel: The Interaction between SSH and X11 

(http://HOME.Braunschweig.Netsurf.De/~ulrich.flegel/pub/ssh−x11.ps.gz). 

Wenn die Option "X11 Forward" aktiviert ist (5), werden alle X11−Anwendungen 

ebenfalls verschlüsselt übertragen. Voraussetzung aber ist, daß Sie vorher am PC 

einen X−Server gestartet haben ( s. TKI 0293; wenn Sie \\PCSRV\public\ 

permanent dem Laufwerk Q: zugeordnet haben, dann ist die PC−Xware−Software 

mit Q:\winnt40\pcxware\setup.exe installierbar.) 

Die Option "Receive LF as CR/LF" hilft, UNIX−Zeilen−Ende am PC korrekt 

darzustellen (6). 

Im Feld "Profile Name:" können Sie einen beliebigen Text für diesen 

Verbindungs−Profile definieren (7). Darüber können Sie bei späteren 

SSH−WIN−Aufrufen wieder gezielt diesen Verbindungs−Profile auswählen. Diese 

Profile−Bezeichnung kann man auch als Aufruf−Parameter verwenden, z.B. bei 

Icons (s. Benutzerhandbuch). 

Mit der Save−Schaltfläche sind diese Angaben in die Registry zu retten (8). 

Mit OK bzw. ENTER wird diese SSH−Verbindung gestartet (9).


Falls Sie SSH−Verbindungen zu verschiedenen Zielrechner aufnehmen wollen, können Sie 

sich mit der New−Schaltfläche weitere solcher SSH−Verbindungs−Profile anlegen und 

retten. 

2.1 Überprüfung des RSA−Rechner−Schlüssels des SSH−Servers 

Der SSH−Server sendet zu Beginn des Verbindungsaufbaus seinen RSA−Rechner 

−Schlüssel. Bevor dieser zur Verschlüsselung der SSH−Verbindung verwendet wird, prüft 

der SSH−Client, ob er diesen Schlüssel schon im File known.hosts hat; ansonsten zeigt 

er ihn an: 

Bild: 2.2 Anzeige eines noch unbekannten RSA−Rechner−Schlüssels 

Wenn Sie sich bereits früher zu diesem Zielrechner per SSH verbunden haben, dann 

sollten Sie Verdacht schöpfen und vorsorglich die Übernahme dieses Schlüssel in 

known.hosts über die Schaltfläche Refuse key ablehnen. Dann wird diese SSH−Sitzung 

mit der fatalen Fehlermeldung: "No host key is known for HOST" 

abgebrochen. 

Setzen Sie sich mit dem Administrator des Zielrechners in Verbindung und klären Sie, 

warum sich der Rechner−Schlüssel geändert hat. Es kann nämlich sein, daß Sie mit einem 

Rechner verbunden waren, der nur den von Ihnen gewünschten Zielrechner vortäuscht, 

um so z.B. an Ihr Paßwort zu kommen. 

Normalerweise aber werden Sie keinen Grund zu einem Verdacht haben und den 

angebotenen RSA−Rechner−Schlüssel einmal (Accept once) oder für immer (mit Accept 

Key bzw. ENTER) akzeptieren. 

2.2 Paßwort−Authentisierung 

Nachdem der RSA−Rechner−Schlüssel geprüft ist, kann der SSH−Client damit eine 

verschlüsselte Verbindung zum SSH−Server aufbauen. Ab nun wird alles zwischen Ihrem 

SSH−Client und dem SSH−Server abhörsicher übertragen. 

Da bei diesem ersten SSH−WIN−Anwendungs−Beispiel die sehr sichere 

RSA−Authentisierung noch nicht vorbereitet ist (s. Interaktive SSH−Verbindung mit 

RSA−Authentisierung), müssen Sie sich nun ganz normal mit Ihrem Paßwort auf dem 

Zielrechner ausweisen. Sie haben dazu drei Versuche. Nach dem dritten Fehlversuch wird 

SSH−WIN mit der fatalen Fehlermeldung "Permission denied" ganz abgebrochen. 

Dadurch wird das Paßwort−Raten deutlich erschwert. 

Nach Eingabe des richtigen Paßwortes erhalten Sie Zugang zu Ihrer Benutzer−Kennung


(User ID) auf dem Zielrechner und können dort ganz normal interaktiv arbeiten. Dabei 

wird ein VT100−Terminal emuliert. Statt dessen können Sie sich dort mit xterm & auch 

ein X−Terminal starten, falls an Ihrem PC der X−Server läuft. 

Mit dem Befehl exit beenden Sie diese interaktive Verbindung zum Zielrechner. Wenn Sie 

beim Aufruf (s. Bild 2.1) die Option "Close on exit" nicht aktiviert hatten, können Sie nun 

die nächste SSH−Verbindung festlegen und starten oder mit −−> Action −−> Exit das 

SSH−WIN−Programm endgültig beenden. 

3 Interaktive SSH−Verbindung mit RSA−Authentisierung 

Bevor Sie die sehr sichere RSA−Authentisierung verwenden können, bei der kein 

Geheimnis Ihren Rechner verläßt, müssen Sie sich zuerst ein RSA−Schlüsselpaar selbst 

erzeugt und dessen öffentlichen Schlüssel am Zielrechner an den File 

$HOME/.ssh/authorized_keys angefügt haben. 

3.1 Erzeugung eines RSA−Schlüsselpaars 

Bild: 3.1 Ausgefüllte Maske zur Erzeugung eines RSA−Schlüsselpaars 

Erklärungen: 

1. Aufruf mit −−> Keys −−> Generate key 

2. Im "Key description"−Feld können Sie eine beliebige Bezeichnung für 

diesen Schlüssel eintragen. Wir empfehlen aber die Form 

Benutzerkennung@Rechnername. 

3. Die voreingestellte Schlüssellänge von 1024 ist ausreichend sicher. 

4. Das idea−Verfahren zur Verschlüssellung des privaten RSA−Schlüssels ist gut. 

5. Die voreingestellte Option "SSH v1 identity" ist gut. Die Protokoll−Version 2 

hingegen ist nicht mehr kostenlos und wird derzeit nicht offiziell im FZJ eingesetzt. 

6. Mit OK bzw. ENTER die Schlüssel−Erzeugung starten 

Das RSA−Schlüsselpaar wird aus zwei sehr großen Primzahlen p und q erzeugt, deren 

Generierung in der Statuszeile angezeigt wird. 

Anschließend wird Ihnen zum Abspeichern das aktuelle Inhaltsverzeichnis angezeigt:


Bild: 3.2 Eingabe des Filenamens für Ihren geheimen SSH−Schlüssel 

Sie können zu einem anderen Verzeichnis wechseln, auch zu A:, oder sich ein neues 

Verzeichnis anlegen. Ihr geheimer SSH−Schlüssel muß also nicht im 

SSH−WIN−Arbeitsverzeichnis liegen, wo ihn ja jeder Angreifer suchen wird. 

Tragen Sie dann dort einen beliebigen Filenamen für Ihren privaten RSA−Schlüssel ein, 

z.B. Benutzername@Rechnername (7). Der dazu passende öffentliche RSA−Schlüssel 

bekommt dann automatisch den gleichen Filenamen, jedoch mit der Erweiterung ".pub". 

Mit der Speichern−Schaltfläche wird der Name übernommen (8). 

Anschließend werden Sie aufgefordert, Ihren SSH−Geheimsatz (passphrase) einzugeben, 

mit dem Ihr geheimer RSA−Schlüssel nochmals verschlüsselt wird, um ihn für einen 

Datendieb unbrauchbar zu machen. Dieser SSH−Geheimsatz ist letztendlich der wichtigste 

Schutz, mit dem Sie Ihren RSA−SSH−Schlüssel sichern. Verwenden Sie dabei sowohl 

Groß− als auch Kleinbuchstaben, Zahlen und Sonderzeichen, um so die Möglichkeit zu 

vereiteln, daß einer durch Ausprobieren aller möglichen Kombinationen doch noch Ihren 

privaten RSA−Schlüssel nutzen kann. Verwenden Sie keines Ihrer UNIX oder 

PC−Paßworte! Es gibt bereits (Makro−) Viren, die versuchen, private (PGP) 

RSA−Schlüssel zu entführen, um dann schlecht gewählte Geheimsätze zu erraten. 

Bild: 3.3 Zweifache Eingabe des SSH−Geheimsatzes 

Achten Sie darauf, den SSH−Geheimsatz (passphrase) gleich zweimal einzugeben (9, 10), 

also zu bestätigen, wobei Sie aber nicht mit der ENTER−Taste, sondern mit der Tab−Taste 

in die Bestätigungszeile kommen (10). Mit OK bzw. ENTER (11) wird Ihr privater 

RSA−Schlüssel verschlüsselt und im ausgewählten Verzeichnis abgespeichert. 

Wenn Sie wollen, können Sie sich so beliebig viele RSA−Schlüsselpaare definieren und für 

jeden SSH−Verbindung ein anderes verwenden. 

3.2 Aufbau einer SSH−Verbindung mit RSA−Authentisierung


Um die RSA−Authentisierung nutzen zu können, müssen Sie Ihren öffentlichen 

SSH−Schlüssel (Endung: .pub) zu Ihrem Benutzerverzeichnis auf dem UNIX−Zielrechner 

gebracht (z.B. per Mail) und dort an den File $HOME/.ssh/authorized_keys 

angefügt haben. Dieser File und das Verzeichnis $HOME/.ssh dürfen nur von Ihnen 

beschreibbar sein, damit kein andere dort seinen RSA−Schlüssel anfügen kann. Denn 

jeder, der das schafft, hat anschließend ungehinderten Zugang zu Ihrer dortigen 

Benutzer−Kennung. 

Wenn sie diese Voraussetzungen erfüllt haben, können Sie nun in den 

SSH−Verbindungs−Optionen die RSA−Authentisierung aktivieren (5) und über die 

Identities−Schaltfläche (8) den vollständigen Pfadnamen Ihres öffentlichen SSH 

RSA−Schlüssels festlegen. Sie könnten dort auch mehrere Schlüssel−Files angeben: 

Bild: 3.4 Anforderung der RSA−Authentisierung im SSH−Verbindungsmenü 

Wichtig ist, daß die Kompression abgeschaltet (4) und die RSA−Authentisierung aktiviert 

ist (5). Über die Identities−Schaltfläche (8) definieren Sie, wo Ihr(e) RSA−Schlüssel zu 

finden ist/sind. 

Zunächst ist natürlich noch kein Schlüssel in der "Identity list" bekanntgemacht. Über die 

New−Schaltfläche können Sie den Schlüssel−Pfad suchen (9. Schritt, hier ohne Bild). 

Dazu wird voreingestellt das SSH−WIN−Arbeitsverzeichnis angezeigt:


Bild: 3.5 Auswahl eines geheimen RSA−Schlüssels (hier: zdv117@zam054) 

Wählen Sie dort Ihren geheimen SSH−Schlüssel aus (10) und bestätigen Sie diese Wahl 

mit der Öffnen−Schaltfläche (11). Dann wird Ihnen in der "Identity list" links dessen 

vollständiger Pfadname und rechts dessen Hexa−Kennung angezeigt: 

Bild: 3.6 Pfad und Hexa−Wert des ausgewählten RSA−Schlüssels 

Mit OK bzw. ENTER (12) kommen Sie wieder zurück zum SSH−Verbindungsmenü (s. 

Bild 3.4). 

Dort sollten Sie im Feld "Profile Name:" eine aussagekräftige Bezeichnung eintragen (13) 

und diese Aufruf−Parameter mit der Save−Schaltfläche in die Registry retten (14), bevor 

Sie mit OK oder ENTER (15) die Verbindung starten. 

Bei der RSA−Authentisierung werden Sie dann nicht nach Ihrem Zielrechner−Paßwort, 

sondern nach Ihrem lokalen SSH−Geheimsatz (Passphrase) für den betreffenden 

RSA−Schlüssel gefragt:


Bild: 3.7 Eingabe des lokalen SSH−Geheimsatzes zur RSA−Authentisierung 

Bei dieser Art der Authentisierung verläßt kein Geheimnis Ihren Rechner. Ihr privater 

SSH−Schlüssel wird nämlich nur lokal benötigt, um eine vom SSH−Server für Sie 

verschlüsselte Botschaft zu entschlüsseln und diese dann modifiziert an den SSH−Server 

zurückzuschicken. Der erkennt daran, ob Sie im Besitz des passenden 

SSH−Geheimschlüssels sind, und akzeptiert das als Ihre Zugangsberechtigung. 

Dann können Sie ganz normal interaktiv auf den entfernten Rechner zugreifen. 

Mit exit beenden Sie diese interaktive Sitzung. Eventuell müssen Sie anschließend die 

SSH−WIN−Bedienoberfläche explizit mit −−> Action −−> Exit ganz beenden. 

4 Ausführung eines Befehls auf einem entfernten SSH−Server 

SSH−WIN erlaubt es, eine Befehlszeile, die im Command−Feld eingetragen ist (1), auf 

einem entfernten Rechner ausführen zu lassen (sichere Remote Execution): 

Bild: 4.1 Verbindungs−Maske mit mehreren entfernt, auf dem zentralen AIX−Rechner 

auszuführenden Befehlen 

Wenn Sie die Ausgabe der entfernt ausgeführten Befehle hier sehen möchten, dürfen Sie 

die Option "Close on exit" nicht aktivieren (2). 

Die Option "Receive LF as CR/LF" sollte Sie aber aktivieren (3), damit Sie 

Programm−Ausgaben an Ihrem PC zeilengerecht lesen können: 

Bild: 4.2 Ausgabe der entfernt ausgeführten Befehle


Der Status des zuletzt ausgeführten Befehls wird in der SSH−WIN−Statuszeile angezeigt. 

Sie haben aber bei der entfernte Befehlsausführung unter SSH−WIN − im Gegensatz zum 

SSH−DOS − keine Möglichkeit, diese von Ihrem Terminal aus zu steuern, können also 

auch keine seitenweise Anzeige anfordern (z.B. ls −lisa | more ). 

Wenn − wie in diesem Beispiel − die "Close on Exit"−Option nicht aktiviert war (2), muß 

man nun diese SSH−Sitzung selbst beenden (s. (4) und (5)): 

Bild: 4.3 Manuelle Beendigung der SSH−Sitzung 

Hinweis: Wenn Sie als entfernten Befehl xterm eintragen, erhalten Sie so ein komfortables 

X−Terminal des entfernten Rechners (s.u.). Im Handbuch ist erklärt, wie Sie sich dazu 

noch ein Icon erstellen. 

5 Tunnelung anderer Dienste über SSH−WIN 

Über eine bestehende interaktive SSH−Verbindung kann man andere TCP/IP−Dienste, 

deren Port−Zuordnung bekannt ist, verschlüsselt, also abhörsicher übertragen. 

5.1 Tunnelung von X11−Anwendungen 

Sicherheits−Vorbemerkung zur X11−Tunnelung 

Ulrich Flegel weist in The Interaction between SSH and X11 

(http://HOME.Braunschweig.Netsurf.De/~ulrich.flegel/pub/ssh−x11.ps.gz) auf die Gefahr 

hin, daß ein Angreifer, der an den Inhalt von $HOME/.Xauthority auf dem entfernten 

Rechner kommt, Ihrem lokalen X−Server beliebige Befehle zur Ausführung auf Ihrem 

lokalen Rechner schicken kann. Diese .Xauthority−Files sind nur durch die 

UNIX−File−Rechte geschützt. In seinem Papier skizziert er auch, wie man dann, wenn die 

HOME−Verzeichnisse per NFS exportiert werden, recht einfach an den Inhalt von 

Benutzer−Files kommt. Der Angriff ist noch einfacher, wenn der Angreifer ebenfalls eine 

Benutzer−Kennung auf dem entfernten Rechner hat. Unangenehm ist, daß durch 

Sicherheits−Lücken im entfernten Rechner Ihr lokaler Rechner attackierbar wird. 

Ursache dafür ist aber nicht SSH sondern X−11. Unter SSH aber können Sie diese 

X11−Tunnelung ganz abschalten. Das sollten Sie immer tun, wenn Sie keine 

X11−Anwendung auf dem Zielrechner starten wollen. 

Ganz gefährlich aber ist die Unsitte, mit dem xhost Zielrechner einen 

bestimmten Rechner oder gar mit xhost + weltweit allen Rechnern X−Zugriffe 

auf den lokalen X−Server zu erlauben. Wer so unverantwortlich handelt, dem hilft 

SSH nicht.


Am einfachsten aber ist die Tunnelung von X11−Anwendungen, weil SSH diese fast 

automatisch macht. Voraussetzung ist, daß Sie vorher auf Ihrem PC einen X11−Server im 

Passiv−Mode gestartet haben (s. TKI 0293). Weiterhin müssen Sie die Option "X11 

Forward" im SSH−Options−Menü aktiviert haben (s. Punkt 3): 

Bild: 5.1 SSH−Verbindungsmaske mit aktivierter X11−Tunnelung 

Auf dem entfernten Rechner aber dürfen Sie die DISPLAY−Variable nicht wie bisher 

selbst definieren. Denn nur wenn diese auf den entfernten Rechner zeigt, was Sie mit 

echo $DISPLAY kontrollieren sollten, wird eine X−Verbindung auch tatsächlich 

verschlüsselt, also sicher übertragen. Wenn die DIPLAY−Variable aber wie früher auf 

Ihren PC zeigt, dann können Sie diese X−Anwendung zwar weiterhin korrekt bedienen; Sie 

merken aber nicht, daß Sie diese X−Verbindung wie früher total unsicher betreiben. 

Kommentieren Sie dann die DISPLAY− bzw. autodisplay−Anweisung in Ihrem 

UNIX−Profile ($HOME/.profile) aus und starten Sie diese Verbindung neu. 

Dann können Sie auf dem entfernten Rechner eine X−Anwendung starten und 

abhörsicher bedienen. Mit xterm & können Sie sich z.B. ein komfortableres X−Term 

Fenster geben lassen: 

Bild: 5.2 Interaktiver Start eines xterm−Fensters auf dem entfernten Rechner und seine


Darstellung auf Ihrem PC 

5.1.1 Start eines X−Term−Fensters auf einem entfernten Rechner durch entfernte Befehlsausführung 

Wenn Sie allerdings nur ein X−Term eines entfernten Rechners benötigen, so genügt es, 

xterm−Aufruf als entfernten Befehl ausführen zu lassen (Sichere Remote Execution): 

Bild: 5.3 Entfernte Ausführung des xterm−Befehls 

Besonderheiten: 

xterm ist als entfernt auszuführenden Befehl (Command) eingetragen (2). 

Da die Option "Close on exit" aktiviert ist (4), wird die SSH−Bedienoberfläche 

automatisch beendet, sobald Sie später das X−Term−Fenster mit exit beenden. 

Die Option "Hide window" ist aktiviert (5). Dadurch wird die 

SSH−WIN−Oberfläche nicht angezeigt. Sie sehen nur das X−Term−Fenster. 

Kontrollieren Sie, ob die voreingestellte Option "X11 Forward" aktiviert ist (6). 

5.2 Tunnelung weiterer TCP/IP−Dienste, dargestellt am FTP−Dienst 

Wie Sie mit SSH beliebige andere TCP/IP−Dienste, deren Port−Nummer Sie kennen, 

sicher übertragen können, ist im folgenden für den interessierten Leser exemplarisch an der 

Tunnelung des FTP−Kommando−Kanals (Port 21) kurz skizziert. Im Handbuch wird 

dieses Anwendungs−Beispiel ausführlich besprochen. 

Dazu müssen Sie vorher aus dem SSH−Verbindungs−Optionsfenster über die Local 

Forwards−Schaltfläche den zu tunnelnde TCP/IP−Dienst festlegen. Das soll exemplarisch 

an der Tunnelung des FTP−Kommando−Kanals (Port 21) demonstriert werden, über den 

Ihr Paßwort und Ihre Benutzer−Kennung im Klartext übertragen werden. Leider kann 

man den eigentlichen FTP−Datentransfer nicht tunneln, da man nicht weiß, welche 

Port−Nummer der FTP−Server und der FTP−Client dafür aushandeln werden.


5.2.1 Konfiguration und Start des SSH−Tunnels zur sicheren Übertragung der FTP−Befehle 

Dazu ist SSH−WIN wie gewohnt zu starten und die "SSH options"−Eingabemaske 

auszufüllen: 

Bild: 5.4 Definition der Weiterleitung von FTP−Kommandos über Port 21 zum 

Zielrechner 


Durch die Aktivierung der Option "Hide window" (6) wird die interaktive 

SSH−Verbindung sofort in den Hintergrund gesetzt, sobald dieser SSH−Tunnel 

aufgebaut ist. 

Zur Tunnelung ist über die Local Forwards−Schaltfläche (8) die Forwards 

−Eingabemakse aufzurufen, dort mit der New−Schaltfläche eine neue 

Weiterleitungsmaske auszuwählen (9) und die Tunnelung von Port 21 (10) und (12) 

zu Ihrem Zielrechner (11) zu definieren. 

Statt Port 21 hätten Sie als lokales Port auch eine beliebige andere Nummer 

wählen können, z.B. 4711; Port 21 hat den Vorteil, daß dies bei Ihrem 

FTP−Programm die voreingestellte Port−Nummer ist, Sie dort also die 

Voreinstellung übernehmen können (s.u.). 

Die Option "Only local" muß unbedingt aktiviert sein (13), damit kein anderer, der 

weiß, daß Sie diesen Tunnel aufgebaut haben, diesen unbemerkt mitbenutzen kann.


Mit OK bzw. ENTER übernehmen Sie diese Forwarding−Einstellungen (14) und 

kommen wieder zum "SSH options"−Menü zurück. 

Es empfiehlt sich, diese Einstellungen einen Profile−Namen zu geben (15) und mit 

der Save−Schaltfläche in der Registry zu retten (16). 

Nun können Sie sich − wie gewohnt − mit OK bzw. ENTER mit dem SSH−Server 

verbinden (17) und sich entweder mit Ihrem SSH−Geheimsatz oder mit Ihrem 

Zielrechner−Paßwort ausweisen. Im zweiten Schritt müssen Sie nun am PC die 

FTP−Software starten und konfigurieren. Das wird im folgenden exemplarisch für das 

WS_FTP−Client−Programm gezeigt. 

5.2.2 Konfiguration und Start des WS_FTP−Client−Programms 

Rufen Sie das WS_FTP−Programm auf und definieren Sie sich als erstes einen eigenen 

Profile (Session Profile), der seine FTP−Befehl lokal auch tatsächlich zur Verschlüsselung 

an das vorher gestartete SSH−Client−Programm übergibt, also das SSH−Tunnel auch 

wirklich benutzt: 

Bild: 5.5 Erstellung eines WS_FTP−Profiles und Festlegung weiterer 

FTP−Zusatzparameter 


Als Zielrechner ("Host Name") tragen Sie localhost bzw. 127.0.0.1 ein (1). 

Dadurch sendet Ihr FTP−Client seine sensitiven FTP−Befehle an das lokal laufende 

SSH−Client−Programm. 

Mit der Advanced−Schaltfläche rufen Sie eine erweiterte Eingabe−Maske (5).

SSH−WIN PC−Benutzeranleitung - Forschungszentrum Jülich

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?