Secure Shell (SSH)
Kommunikation im Flüsterton

von Peter Marksteiner, Heinrich Mislik & Robert Brunnthaler (Ausgabe 00/3, Oktober 2000)

 

Secure Shell? Was ist das?

Computersicherheit ist der Schwerpunkt dieser Comment-Ausgabe (siehe auch Seite 2, Seite 20 und http://www.univie.ac.at/ZID/security/). Der folgende Artikel kann ebenfalls dieser Kategorie zugeordnet werden: Secure Shell (SSH) ist ein Netzwerkprotokoll, das den Datenverkehr zwischen zwei Rechnern in verschlüsselter Form abwickelt und somit einen guten Schutz gegen gewisse Angriffe aus dem Netzwerk (packet sniffing und spoofing)1) bietet. SSH kann für folgende Aufgaben eingesetzt werden:

  • als Terminalemulation (remote login, Ersatz für Telnet),
  • für Dateiübertragung (remote copy, Ersatz für FTP),
  • zum Ausführen von Befehlen auf anderen Servern (remote execution) und
  • zum "Tunneln" beliebiger Protokolle: Praktisch der gesamte Netzverkehr - vor allem auch eMail - kann bei Bedarf verschlüsselt übertragen werden.

Wer braucht das?

Während spoofing eher selten ist und nur von hochmotivierten Hackern mit profunden technischen Kenntnissen durchgeführt wird, ist packet sniffing in vielen Netzen eine reale Gefahr. In folgenden Situationen wird die Verwendung der Secure Shell empfohlen:

  • Prinzipiell als Ersatz für Telnet und FTP: Die Secure Shell funktioniert genauso komfortabel, bietet aber erhöhte Sicherheit. Wenn Sie selbst einen Server betreiben, sollten Sie - wenn möglich - Telnet- und FTP-Zugriffe überhaupt verbieten und nur SSH-Verbindungen zulassen.
  • Wenn jemand aus einem "Fremdnetz" (z.B. während eines Auslandsaufenthalts) auf den Mailbox-Rechner zugreifen will, um einerseits mit POP3 eMail abzuholen und andererseits mit FTP seine Homepage zu warten. In diesem Fall wäre es vollkommen sinnlos, secure copy anstatt FTP zu verwenden, solange alle paar Minuten eine POP3-Anfrage das Paßwort unverschlüsselt über das Netz schickt. Hier empfiehlt sich das Verschlüsseln des eMail-Verkehrs mit Hilfe eines SSH-Tunnels. Innerhalb des Datennetzes der Universität Wien ist die Gefahr geringer; bei erhöhtem Sicherheitsbedürfnis ist ein SSH-Tunnel jedoch auch hier angebracht.

Obwohl sich der Aufbau eines Tunnels weitgehend automatisieren läßt, ist die Konfiguration eines Mail-Klienten mit SSH-Tunnel relativ umständlich. Es gibt auch Alternativen, um eMail sicher zu bearbeiten: Entweder mittels slogin auf dem Mailserver oder mittels Webmail über Secure HTTP. Für Unet- und Mailbox-Benutzer wird eine solche Webmail-Lösung demnächst angeboten werden. Generell wenig Sinn macht ein SSH-Tunnel bei Verwendung des Wählleitungszugangs zur Uni Wien.

Wie geht das?

Um die Funktionsweise der Secure Shell zu verstehen, benötigt man Grundkenntnisse der Kryptographie und der Client/Server-Kommunikation. Das Client/Server-Prinzip, auf dem fast alle Verbindungen in Computernetzwerken basieren, sei im folgenden kurz erläutert:

Ein Server ist ein Rechner im Netzwerk, der ständig in Betrieb ist und Anfragen von Klienten entgegennimmt und bearbeitet. Als Klienten bezeichnet man die Netzwerkprogramme (z.B. Mailprogramme, Web-Browser), die auf den lokalen Arbeitsplatzrechnern installiert sind. Server und Klienten kommunizieren nach wohldefinierten Regeln (Protokollen). Solange diese Regeln eingehalten werden, können sich die unterschiedlichsten Klienten auf verschiedensten Rechnertypen mit beliebigen Servern verständigen. Beispiele für Protokolle sind die bereits erwähnten Protokolle Telnet und FTP (file transfer protocol); das hypertext transfer protocol (HTTP), auf dem das WWW beruht; das simple mail transfer protocol (SMTP) bzw. das post office protocol (POP3) zum Verschicken bzw. zum Abholen von eMail - und auch das Secure Shell-Protokoll. Leider gibt es von letzterem zwei Versionen (SSH1 und SSH2), die teilweise inkompatibel sind, sodaß nicht jeder SSH-Klient mit jedem Server kommunizieren kann.

Damit ein Klient eine Verbindung zu einem Server aufbauen kann, muß zusätzlich zur Netzwerkadresse (IP-Adresse) des Servers auch der Port angegeben werden - das ist ein durch eine eindeutige Nummer identifizierter Kommunikationskanal. Ein Server ist imstande, auf mehreren Ports gleichzeitig Verbindungen entgegenzunehmen und so verschiedene Services anzubieten (z.B. WWW und eMail). Für viele Protokolle gibt es bereits vordefinierte Ports: Beispielsweise ist Port 22 für Secure Shell vorgesehen, Port 23 für Telnet, Port 25 für SMTP, Port 80 für HTTP und Port 110 für POP3. Die Zuordnung von Protokollen zu Ports ist eine Konvention, die im RFC 17002) definiert ist, aber keine absolute Notwendigkeit. Zahlreiche Webserver verwenden z.B. andere Ports als den Standard-Port 80; der URL erweitert sich dann um einen Doppelpunkt und eine Zahl, die den Port bezeichnet (z.B. aleph.univie.ac.at/ALEPH).

