OpenSSH hat sich zum Standard-Tool für verschlüsselte Remote-Logins entwickelt. Wer die Sicherheitsfunktionen dieses Wekzeugs richtig nutzen will, kann etwas Hintergrundwissen gut brauchen.

Sie sind immer noch an der Tagesordnung: Computernetze, in denen Protokolle wie Rsh, Rlogin, Telnet, FTP und POP3 die Passwörter im Klartext durch das LAN und über Internet-Verbindungen schicken. Dass jeder Host auf der Strecke zwischen Client und Server die Passwörter lesen kann, ist eigentlich bekannt. Wie leicht es geht, zeigen Paketsniffer wie Sniffit oder Dsniff.

Solche Netze sind ein gefundenes Fressen für Cracker und Skript-Kiddies. Die eben erwähnten Dienste rangieren bei ihnen auf den ersten Plätzen der Exploitable-Skala. Dabei gibt es keinen Grund, dieses Risiko einzugehen. Mit SSH steht eine vollwertige Alternative zur Verfügung, die wesentlich mehr Funktionen als Rlogin, Rcp oder Telnet hat.

Neben der gesicherten Authentifikation von Hosts und Usern gewährleistet SSH die verschlüsselte Datenübertragung und erkennt Manipulationen. Der Begriff SSH bezeichnet sowohl das kryptographische Protokoll als auch dessen konkrete Implementierung. Anders als bei IPSec, bei dem die Verschlüsselung auf IP-Ebene stattfindet, realisiert SSH sie in der Applikation selbst.

Installation von SSH

Aktuelle Linux-Distributionen enthalten in der Regel bereits OpenSSH-Pakete. In einem Debian-System zeigt »dpkg -L ssh«, welche SSH-Files installiert sind. Dieselbe Auskunft gibt in RPM-basierten Systemen »rpm -ql openssh«.

Das Postinstall-Skript erzeugt die Schlüsselpaare (öffentlicher und privater Key) des Servers für beide Protokollversionen. Für SSH1 sind das die Dateien »ssh_host_key« und »ssh_host_key.pub«. SSH2 kann RSA- und DSA-Schlüssel verwenden, die bei RSA in »ssh_host_rsa_key« und »ssh_host_rsa_key.pub« liegen, bei DSA in »ssh_host_dsa_key« und in »ssh_host_dsa_key.pub«.

Alle privaten Schlüssel des Servers (ohne Datei-Erweiterung ».pub«) dürfen nur für Root les- und schreibbar sein. Die insgesamt sechs Key-Dateien benutzt der Server, um sich gegenüber unterschiedlichen Clients zu authentifizieren. Fehlt ein Teil der Schlüssel, kann ein Client, der eine bestimmte Schlüsselart benötigt, keine Verbindung herstellen. Bei Bedarf lassen sich fehlende Server-Keys mit dem Kommando »ssh-keygen« nachträglich erzeugen.

Die Konfig-Datei »/etc/ssh/ssh_config« enthält systemweite Vorgaben für das Client-Programm »ssh«; sie ist im Normalfall fast leer. Jeder User kann seinen Client mit »~/.ssh/config« (oder per Kommandozeile) konfigurieren.

Konfiguration des Servers

Der SSH-Server »sshd« arbeitet in der Regel als eigener Daemon, er kann aber auch vom Inetd gestartet werden. Die Daemon-Methode ist deutlich schneller, da »sshd« beim Starten erst einen Server-Key für SSH1 berechnen muss. Die Inetd-Variante bietet sich aber als praktische Fallback-Lösung an: Sollte der Daemon doch einmal abstürzen, kann sich der Admin immer noch remote einloggen und das Problem beheben. Dieser zweite Server muss auf einem anderen Port lauschen (»sshd -i -p Port«). Die Portnummer lässt sich auch im Konfig-File verändern (Listing 1, Zeile 8).

Hat ein Host mehrere IPs, kann der Admin festlegen, auf welche dieser Adressen »sshd« hören soll. Per Default bindet sich der Daemon an alle. Mit »ListenAddress IP« (Zeile 11) lässt sich das ändern; diese Option darf auch mehrfach vorkommen.