Der Aufbau einer Secure Shell-Verbindung funktioniert nun folgendermaßen:

  1. Nachdem der SSH-Klient den Server kontaktiert hat, schickt ihm der Server seinen public key.
  2. Der Klient hat Zugriff auf eine Datei (diese heißt üblicherweise known_hosts) mit den public keys aller Server, denen der Klient vertraut. Wenn es für den kontaktierten Server keinen Eintrag in dieser Datei gibt, wird die Verbindung nur dann errichtet, wenn man bestätigt, diesen Schlüssel zu akzeptieren. Er wird dann in die Liste der known hosts aufgenommen. Falls es einen Eintrag mit einem unterschiedlichen Schlüssel gibt, liegt der Verdacht auf spoofing nahe; der Verbindungsaufbau wird dann meistens mit einer Fehlermeldung abgebrochen (manche Klienten liefern nur eine Warnung und stellen es dem Benutzer frei, die Verbindung dennoch zu errichten).
  3. Wie auf Seite 21 beschrieben, wird der public key zum sicheren Austausch eines symmetrischen Schlüssels verwendet; der Rest der Verbindung wird nach einem symmetrischen Verfahren (3DES, Blowfish) verschlüsselt.
  4. Die Authentifizierung des Klienten gegenüber dem Server kann wie gewohnt mittels Paßwort erfolgen, das verschlüsselt übertragen wird. Es kann aber auch der Server eine Datei (üblicherweise authorized_keys) mit den public keys aller Klienten führen, die sich ausreichend authentifiziert haben. Der Klient authentifiziert sich dadurch, daß er eine vom Server geschickte "Herausforderung" (challenge) mit seinem private key entschlüsseln kann. Diese Art von Verbindung eignet sich sehr gut für automatische Prozeduren, die ohne händische Eingriffe (Eintippen von Paßwörtern) auskommen müssen.

Tunnel