Normalerweise landen die Logging-Ausgaben von »sshd« über Syslog in der Datei »/var/log/auth.log« mit »LogLevel INFO« als Ausführlichkeitsstufe. Bei der Fehlersuche sind zusätzliche Logging-Infos hilfreich: »VERBOSE« ist die nächsthöhere Stufe und spätestens mit »DEBUG« lässt sich Server-seitig eigentlich immer der Grund für das Scheitern von Verbindungen finden (Zeilen 24 und 25).

Bei der Konfiguration des Servers kann man entscheiden, welche Protokollversionen er beim Handshake benutzen soll. Seit OpenSSH 2.9 ist SSH 2 gefolgt von SSH 1 Default: »Protocol 2,1« (Zeile 9). Will man nur SSH2 erlauben, muss der Eintrag »Protocol 2« lauten.

Listing 1: Server-Konfig >>sshd_config

Authentifikations-Verfahren

SSH kennt in beiden Protokollversionen mehrere Wege, um User zu authentifizieren. Die ausgefeilteste Variante ist das Public-Key-Verfahren, aktiviert durch »PubkeyAuthentication yes« (Zeile 35). Dabei legt ein User seinen Public Key im Homeverzeichnis ab und authentifiziert sich mit dem passenden Private Key. Die Defaults des Servers und die OpenSSH-Pakete vieler Distributionen erlauben auch die Passwort-basierte Authentifizierung mit »PasswordAuthentication yes« (Zeile 50). Die wenigsten Admins ändern das und die User benutzen »ssh«, ohne sich über die besten Features Gedanken zu machen.

Wer größtmögliche Sicherheit beim Login anstrebt, kann auf die Einstellung »PasswordAuthentication no« zurückgreifen. Die Passwörter überträgt SSH zwar verschlüsselt, ihre prinzipiellen Schwächen bleiben aber bestehen (häufig zu kurz, zu leicht zu erraten, zu selten geändert und andere). Es gibt sogar Ansätze, durch eine Timing-Analyse der verschlüsselten Daten indirekt auf die verwendeten Passwörter zu schließen, ohne die Daten dabei zu entschlüsseln (SSH Keystroke Timing Attack). Ein Login per Passwort ist allerdings erst dann wirklich ausgeschlossen, wenn zusätzlich »PAMAuthenticationViaKbdInt no« (Zeile 58) gesetzt ist.

Das unsichere Rhost-Verfahren ist in der Grundeinstellung des Servers ausgeschaltet (Zeilen 38 bis 41). Bei dieser Trusted-Host-Authentifizierung benennen die Dateien »/etc/hosts.equiv« und »~/.rhosts« vertrauenswürdige Rechner, von denen ein Login ohne Authentifikation erfolgen darf – der Server vertraut dann dem Client-Rechner und der dort bereits erfolgten Authentifikation.

Beim Rhosts-Verfahren überprüft der Server nur die IP-Adresse und Port-Nummer des Clients. Ist die Port-Nummer kleiner als 1024, muss der Client-Prozess auf Unix-Rechnern über Root-Rechte verfügen. Das soll verhindern, dass einfache User-Programme eine falsche Kennung an den Server weitergeben. Das ganze Modell vertraut aber darauf, dass die IP-Adressen und Ports korrekt sind. In den heutigen Netzen ist diese Annahme aber meist leichtsinnig.

Hosts vertrauen sich gegenseitig

SSH beherrscht eine wesentlich bessere Variante der Host-basierten Authentifizierung. Hier muss sich das Client-Programm mit dem Host-Key des Client-Rechners authentifizieren. Um überhaupt Zugang zu diesem Schlüssel zu haben, benötigt es Root-Rechte (Set-UID-Bit gesetzt). SSH vertraut dann zusätzlich den Hosts in »~/.shosts« und »/etc/shosts.equiv«; die Default-Einstellung schließt aber auch dieses Verfahren aus (Zeilen 42 bis 45).

In vielen Fällen ist es unerwünscht, dass sich ein Nutzer direkt als Root anmeldet. Besonders wenn mehrere User den Root-Account nutzen können, wird es schwer nachvollziehbar, welcher Admin gerade eingeloggt ist. Mit der Option »PermitRootLogin no« (Zeile 31) können sich nur noch normale Benutzer anmelden. Wer zusätzlich Admin ist, kommt mit »su« zu seinen Sonderrechten.

OpenSSH übernimmt nicht nur die Authentifikation, sondern auch die weiteren Schritte beim Anmelden am System (Start der Sitzung mit allen Einträgen in Logfiles, Start der Shell). Mit der Option »UseLogin yes« greift es dafür auf das Login-Programm des Systems zurück. In manchen Umgebungen kann das sinnvoll sein, etwa wenn dieses Binary Restriktionen durchsetzt, von denen »sshd« nichts weiß. Allerdings hat auch diese Option ihre Sicherheitsgeschichte. Bereits zweimal musste das CERT über Lücken berichten[6].

Arbeiten mit den Schlüsselpaaren

Die Public-Key-Authentifizierung hat viele Vorteile gegenüber einem einfachen Login mit Passwort, sie bürdet dem User aber etwas Arbeit beim ersten Einrichten auf. Der Admin muss in der Regel zwar einiges erklären, im Grunde ist es aber nicht schwierig. Um sich mit einem RSA- oder einem DSA-Schlüssel remote einloggen zu können, sind drei Schritte erforderlich:

• Der User muss ein Schlüsselpaar erzeugen (Public und Private Key).
• Er muss seinen Public Key auf dem entfernten Rechner in die Datei »~/.ssh/authorized_keys« kopieren.
• Auf dem lokalen Rechner muss sein privater Schlüssel vorliegen.

Key-Paare erzeugt das Programm »ssh-keygen«. Ohne Option aufgerufen legt es ein SSH1-kompatibles RSA-Schlüsselpaar im Verzeichnis »~/.ssh/« ab. Die beiden Dateien heißen »identity« (Private Key) und »identity.pub« (Public Key). Diese Files gelten für SSH 1, OpenSSH beherrscht aber auch die sicherere Protokollversion 2.

Seit SSH 2 sind auch DSA-Schlüssel möglich. Ein solches Schlüsselpaar generiert das Kommando »ssh-keygen -t dsa«; es erzeugt die Dateien »~/.ssh/id_dsa« (Private Key, Version 2) und »~/.ssh/id_dsa.pub« (Public Key, Version 2). RSA-Schlüssel für SSH 2 entstehen mit »ssh-keygen -t rsa«, die Dateien tragen dann »rsa« in ihrem Namen.

Alle Files mit privaten Schlüsseln dürfen nur für ihre Besitzer les- und schreibbar sein. OpenSSH prüft diese Rechte, wenn es das Key-Verfahren benutzt, und verweigert die Verbindung, wenn die Rechte zu offen sind.

Schlüssel verschlüsseln

Die Zugriffsrechte auf die Schlüsseldateien schützen zwar recht effektiv vor neugierigen Benutzern auf dem System, gegen Root helfen sie jedoch nicht. Falls das Homeverzeichnis auf einem NFS-Server liegt, wird der Schlüssel sogar ungeschützt über das Netz geschickt, vom NFS-Server zum Arbeitsplatzrechner. Damit wäre der ganze Vorteil der Key-Authentifizierung verloren, aber auch dieses Problem lässt sich lösen.

Bereits bei der Erzeugung kann man den Schlüssel mit einer Passphrase schützen. »ssh-keygen« verschlüsselt dann den privaten Key mit der Passphrase. Der Key ist damit vor neugierigen Personen gesichert, nicht mal Root kann ohne die Passphrase die Daten dieses Users entschlüsseln. Die Passphrase lässt sich mit »ssh-keygen -p -f ~/.ssh/id_dsa« auch nachträglich ändern.

Auf dem Zielrechner muss der Public Key in »~/.ssh/authorized_keys« liegen. So kann der Server prüfen, ob der öffentliche Schlüssel wirklich dem User gehört, der sich einloggen will. Bei OpenSSH-Server-Versionen vor 3.0 ist für SSH-2-Schlüssel noch eine Datei gleichen Inhalts nötig, die aber den Namen »~/.ssh/authorized_keys2« trägt.

Der öffentliche Schlüssel muss, wie der Name sagt, nicht geheim gehalten werden. So kann durchaus der Admin des Zielsystems den Schlüssel im Homeverzeichnis ablegen, so lange er wirklich sicher weiß, dass er den richtigen Schlüssel hat. Eine einfache Mail mit dem Schlüssel als Attachment ist da ziemlich riskant. Eine Lösung wäre, die Mail mit GPG zu signieren. Oder der Admin vergleicht den Fingerprint »ssh-keygen -l -f Keyfile« des empfangenen Schlüssels mit dem originalen Fingerprint. Dieser Vergleich kann beispielsweise durch ein kurzes Telefonat erledigt werden.