Mit Hilfe eines Tunnels kann der Datenverkehr beliebiger Protokolle3) - also auch POP3 - verschlüsselt übertragen werden. Dies geht folgendermaßen vor sich:

  • Der SSH-Klient wartet auf einem bestimmten Port auf Netzwerkverbindungen (z.B. auf Port 110 auf Verbindungen von einem POP3-Klienten), d.h. der SSH-Klient übernimmt auch die Funktion eines Servers. Da solche Verbindungen üblicherweise nur vom lokalen Rechner (dem localhost) aus aufgebaut werden, wird der SSH-Klient bei einer POP3-Verbindung als localhost:110 adressiert.
  • Sobald eine Verbindung zu diesem Port des SSH-Klienten aufgebaut wird, errichtet der SSH-Klient eine Verbindung zum SSH-Server (dem sogenannten ssh daemon) am gewünschten Server. Diese Verbindung wird als Tunnel bezeichnet; alle Daten, die an den SSH-Klienten geschickt werden, werden automatisch verschlüsselt und durch diesen Tunnel weitergeleitet.
  • Der SSH-Server entschlüsselt die Daten und reicht sie an den endgültigen Adressaten weiter - z.B. an den POP3-Server, der aus der Sicht des SSH-Servers ebenfalls als localhost:110 angesprochen werden muß.

Unverschlüsselte Verbindungen gibt es nur lokal: zwischen Mailprogramm (POP3-Klient) und SSH-Klient bzw. zwischen SSH-Server und POP3-Server (siehe Abb. 1).

Abb. 1: POP3-Verbindung ohne (oben) und mit (unten) SSH-Tunnel
Abb. 1: POP3-Verbindung ohne (oben) und mit (unten) SSH-Tunnel

Um eMail über einen SSH-Tunnel abzuholen, sind also zwei Schritte notwendig: Zuerst müssen Sie in der Konfiguration Ihres Mailprogramms als POP3-Server localhost eintragen (der Port 110 ist schon vorkonfiguriert) und anschließend mit Hilfe des SSH-Klienten den Tunnel errichten. Solange kein Tunnel besteht, versucht das Mailprogramm, die für Sie am Mailserver neu eingelangten Nachrichten vom lokalen SSH-Klienten zu erhalten, was natürlich nicht funktioniert.

Ein Spezialfall ist der X11-Tunnel (X11 ist das Protokoll, das für netzwerkfähige grafische Unix-Applikationen verwendet wird): Dabei laufen die Daten vom Server zum Klienten und erlauben das Ausführen von X-Applikationen. Durch X11-Authentication wird sichergestellt, daß nur der Benutzer den Tunnel verwenden kann, der die Verbindung aufgebaut hat.

SSH-Server

Mit OPEN-SSH 2.0 (http://www.openssh.com/) steht auf den Servern des Zentralen Informatikdienstes eine Software zur Verfügung, die folgende Funktionen unterstützt:

  • SSH-Protokoll 1 und 2
  • RSA- und DSA-Schlüssel
  • Symmetrische Kryptisierung mit 3DES (Standardeinstellung) oder Blowfish
  • Authentifizierung mit private key oder Paßwort
  • Interaktives Arbeiten (slogin)
  • Datentransfer (scp)
  • Ausführen von Befehlen (ssh)
  • Verschlüsselung beliebiger Protokolle mittels Tunnelling
  • Spezielle Unterstützung für X11-Tunnelling

Diese Software kommt zur Zeit auf folgenden Servern zum Einsatz:

  • MAILBOX.UNIVIE.AC.AT
  • UNET.UNIVIE.AC.AT (ohne X11)
  • WWW.UNIVIE.AC.AT (ohne X11)
  • RS6000.UNIVIE.AC.AT
  • ALPHA.UNIVIE.AC.AT

Auf UNET.UNIVIE.AC.AT befindet sich das Homedirectory auf einem DFS-Filesystem und steht daher während des Loginvorgangs noch nicht zur Verfügung. Deshalb funktionieren manche SSH-Features nicht, die Zugriff auf dieses Verzeichnis brauchen (z.B. Authentifizierung mit private key).

Eine etwas andere SSH 2.0-Version, die zusätzlich noch sftp unterstützt, ist auf den Servern

  • MERLIN.AP.UNIVIE.AC.AT (Außenstelle Physik des ZID)
  • EMB1.BCC.UNIVIE.AC.AT (Außenstelle Biochemie)

verfügbar. Näheres dazu - auch eine kurze Beschreibung eines geeigneten Windows-Klienten - finden Sie auf Seite 27.

Die public keys aller genannten Server sind unter https://www.univie.ac.at/keys/ zu finden.

SSH-Klienten

Im folgenden werden einige von uns getestete SSH-Klienten für Unix und Windows vorgestellt; weitere SSH-Klienten für verschiedene Plattformen (auch für Macintosh) finden Sie unter http://www.freessh.org/.

Unix

Die Secure Shell wurde ursprünglich für Unix-Systeme entwickelt und erst später auf verschiedene Windows-Plattformen portiert. Die Befehle ssh, slogin und scp sind die "sicheren" Äquivalente zu den bekannten Unix-Befehlen rsh (remote shell), rlogin (remote login) und rcp (remote copy). Es gibt etliche SSH-Klienten für Unix, bei den Befehlen und Optionen findet man jedoch nur geringe Unterschiede. Details dazu sind auf Unix- oder Linux-Systemen in der entsprechenden Online-Dokumentation (man pages) zu finden, z.B. mit man slogin. Die wichtigsten Funktionen seien hier anhand einiger Beispiele illustriert:

  • Login auf einem anderen Rechner:
    slogin -l remoteuser remotehost
    (z.B.: slogin -v -l broesef7 mailbox.univie.ac.at)
    Anm.: Alle SSH-Befehle können mit der Option -v ("verbose") aufgerufen werden, die bei der Fehlersuche sehr nützlich ist.
  • Übertragen einer Datei:
    scp localfile remoteuser@remotehost:remotefile
    (z.B.: scp index.html broesef7@mailbox.univie.ac.at:html/index.html)
    Anm.: Beim SSH-Klienten von ssh.com (siehe Seite 27) ist scp ein Alias für sftp; daher muß hier der Befehl scp1 verwendet werden, wenn der Server das sftp-Protokoll nicht unterstützt.
  • Ausführen eines Befehls auf einem anderen Rechner:
    ssh -l remoteuser remotehost "ls -l"
    (z.B.: ssh -l broesef7 mailbox.univie.ac.at "ls -l")
  • Aufbau eines POP3-Tunnels:
    ssh -L 60000:localhost:110 remotehost
    (z.B.: ssh -L 60000:localhost:110 mailbox.univie.ac.at)
    Anm.: Unter Unix sind die Ports 1 bis 1023 dem Benutzer root vorbehalten. Daher muß für POP3 ein freier Port mit hoher Nummer (1024 bis 65535) verwendet werden, sofern man keine root-Privilegien hat. Wählt man einen hohen Port (z.B. 60000), muß dieser auch in die Konfiguration des Mailklienten eingetragen werden.

PuTTY & PSCP (für Windows)

Diese beiden Programme (Autor: Simon Tatham; zu finden unter http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html) bestechen durch ihre Einfachheit: Sie bestehen jeweils nur aus einer .exe-Datei und haben gemeinsam auf einer Diskette Platz.

Eine Installation ist nicht erforderlich. Will man PuTTY aus dem Programm-Menü starten, muß man selbst eine entsprechende Verknüpfung erstellen. Es empfiehlt sich, beim Programmaufruf die Option -ssh anzugeben. Wenn dann das Dialogfenster zur Eingabe der Verbindungsdaten erscheint, ist der Punkt SSH bereits ausgewählt; man muß nur noch den Hostnamen eingeben und auf Open klicken. Bei der ersten Verbindung zu einem bestimmten Rechner fragt das Programm, ob der public key dieses Servers (hostkey) gespeichert werden soll.4) Im anschließend erscheinenden Terminalfenster verlangt das Programm mit dem Text login as: Ihre UserID, danach Ihr Paßwort. Eine Besonderheit des SSH-Protokolls ist, daß nach einem Login-Fehlversuch nur das Paßwort nochmals verlangt wird - hat man sich bei der UserID vertippt, muß man den Vorgang durch Schließen des Fensters beenden und von vorne beginnen.