Abbildung 1: Der Server sendet seinen Public Key an den Client (1), dieser vergleicht ihn mit dem erwarteten Key (2) und authentifiziert den Server (3, 4) über dessen privaten Schlüssel. Danach werden alle Daten verschlüsselt übertragen (5), inklusive der eventuell benutzten Passwörter.

Hinter den Hürden

Nun sollte es möglich sein, sich auf dem Zielsystem einzuloggen:

ssh -v User@Zielrechner

Der Schalter »-v« sorgt dafür, dass OpenSSH eine Reihe von Debug-Meldungen ausgibt. Diese Meldungen sind bei Problemen sehr hilfreich.

Das lokal aufgerufene SSH-Programm fragt anschließend nach der Passphrase des zum Zielaccount passenden privaten Schlüssels. Ist sie korrekt eingegeben, authentifiziert SSH den User am Zielsystem und er findet sich dort in seiner Shell-Umgebung wieder (siehe Abbildung 2). Der Client kann auch die Protokollart (SSH 2 oder SSH 1) vorgeben; die entsprechenden Aufruf-Optionen lauten »-2« und »-1«:

kh@lux:~$ ssh -2 kh@vaio

Lokal wie remote muss ein Login nicht gleich sein. Gerade für Admins ist es ja an der Tagesordnung, lokal normaler User zu sein, aber auf einem entfernten Host als Root zu arbeiten. Für SSH ist das kein Problem:

kh@lux:~$ ssh root@vaio

Der eigene Public Key kann auch in »~/.ssh/authorized_keys« im Homeverzeichnis von Root auf dem Zielsystem liegen; es muss allerdings die Option »PermitRootLogin yes« in »sshd_config« gesetzt sein (Zeile 31 in Listing 1).

Nicht nur User, auch Hosts haben ihr eigenes Schlüsselpaar (siehe Abbildung 1). Damit kann der Client feststellen, ob er wirklich mit dem gewünschten Server verbunden ist. Der entfernte »sshd« sendet dazu seinen Public Key an den Client und authentifiziert sich mit Hilfe seines privaten Schlüssels.

Abbildung 2: Der User »kh« loggt sich per »ssh« von Host »lux« auf »vaio« ein. Dabei sieht er die üblichen Systemmeldungen.

Sicherheitsdatenbank »known_hosts«

Der Client speichert den Host-Key in der Textdatei »~/.ssh/known_hosts«. In den Drafts zu SSH 2 ist festgelegt, dass SSH-Clients bei bislang unbekannten Servern eine Bestätigung des Anwenders einholen müssen, ob er wirklich eine Verbindung dorthin wünscht. Verneint der Anwender das, bricht die Verbindung ab (siehe Abbildung 3).

Der User sollte hier nicht leichtfertig »yes« tippen, diese Abfrage ist schließlich eines der wesentlichen Sicherheits-Features von SSH. Der angezeigte Fingerprint ist bestens geeignet, um den Key durch ein Telefonat mit dem Admin des Ziel-Hosts zu verifizieren: Der Admin kann sich den Fingerprint des originalen Host-Keys mit »ssh-keygen -l -f Keyfile« ansehen. Nur wenn beide Zeichenfolgen übereinstimmen, sollte der User den Key in seine »known_hosts«-Datei aufnehmen (Abbildung 4).

Das Prüfen des Server-Host-Keys schützt vor Man-in-the-Middle-Attacken. Dabei gibt sich ein Angreifer beispielsweise durch Manipulation des DNS, von ARP oder durch die Übernahme der IP des echten Servers für diesen aus. Der Angreifer verbindet sich seinerseits mit dem echten Server und leitet die Daten weiter, so dass der Benutzer keinen Unterschied bemerkt. Vor diesem Angriff kann die Kryptographie ihre Anwender schützen – aber nur, wenn diese auch mitspielen. Wenn der Client nichts über den Server weiß, kann der dessen Authentizität auch nicht verifizieren.

Wenn der SSH-Client den Public Key des echten Servers bereits kennt, der Schlüssel also in der »known_hosts«-Datei steht, kann der Client den Angriff automatisch erkennen. Der Angreifer kennt den originalen Secret Key nicht und kann daher auch nicht den Public Key des gewünschten Ziels verwenden, vielmehr muss er seinen eigenen öffentlichen Schlüssel senden. Beim Vergleich mit seiner Schlüsselliste stellt der Client die Abweichung fest, warnt den User ausdrücklich (Abbildung 5) und bricht die Verbindung ab.