PSCP ist ein Programm zur Dateiübertragung und hat im wesentlichen dieselben Optionen wie die Unix-Variante scp. Es arbeitet über Befehlszeilen und muß daher in einem Eingabe-Fenster gestartet werden. Interessant ist die Option -ls , welche es ermöglicht, Inhaltsverzeichnisse vom Host abzurufen. Der Kopiervorgang kann entweder vom lokalen Rechner zum Host oder umgekehrt erfolgen. Dabei gilt, daß ein Dateiname, der einen Doppelpunkt enthält, als Hostdatei verarbeitet wird. Die Syntax lautet user@host:path, wobei path relativ zum Homeverzeichnis des Benutzers user angenommen wird. Einige Beispiele veranschaulichen die Funktionalität am besten:

  • pscp -ls hugok4@mailbox.univie.ac.at
    (Inhalt des Homeverzeichnisses von hugok4 ansehen)
  • pscp default.html a1234567@unet.univie.ac.at:html/index.html
    (Kopieren der Datei default.html vom lokalen Rechner zum Host unter einem anderen Namen)
  • pscp -r y1234uaa@rs6000.univie.ac.at:daten c:\
    (Kopieren des Verzeichnisses daten mit allen Unterverzeichnissen vom Host zum lokalen Rechner)

Fazit: Klein, aber fein. Besonders empfehlenswert, wenn man unterwegs eMail lesen möchte.

TeraTerm & TTSSH (für Windows)

Dieses Paket bietet wesentlich mehr Funktionsumfang als PuTTY & PSCP. TeraTerm ist ein ausgezeichneter Terminalemulator des japanischen Autors T. Teranishi; TTSSH wurde von Robert O'Callahan entwickelt und ist eine Erweiterung dazu, die das SSH-Protokoll implementiert. Die aktuellen Versionen finden Sie unter http://hp.vector.co.jp/authors/VA002416/teraterm.html (TeraTerm) und http://www.zip.com.au/~roca/download.html (TTSSH).

Die Installation erfolgt in zwei Schritten: Zunächst wird TeraTerm nach Entpacken der ZIP-Datei und Starten von setup.exe wie gewohnt installiert. Danach müssen die Dateien aus der TTSSH-ZIP-Datei in dasselbe Verzeichnis kopiert werden, in das zuvor TeraTerm installiert wurde. Will man das Programm über das Start-Menü zur Verfügung haben, muß man eine entsprechende Verknüpfung für die Datei ttssh.exe herstellen. Die Verknüpfung, die während der Installation von TeraTerm angelegt wurde, startet den Terminalemulator ohne SSH-Erweiterung.

Der Verbindungsaufbau verläuft ähnlich wie bei PuTTY. Nach dem Programmstart erhält man ein Fenster mit den Verbindungsdaten. Hier müssen Sie den gewünschten Hostnamen eingeben und auf OK klicken. Es folgt die Überprüfung des hostkey; wenn dieser in der Datei known_hosts nicht gefunden wird, erscheint eine Warnung. Man kann dann entweder die Verbindung abbrechen oder den unbekannten hostkey akzeptieren und optional in die known_hosts-Datei aufnehmen. (Ist der hostkey des gewünschten Servers aus einer anderen, sicheren Quelle bereits bekannt, kann man ihn schon vor dem Programmstart mit einem Texteditor in die Datei ssh_known_hosts eintragen, die sich im TeraTerm-Installationsverzeichnis befinden muß.) Das folgende Fenster dient der Authentifizierung am Server. Man gibt UserID und Paßwort (hier Passphrase genannt) ein, wählt Use plain password to log in und klickt auf OK. Auch hier gilt, daß eine Fehleingabe bei der UserID nicht korrigiert werden kann.

Wer viel in Terminalfenstern arbeitet, wird die gute und einfache Konfigurierbarkeit von TeraTerm schätzen lernen. Alle Einstellungen sind im Menüpunkt Setup vorzunehmen. Unter Font können Sie eine Ihnen genehme Schriftart aussuchen und unter Terminal unter anderem die Größe des Fensters bestimmen, in dem Sie arbeiten wollen. Falls Sie sich auf mehreren Rechnern per SSH einloggen, empfehle ich Ihnen, Ihre Terminalfenster je nach Rechner verschieden einzufärben. Sie sehen dann sofort, auf welchem Rechner Sie sich gerade befinden, und die Gefahr, ein rm -rf * (der Unix-Befehl zum Löschen aller Dateien und Unterverzeichnisse) versehentlich in einem Terminalfenster einzugeben, wo man es auf keinen Fall tun hätte sollen, wird wesentlich geringer. Stellen Sie sich für jeden Host, auf den Sie zugreifen, die gewünschten Parameter ein und speichern Sie diese mittels Klick auf Setup - Save Setup in einer separaten Konfigurationsdatei (z.B. www.ini).

Nachdem Sie eine solche Konfigurationsdatei erstellt haben, können Sie sich für jeden Rechner, zu dem Sie Kontakt aufnehmen, eine Verknüpfung auf Ihren Bildschirm "zaubern": Klicken Sie mit der rechten Maustaste auf Ihren Desktop, wählen Sie Neu - Verknüpfung und anschließend die Datei ttssh.exe (meistens zu finden unter C:\Programme\TTERMPRO\ttssh.exe). Nun wird ein neues Symbol erstellt. In den Eigenschaften dieses Symbols erweitern Sie unter Verknüpfung - Ziel den Programmaufruf um die Einträge hostname:22 und /F=hostname.ini, also z.B. C:\Programme\TTERMPRO\ttssh.exe www.univie.ac.at:22 /F=www.ini (siehe Abb. 2). Diese Zeile bewirkt, daß nach Doppelklick auf das neue Symbol eine Verbindung zum SSH-Port des Rechners WWW.UNIVIE.AC.AT aufgebaut und die unter www.ini gesicherte Konfiguration geladen wird.

Abb. 2: Verknüpfung für TTSSH-Konfigurationsdatei erstellen
Abb. 2: Verknüpfung für TTSSH-Konfigurationsdatei erstellen