Die Warnmeldung kann aber auch einen harmlosen Anlass haben, wenn sich der Server-Key tatsächlich geändert hat. Das passiert, wenn der Admin den Key neu generiert, weil beispielsweise die alte Festplatte defekt und kein Backup vorhanden ist, der Rechner ausgetauscht wurde oder einfach nur jemand SSH neu installiert hat, ohne den alten Schlüssel zu übernehmen. Die Warnung des Clients bleibt so lange bestehen, bis der User den alten Server-Key aus »known _hosts« löscht. Bei der nächsten Kontaktaufnahme wird der Dialog zur Bestätigung des Servers dann erneut durchlaufen (Abbildung 4).

Abbildung 3: Beim Login auf einen unbekannten Host fragt SSH nach, ob der User dem Server-Key vertraut. »kh« verneint dies hier, die Verbindung bricht ab.

Abbildung 4: Wenn der User sicher ist, dass der Host-Key wirklich zu dem gewünschten Zielrechner gehört, kann er den Schlüssel in die Liste der bekannten Hosts aufnehmen.

Abbildung 5: Wenn der SSH-Client feststellt, dass sich der Public Key des Servers geändert hat, muss er von einem Man-in-the-Middle-Angriff ausgehen. SSH warnt den Benutzer dann sehr deutlich.

Schlüsselverwaltung

Wenn ein Admin seinen Usern innerhalb des eigenen Netzes diese Prozedur ersparen will, dann sollte er die globale »/etc/ssh/ssh_known_hosts«-Datei pflegen. Wenn sich ein Host-Key ändert, kann er auch die Liste der öffentlichen Schlüssel anpassen.

Mit der beschriebenen Key-Authentifizierung sind die Verbindungen zwar sicherer geworden, aber statt eines Passworts muss man nun eine Passphrase eingeben. Mit dieser Unbequemlichkeit machen die beiden Programme »ssh-agent« und »ssh-add« Schluss. Der SSH-Agent ist eine Art Cache-Agent zum Abruf von entschlüsselten Private Keys. Er läuft als Daemon und stellt seine Dienste nur jenem User zur Verfügung, der ihn gestartet hat. Zur Kommunikation nutzt er Unix Domain Sockets; welches Socket er verwendet, teilt er seinen Kindprozessen über die Umgebungsvariablen »SSH_AUTH_SOCK« und »SSH _AGENT_PID« mit.

Die X11-Startskripte vieler Distributionen starten den SSH-Agenten als Vaterprozess der X11-Sitzung, so dass er in jedem X11-Terminal zur Verfügung steht. Verifizieren lässt sich das mit folgendem Kommando:

kh@lux:~$ set | grep SSH
SSH_AGENT_PID=2097
SSH_AUTH_SOCK=/tmp/ssh-XX70h6xH/agent.2062

Läuft noch kein SSH-Agent und will man ihn nur in einer einzelnen Shell nutzen, erledigt das folgender Aufruf:

kh@lux:~$ ssh-agent $SHELL

Der SSH-Agent startet die Subshell »$SHELL« mit den passenden Umgebungsvariablen und versetzt sich danach selbst in den Hintergrund. Nun kann das Kommando »ssh-add« beliebige private Schlüssel entschlüsselt im Cache speichern:

kh@lux:~$ ssh-add ~/.ssh/id_dsa
Enter passphrase for /home/kh/.ssh/id_dsa:
Identity added: /home/kh/.ssh/id_dsa 
(/home/kh/.ssh/id_dsa)
kh@lux:~$

Damit stehen diese Keys dem SSH-Client zur Verfügung, ohne dass er nochmals nach der Passphrase fragen muss. Welche Keys im SSH-Agent gecacht sind, zeigt folgender Aufruf:

kh@lux:~$ ssh-add -l
1024 87:db:4c:0a:6a:c5:56:6b:74:6f:1c:8e:
65:0a:ce:b2 /home/kh/.ssh/id_dsa (DSA)
kh@lux:~$

Komplett löschen kann man den Key- Cache mit »ssh-add -D«, einzelne Schlüssel entfernt »sh-add -d ~/.ssh/id_dsa«.

Agenten weiterleiten

Loggt man sich hintereinander auf mehreren Hosts ein, kann die »ForwardAgent«-Option behilflich sein. Damit muss nicht auf jeder Zwischenstation eine Kombination aus privatem und öffentlichem Schlüssel liegen und ein weiterer Agenten-Prozess gestartet werden. Ein einzelner SSH-Agent auf dem vertrauenswürdigen Rechner genügt; alle Hosts, zu denen man sich weiterverbindet, benutzen rückwärts den »ssh-agent« am Anfang der Kette.

Das Agent Forwarding lässt sich auf drei Arten aktivieren: systemweit als Eintrag »ForwardAgent yes« in der Datei »/etc /ssh/ssh_config«, für einzelne User im File »~/.ssh/config« oder durch die Option »-A« des »ssh«-Kommandos.

Das Verfahren hat aber auch seine Schattenseiten. Prinzipiell kann Root durch einen Speicherdump die entschlüsselten Private Keys lesen – wer dem Root-Account nicht vertraut, sollte auf der jeweiligen Maschine aber generell keine Geheimnisse speichern. Selbst wenn man auf den SSH-Agent verzichtet, kann Root durch einen trojanisierten SSH-Client oder mit Hilfe eines TTY-Sniffers an die geheimen Daten kommen, sobald der User die Passphrase eintippt.

Files mit »scp« und »sftp« sicher übertragen

SSH kann noch mehr als nur Remote-Logins. Ein Beispiel dafür ist das Kopieren von Dateien über die verschlüsselte Verbindung. Die zur OpenSSH-Suite gehörenden Programme »scp« und »sftp« bieten sich hierfür an. »scp« folgt der Syntax von »rcp«.

Eine lokale Datei kopiert das Kommando »scp LokaleDatei user@host.remote:ZielDatei« auf den Zielhost. Den umgekehrten Weg, eine entfernte Datei zum lokalen Host zu kopieren, erreicht das Kommando »scp user@host.remote:RemoteDatei LokalesZiel«. Wie beim interaktiven »ssh« kennt das Kommando noch weitere Optionen, etwa Protokollversion, Verbosity-Level, Usernamen oder Komprimierung.

Das Programm »sftp« erfüllt denselben Zweck wie »scp«, ist aber ähnlich zu benutzen wie das Kommandozeilenprogramm »ftp«. Es setzt nur voraus, dass in »sshd_config« das Server-Subsystem »sftp-server« aktiviert ist (letzte Zeile in Listing 1). Das interaktive Arbeiten mit »sftp« sollte vielen Benutzern vertraut erscheinen:

lux:/tmp$ sftp root@vaio
Connecting to vaio...
sftp> pwd
Remote working directory: /root
sftp>

Mit Gftp[8] gibt es sogar ein komfortables GUI für FTP und SFTP.

Backup über SSH

Besonders erfreulich für Administratoren ist die Möglichkeit, Backups über SSH durch das Netz zu schicken. Dafür ist gar kein »scp« oder »sftp« nötig, SSH lässt sich direkt in der Shell-Pipe nutzen:

tar czvf - /das/Verzeichnis | 
ssh user@host cat /tmp/foo.tar.gz

Die Empfängerseite kann auch direkt auf ein Bandlaufwerk schreiben:

tar cvf - /das/Verzeichnis | 
ssh user@host dd of=/dev/tape

Dabei kann die Performance des Bandlaufwerks allerdings ziemlich in den Keller gehen. Der Grund dafür ist, dass »dd« und Bandlaufwerk wechselseitig auf Daten warten müssen. Reißt der Strom neuer Daten ab, muss das Laufwerk absetzen, etwas zurückspulen und kann dann erst weiter schreiben. Ein kleines Tool hilft hier:

tar cvf - /das/Verzeichnis | 
buffer | ssh -c blowfish root@vaio 
buffer -o /dev/tape

Buffer[9] teilt sich in zwei Prozesse, die das Lesen der Daten vom Netz und das Schreiben auf Band entkoppeln und durch einen Zwischenpuffer ergänzen. In diesem Beispiel schaltet zudem die OpenSSH-Option »-c blowfish« auf den sehr schnellen und trotzdem als sicher geltenden Verschlüsselungsalgorithmus Blowfish um. Damit erfüllt OpenSSH die oft gegensätzlichen Forderungen nach Sicherheit und Schnelligkeit. (fjl)

ps ax | grep sshd

netstat -tpan