Auch wenn Sie sich nie per Telnet/SSH in einen Rechner einloggen, kann Ihnen TeraTerm gute Dienste erweisen: Sie können damit beliebige Protokolle "tunneln" und somit abhörsicher machen. Ein Protokoll, das Sie sicher verwenden, ist jenes, mit dem Sie eMail vom Server holen: POP3 oder IMAP. Das Abholen erledigt Ihr Mailprogramm für Sie - irgendwann haben Sie den Namen Ihres POP3- oder IMAP-Servers eingetragen (POP.UNET.UNIVIE.AC.AT für Studierende, MAILBOX.UNIVIE.AC.AT für Uni-Mitarbeiter), haben Ihren Benutzernamen angegeben und womöglich Ihr Paßwort im Mailprogramm abgespeichert. Jedesmal, wenn Ihr Mailprogramm am Server nachsieht, ob neue Nachrichten für Sie da sind, wird Ihre UserID-/Paßwort-Kombination im Klartext zum Server übertragen und kann, wenn sich Ihr Rechner in einem unsicheren Netz befindet, abgehört werden! Die Klärung der Frage, ob Ihr Rechner in einem "sicheren" Netz hängt, benötigt sicher mehr Zeit als die Erstellung eines Tunnels mit Hilfe von TeraTerm - und ein Tunnel schadet auch in einem sicheren Netz nicht. Wie im Abschnitt Tunnel beschrieben, sind zwei Schritte notwendig, um den Datenverkehr zwischen Ihrem Rechner und dem Mailserver zu verschlüsseln:

  • Zuerst muß ein Tunnel eingerichtet werden: Klicken Sie im TeraTerm-Fenster auf Setup - SSH Forwarding... und dann im TTSSH: Forwarding Setup-Dialog auf Add.
  • Im Fenster SSH Port Forwarding (siehe Abb. 3) aktivieren Sie Forward local port und geben das Protokoll an, über das Sie Ihre eMail-Nachrichten erhalten (pop-3 oder imap).
  • Das Feld to remote machine lassen Sie frei und tragen das Protokoll auch im Feld port ein.
  • Durch Klick auf OK wird der Tunnel Ihrer Konfiguration hinzugefügt, und Sie können auch den TTSSH: Forwarding Setup-Dialog durch Klick auf OK wieder beenden.
  • Speichern Sie die Konfiguration wie vorhin beschrieben.
  • Erstellen Sie eine Verknüpfung am Desktop (siehe weiter oben) und tragen Sie als hostname den Namen Ihres Mailservers ein (z.B. C:\Programme\TTERMPRO\ttssh.exe mailbox.univie.ac.at:22 /F=mailbox.ini).
  • Ein Doppelklick auf diese Verknüpfung und die Eingabe von UserID und Paßwort im SSH Authentication-Dialogfenster baut den Tunnel auf. Vorsicht: Das ganze funktioniert nur, wenn Ihr Rechner eine bestehende Internetverbindung hat. Falls Sie per Modem einwählen, müssen Sie diese zuerst herstellen.
  • Im zweiten Schritt müssen Sie in der Konfiguration Ihres Mailprogramms den Namen des Posteingangsservers auf localhost ändern. Wo Sie dies einstellen können, entnehmen Sie bitte unseren Konfigurationsanleitungen.
Abb. 3: Dialogfenster SSH Port Forwarding
Abb. 3: Dialogfenster SSH Port Forwarding

Diese Einstellungen müssen Sie nur einmal vornehmen. Ihr Mailprogramm funktioniert in dieser Konfiguration allerdings nur bei aktiviertem Tunnel. Falls Ihr Rechner über eine permanente Internetverbindung verfügt, spricht nichts dagegen, den Tunnel immer aktiv zu lassen, während Ihr Rechner läuft. Sie müssen nur einmal nach dem Rechnerstart auf das TTSSH-Icon doppelklicken und sich authentifizieren. Alles funktioniert dann wie vorher. Nur sicher.

 

1) Unter packet sniffing versteht man das Abhören des gesamten Datenverkehrs in einem bestimmten Netzwerkbereich durch einen anderen Netzteilnehmer. Da mit SSH alle Daten (also auch alle Paßwörter) verschlüsselt übertragen werden, sind die erlauschten Informationen für den Übeltäter wertlos. Spoofing (IP oder DNS spoofing) bedeutet, daß ein Server X im Netzwerk mit Hilfe verschiedener Tricks vortäuscht, Server Y zu sein, und daher Verbindungen von Klienten entgegennehmen kann, die an Server Y gerichtet sind. Bei Verwendung der Secure Shell hat der Klient jedoch die Möglichkeit, die Identität des Servers anhand eines Zertifikats zu überprüfen.

2) http://ftp.univie.ac.at/netinfo/rfc/rfc1700.txt oder http://ftp.univie.ac.at/netinfo/assignments/port-numbers

3) Bei manchen Protokollen ist das Tunneln schwierig, weil mehrere Verbindungen auf unterschiedlichen Ports beteiligt sind: Beim FTP-Protokoll gibt es z.B. die Datenverbindung (Port 20) und die Kontrollverbindung (Port 21). Daher ist es einfacher, anstatt eines FTP-Tunnels scp zu verwenden.

4) Bei PuTTY ist es nicht so einfach möglich, die hostkeys bereits im vorhinein zu speichern: Die hostkeys werden im Windows-Registry in einem eigenen Format abgelegt, da es keine known_hosts-Datei gibt.