Es gab einmal eine Zeit, als Computer im Netz über das Telnet-Protokoll zugänglich waren. Da dieses Protokoll keine Verschlüsselung bot, wurde das Mitschneiden von Passwörtern zur trivialen Angelegenheit.
Um den Fernzugang zu sichern, schrieb Tatu Ylönen Mitte der 1990er eine Programmsuite – bestehend aus Server, Client und Hilfsprogrammen – die er ssh (secure shell) nannte.
Später gründete er die Firma ssh.com und bot die Version 2 der SSH-Suite nur noch kommerziell an. Daraufhin wurde von Entwicklern des Betriebssystems OpenBSD der öffentliche Quellcode der Version 1 geforkt. Sie entwickelten das Programm unter dem Namen "OpenSSH" weiter. Diese OpenSSH-Suite wurde fester Bestandteil quasi aller Linux-Distributionen.
Drei wichtige Eigenschaften führten zum Erfolg von ssh :* Authentifizierung der Gegenstelle, kein Ansprechen falscher Ziele
- Verschlüsselung der Datenübertragung, kein Mithören durch Unbefugte
- Datenintegrität, keine Manipulation der übertragenen Daten
Mehr Details zur verwendeten Verschlüsselung finden sich weiter unten. Falls man sich auf den eigenen Computer hinter einem DSL-Router per SSH einloggen will, muss man zuvor in diesem eine Portweiterleitung einrichten, sonst kommt keine Verbindung zustande.

Der SSH-Client

Das funktioniert normalerweise in einen Terminal-Fenster [2] so:

ssh user@sol-1 
user@sol-1's password:
Last login: Sun Feb 12 07:38:50 2006 from client.local
Sun Microsystems Inc.   SunOS 5.9       Generic_112234-03       November 2002
bash-2.05$

Und schon befindet man sich auf einem anderen System, in diesem Fall mit dem Betriebssystem Solaris.

ssh server 
Password:
Linux vdr 2.4.27-ctvdr-1 #1 Fri Oct 15 18:38:29 UTC 2004 i686 GNU/Linux
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
You have new mail.
Last login: Sun Feb 12 07:38:23 2006 from client.local
user@server:~$

Oder auf einem anderen Linux-System. Wie man sieht, ist die Angabe des Benutzernamens optional, wenn er auf beiden Systemen gleich ist. Man kann auch einfach einen Befehl anhängen, der anstelle der Terminal-Session ausgeführt wird. Nach der Ausführung des Befehls wird die SSH-Session dann automatisch beendet:

ssh server cat /etc/issue 
Password:
Debian GNU/Linux 3.1 \n \l

Oder etwas komplizierter - eine Datensicherung machen ("backup"):

user@client:~$ ssh root@server 'cd /etc; tar czvf - network/' | cat > etc_network_backup.tar.gz 
Password:
network/
network/interfaces
network/if-post-down.d/
network/if-pre-up.d/
network/if-up.d/
network/if-down.d/
network/options
network/interfaces.pre-etherconf
network/interfaces.1
network/run

Bei einer langsamen Verbindung empfiehlt sich zusätzlich die Benutzung der Option -C (großes C), die zusätzlich zur Verschlüsselung eine transparente Kompression der übertragenen Daten aktiviert. Bei einer schnellen Verbindung wird die Kompression aber vermutlich bremsen.

Woher weiß man nun aber, dass man tatsächlich mit dem richtigen Rechner verbunden ist, und nicht ein Angreifer die Verbindung umgeleitet hat? Dafür gibt es den Host-Schlüssel, der jeden SSH-Server eindeutig identifiziert. Greift man zum ersten Mal auf einen bestimmten Server zu, kennt man diesen Schlüssel natürlich noch nicht. (Außer man hat ihn sich auf anderen Wegen im Voraus besorgt.)

ssh server 
The authenticity of host 'server (192.168.1.5)' can't be established.
ECDSA key fingerprint is b5:0e:ec:b7:16:06:e6:24:a6:39:18:58:4e:ec:3b:d1.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'server' (ECDSA) to the list of known hosts.
Password:

Wenn gerade in diesem Moment jemand die Verbindung gekapert hat, hat man natürlich Pech, außer man kann den Administrator des Servers nach dem richtigen Fingerprint des Host-Schlüssels fragen.
Den ECDSA-Fingerprint eines Servers kann man mit dem Systemprogramm ssh-keygen erfahren:

ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -l

gibt den Fingerprint und einige weitere Informationen aus, z.B. 256 b5:0e:ec:b7:16:06:e6:24:a6:39:18:58:4e:ec:3b:d1 root@server (ECDSA). Wenn man auf Nummer sicher gehen möchte, lässt man sich vom Administrator des Servers diese Ausgabe mitgeben (evtl. ausdrucken) und kann dann beim ersten Verbindungsversuch überprüfen, ob man sich tatsächlich zum richtigen SSH-Server verbunden hat und nicht zu einem dazwischengeschalteten Angreifer.

Bei allen weiteren Kontakten stellt das ssh-Programm jedoch von nun an über asymmetrische Kryptografie sicher, dass der Server auch über den richtigen öffentlichen Schlüssel verfügt, der zum öffentlichen, in der Datei ~/.ssh/known_hosts abgelegten passt, und verweigert im Zweifelsfall den Verbindungsaufbau.

Sollte sich dieser Schlüssel einmal aus legitimen Gründen geändert haben, bspw. weil das System neu aufgesetzt wurde, muss man den entsprechenden veralteten Schlüssel erst einmal auf dem Client mit dem Befehl

ssh-keygen -R hostname

aus der known_hosts-Datei entfernen.

Sollte die Verbindung nicht mehr reagieren, z.B. wenn der SSH-Server heruntergefahren wurde, lässt sich der ssh-Client mit der Eingabe von "~." (nacheinander) beenden.

Hinweis

Wer (noch) einen Windows-Desktop benutzt und über das SSH-Protokoll auf eine Linux-Maschine zugreifen will, kann das Programm PuTTY nutzen.

Benutzeroberflächen

Wem es zu mühsam ist, auf der Kommandozeile die SSH-Verbindung zu einem Server aufzubauen, der sucht vielleicht ein grafisches Programm, um Verbindungsdaten zu verwalten.* PuTTY - gibt es sowohl für Linux als auch für Windows. Das Programm ist in den offiziellen Paketquellen enthalten.

PAC Manager - (Perl Auto Connector) nicht in den offiziellen Paketquellen enthalten, aber über SourceForge wird ein Fremdpaket angeboten, das manuell installiert werden kann.
Gnome-RDP - mit diesem Programm kann man nicht nur RDP- und VNC-Verbindungen aufbauen, sondern auch SSH-Terminalsitzungen. Leider kann man in der aktuellen Version die Zugangspasswörter nicht speichern lassen und keine Angaben zum verwendeten Port machen. Es funktioniert somit nur mit Servern, die den Standard-SSH-Port 22 nutzen. In den offiziellen Paketquellen enthalten, benötigt aber Mono als Voraussetzung.

.ssh/config

Wenn man sich auf der Konsole mit einem anderen Server verbinden möchte, muss man evtl. z.B. Port und Benutzernamen angeben. Um das Ganze zu vereinfachen, kann man Voreinstellungen für ssh in der config-Datei $HOME/.ssh/config hinterlegen. Hier ein Beispiel:

vergrößern

# ssh (secure shell) configuration file Host test1

   HostName 123.456.789.0
   Port 980
   User MeinBenutzerName

Host test2

   HostName test.mynet.local
   User test
   CheckHostIP no
   Cipher blowfish

Host foobar

   HostName domain.tld
   Port 55550
   User fanta
   IdentityFile ~/.ssh/private_ssh_key_rsa

Nun braucht man nicht mehr

ssh MeinBenutzerName@123.456.789.0 -p980

zu schreiben, es reicht nun ein kurzes

ssh test1

für einen Verbindungsaufbau. Alle Parameter, die man verwenden kann, findet man unter openbsd.org oder in der Manpages von ssh_config.

Der SSH-Server

Im Gegensatz zum SSH-Klienten ist der SSH-Server unter Ubuntu standardmäßig nicht installiert. Er lässt sich über das Paket

openssh-server

mit apturl

Paketliste zum Kopieren: apt-get aptitude

sudo apt-get install openssh-server

installieren [1].

Die Konfiguration des SSH-Servers sshd findet über die Datei /etc/ssh/sshd_config statt. Die Voreinstellungen sind aber durchweg akzeptabel.

Wer den sshd auf einem Gateway oder Router betreibt oder aus einem anderen Grund mehrere Netzwerkschnittstellen verwendet (bspw. WLAN), der möchte dort vielleicht die ListenAddress-Direktive benutzen, um den Server nur an bestimmten Netzwerk-Schnittstellen laufen zu lassen.

Außerdem kann es sinnvoll sein, PermitRootLogin auf no zu setzen. Dann kann sich niemand direkt als root einloggen, sondern man meldet sich unter seinem Benutzernamen an und ruft dann su oder sudo -s auf. Dies ist aber unter Ubuntu nur relevant, sollte man dem "root"-Benutzerkonto ein Passwort zugewiesen haben.

Mit den Direktiven AllowUsers und AllowGroups bzw. DenyUsers und DenyGroups lässt sich noch genauer festlegen, welche Benutzer sich anmelden dürfen und welche nicht. Dies empfiehlt sich besonders bei Servern. AllowGroups admin verbietet bspw. allen Benutzern, die keine Mitglieder der Gruppe admin sind, den Zugriff.

Wer sich ausschließlich über das noch sicherere Public-Key-Verfahren anmelden will, der sollte die Benutzung von Passwörtern mit PasswordAuthentication no abschalten.

Falls lange Wartezeiten bei der Anmeldung am SSH-Server auftreten, könnte das an einer fehlgeschlagenen Namensauflösung liegen. Da man SSH normalerweise sowieso über die IP benutzt, können diese DNS-Anfragen in der sshd_config deaktiviert werden. Der dafür nötige Eintrag wäre UseDNS no.

Nach erfolgter Änderung der Datei sshd_config muss der Server mit dem Befehl:

sudo reload ssh

neugestartet werden, damit die Änderungen wirksam werden.

Hinweis

Standardmäßig wird der SSH-Server beim Booten geladen. Ab Ubuntu 10.04 ist Upstart für den Autostart des SSH-Servers zuständig. Wie man den Autostart deaktiviert, wird im Upstart-Artikel beschrieben.

Dateitransfer

Wenn man also ein Protokoll hat, das so sicher wie nach dem heutigen Stand der Technik möglich Daten durch einen verschlüsselten Kanal senden und empfangen kann, dann wäre es wohl Verschwendung, dieses Protokoll nur für interaktive Terminal-Sessions zu benutzen. Sehr häufig möchte man bspw. einfach nur Dateien sicher von einem System zum anderen bewegen. Dafür existieren verschiedene Programme der grafischen Benutzeroberfläche sowie gleich zwei Terminalbefehle nämlich scp und sftp.

Transfer von der Kommandozeile

scp

Das Kommandozeilenwerkzeug scp funktioniert in etwa so wie das normale Unix-Kommando cp, nur dass es über Systemgrenzen hinweg funktioniert. Jedes Datei- oder Verzeichnisargument kann dabei optional, getrennt durch einen Doppelpunkt, durch einen vorangestellten Benutzer- bzw. Hostnamen ergänzt werden. Dabei werden weggelassene Teile durch den aktuellen Benutzernamen, localhost bzw. das Homeverzeichnis (bzw. das aktuelle Verzeichnis) ergänzt, etwa so:

scp benutzerx@server1:datei1 datei2 benutzery@server2:

In diesem Beispiel wurde die datei1 aus dem Homeverzeichnis von benutzerx auf server1 und die datei2 aus dem aktuellen Verzeichnis des lokalen Hosts in das Homeverzeichnis von benutzery auf server2 kopiert.

Der Befehl scp versteht auch einige von cp bekannte Optionen, bspw. -r für das rekursive Kopieren ganzer Verzeichnisbäume. Bedauerlicherweise unterstützt scp aber nicht alle cp-Optionen, die für das exakte Klonen von Verzeichnissen, inkl. aller Dateirechte und symbolischen Verknüpfungen notwendig sind. Für die exakte Replikation sollte deswegen entweder das Werkzeug rsync -e ssh genutzt werden (man beachte die Handbuchseite zu diesem Tool) oder der oben schon genutzte Trick mit tar und einer Pipe.

ssh root@server 'cd verzeichnis; tar czvf - verz./dateien' | tar xzf -

sftp

Die andere Möglichkeit des Dateitransfers lautet sftp. Das funktioniert genau so wie der normale Kommandozeilen-FTP-Client:

sftp server

vergrößern

Connecting to server... user@server's password: sftp> pwd Remote working directory: /export/home/user sftp> dir [...] wichtige_datei.txt [...] sftp> get wichtige_datei.txt Fetching /export/home/user/wichtige_datei.txt to wichtige_datei.txt /export/home/user/wichtige_datei.txt 100% 62KB 62.2KB/s 00:00 sftp> quit

Mit dem Befehl help bekommt man eine Übersicht über die möglichen Kommandos.

Entfernte Dateisysteme einbinden

Man kann das Dateisystem eines entfernten Rechners in sein eigenes Dateisystem mittels sshfs einbinden. Damit ist eine transparente Nutzung von Dateien auch über unsichere Netze hinweg möglich.

Grafische Programme zum Dateitransfer

Gnome/Ubuntu

Der Gnome-Dateimanager Nautilus unterstützt das SSH-Protokoll von Haus aus. Dazu benutzt man eine Adresse der Form ssh://rechnername/pfad, um über SSH die Dateien auf dem angegebenen Rechner zu sehen. Wenn man sich als ein anderer Benutzer anmelden möchte, verwendet man stattdessen eine Adresse der Form ssh://andererbenutzer@rechnername/pfad. Alternativ können auch die Hosts aus der ~/.ssh/config verwendet werden. Dort lassen sich auch noch andere SSH-Einstellung, wie. z.B SSH-Keys, definieren. Der Zugriff erfolgt mit ssh://hostname. Diese Adressen funktionieren übrigens auch in einigen anderen Gnome-Anwendungen.

KDE/Kubuntu

Auch bei KDE ist SSH-Unterstützung eingebaut: Mit einer Adresse der Form fish://rechnername/pfad kann man auf die Dateien auf einem anderen Rechner zugreifen, und mit fish://andererbenutzer@rechnername/pfad meldet man sich als anderer Benutzer auf dem Zielrechner an. Dies funktioniert im Konqueror sowie in allen KDE-Anwendungen.

Man kann also beispielsweise im Malprogramm KolourPaint via Datei -> Öffnen.. und dann oben in der Adresszeile eine fish://-Adresse eingeben, um direkt ein Bild auf einem anderen Rechner anzusehen oder zu bearbeiten. Im Dateimanager Dolphin (Kubuntu-Standard) können über das Bookmark "Netzwerk" und den Assistenten "Netzwerkordner hinzufügen" neue ssh-basierte Netzwerkordner als feste Bookmarks erstellt werden.

Wenn der Zielrechner ebenfalls ein UTF-8 codiertes Dateisystem hat, sind u.U. die Umlaute falsch angezeigt. Um dies zu ändern, muss man im Konqueror eine fish-Adresse aufrufen und kann nun unter "Extras -> Entfernte Zeichencodierung wählen..." die entsprechende Codierung einstellen. Diese Einstellung ist fortan auch in Dolphin gültig. Diese Option einzustellen wird in KDE4 vermutlich in Dolphin selbst möglich sein.

Xfce/Xubuntu

Der Xfce-Dateimanager Thunar unterstützt das SSH-Protokoll wie Nautilus unter GNOME. Siehe Gnome-Ubuntu.

Weitere grafische Programme

Die meisten grafischen FTP-Clients (FTP) unterstützen auch sftp oder scp über das SSH-Protokoll. Beim Gnome FTP-Cient gFTP etwa muss man unter "FTP -> Optionen -> Netz -> Voreingestelltes Protokoll" in der Drop-Down-Liste SSH2 an Stelle von FTP auswählen. Leider hat gftp Probleme, wenn man neben Passwörtern auch Public-Keys (siehe Public-Key-Verfahren) benutzt. Das funktioniert nur mit dem SSH-Agenten (ebenfalls weiter unten beschrieben) und der Einstellung "Benötige SSH Benutzername/Passwort nicht" in "FTP -> Optionen -> SSH".

SSH-Verbindungen zu Datenverzeichnissen auf Fremdrechnern unterstützen auch Datensynchronisationsprogramme wie Unison und Backupprogramme wie Keep.

Authentifizierung über Public-Keys

Wem die Authentifizierung über Passwörter trotz der Verschlüsselung zu unsicher ist, - immerhin könnte das Passwort ja erraten werden - der benutzt am besten das Public-Key-Verfahren. Hierbei wird asymmetrische Verschlüsselung genutzt, um den Benutzer zu authentifizieren. Der (oder die) öffentliche(n) Schlüssel des Benutzers befindet sich dabei in der Datei ~/.ssh/authorized_keys des Zielsystems, der private Schlüssel in einer Datei (meist id_rsa) im Verzeichnis ~/.ssh auf dem lokalen System, wo er zusätzlich von einer "pass phrase" geschützt wird. Wenn man sich nun mit der Public-Key-Methode auf einem SSH-Server anmelden möchte, so schickt der Server dem Klienten eine zufällig generierte Challenge. Der Klient verschlüsselt diesen Datenblock mit seinem privaten Schlüssel, (wofür nötigenfalls die Passphrase abgefragt wird,) und wenn der Server diesen Chiffre mit dem zugehörigen öffentlichen Schlüssel wieder entschlüsseln kann, ist die Identität des Benutzers bestätigt.

Damit man dieses Verfahren überhaupt verwenden kann, muss man sich zunächst mit Hilfe des Kommandozeilenprogramms ssh-keygen ein entsprechendes Schlüsselpaar erzeugen:

ssh-keygen -t rsa -b 4096

vergrößern

Generating public/private rsa key pair. Enter file in which to save the key (/home/user/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/id_rsa. Your public key has been saved in /home/user/.ssh/id_rsa.pub. The key fingerprint is: 24:55:ee:67:83:72:82:55:5f:b9:b4:09:2a:fa:56:a1 user@client.local The key's randomart image is: +--[ RSA 4096]----+ | | | | | | | + . | | S E | | . + + | | .o . o.| | o.oo. oo| | ==o.BO+| +-----------------+

Der voreingestellte Dateiname (id_rsa) kann einfach mit der Taste ⏎ bestätigt werden, außer man möchte sich ein weiteres Schlüsselpaar erzeugen. Von der Benutzung einer leeren Passphrase ist jedoch abzuraten, weil sonst jeder, der evtl. in den Besitz dieser Datei kommt, sofortigen Zugriff auf alle zugehörigen Systeme erhält.

Nun muss noch der öffentliche Schlüssel, zu erkennen an der Endung .pub (id_rsa.pub), auf dem Zielsystem deponiert werden. Dazu dient das Programm ssh-copy-id. Zu diesem Zeitpunkt muss die Authentifizierung per Passwort noch erlaubt sein (PasswordAuthentication yes):

ssh-copy-id -i ~/.ssh/id_rsa.pub user@server Password: Now try logging into the machine, with "ssh 'user@server'", and check in:

 .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

Hinweis

Sollte man - warum auch immer - bei der Angabe des Dateinamens des Schlüssels die Endung .pub vergessen, so wird diese automatisch durch ssh-copy-id angehängt. Man kann also nie aus Versehen seinen privaten Schlüssel Namens id_rsa (also ohne Endung .pub) übertragen.

Sollte ssh-copy-id nicht funktionieren, kann man den öffentlichen Schlüssel auch anders auf das Zielsystem kopieren und in die Datei ~/.ssh/authorized_keys einfügen. Dabei ist unbedingt darauf zu achten, dass die Datei mit der Endung .pub und nicht der private Schlüssel ohne diese Endung verwendet wird:

cat id_rsa.pub | ssh server 'cat>> ~/.ssh/authorized_keys'

Wenn ein vom Standard abweichender Dateiname für den Key gewählt wurde, muss er mittels der Kommandozeilenoption -i ~/pfad/dateiname gesondert angegeben werden. Für die dauerhafte Nutzung empfiehlt sich ein Eintrag in der ~/.ssh/config mittels IdentityFile-Parameter.

Hinweis

Bei Ubuntu 12.04 sollten die Rechte der Datei ~/.ssh/authorized_keys sowie des Ordners ~/.ssh auf dem Server noch restriktiver gesetzt werden, falls diese neu erzeugt wurden und daher nur mit Standardrechten ausgestattet sind:

chmod 700 /home/BENUTZERNAME/.ssh chmod 600 /home/BENUTZERNAME/.ssh/authorized_keys

Anschließend kann man sich ohne Passwort anmelden:

ssh user@server Enter passphrase for key '/home/user/.ssh/id_rsa': Linux server.local 2.6.12-10-686 #1 Mon Feb 13 12:18:37 UTC 2006 i686 GNU/Linux The programs included with the Ubuntu system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Fri Mar 3 03:51:14 2006

In einigen Fällen tritt ein Fehler beim ersten Anmeldeversuch auf:

"Agent admitted failure to sign using the key."

In diesem Fall einfach ssh-add ausführen.

ssh-add Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)

Hinweis

Falls es noch nicht klappt kann es daran liegen, dass die Rechte beim Server nicht korrekt sind. sshd achtet darauf, dass das Homeverzeichnis, das dem Login-Namen entspricht (also die "Mappe" selbst), das .ssh-Verzeichnis und authorized_keys nur für den Eigentümer Schreibrechte hat. Hintergrund ist wohl, die Gefahr zu verringern, dass authorized_keys manipuliert wird und man keinen Zugriff mehr hat, wenn der Passwortzugang (s.u.) gesperrt ist.

Wer also bei bestimmten Konten auf dem Server auch einer Gruppe Schreibrechte gewähren will, muss evtl. die Optionen in /etc/ssh/sshd_config prüfen.

Jetzt ist es aber immer noch möglich, sich mit dem Passwort anzumelden. Um dies zu unterbinden, sind in der Datei /etc/ssh/sshd_config die Optionen

PasswordAuthentication no UsePAM no

zu setzen und mit einem

sudo /etc/init.d/ssh reload

die Konfiguration neu einlesen lassen.

Alternativ: Auf der Serverseite eingeben passwd -l <user>. Damit sind Passwörter nur für ausgewählte Accounts sperrbar.

Verschlüsseltes Home-Verzeichnis

Man sollte darauf achten, dass bei verschlüsselten Home-Verzeichnissen (ecryptfs) auch die authorized_keys mit verschlüsselt ist und somit nicht zur Authentifizierung verwendet werden kann, solange das Home-Verzeichnis nicht entschlüsselt ist (durch parallele Anmeldung mit dem gleichen Benutzernamen).

Eine Abhilfe ist z.B. die authorized_keys in ein nicht-verschlüsseltes Verzeichnis zu legen (z.B. /etc/ssh/username/) und die Einstellung AuthorizedKeysFile in der /etc/ssh/sshd_config auf /etc/ssh/%u/authorized_keys zu ändern (Root-Rechte und Neustart des SSH-Daemons erforderlich).

sudo mkdir /etc/ssh/$USER sudo mv $HOME/.ssh/authorized_keys /etc/ssh/$USER/ ln -s /etc/ssh/$USER/authorized_keys $HOME/.ssh/

Quelle: SSH with authorized_keys to an Ubuntu system with encrypted homedir?

Der SSH-Agent

Unter grafischen Desktop-Sitzungen (Unity, Gnome, etc.) startet automatisch im Hintergrund der SSH-Agent. In diesem werden automatisch die privaten Schlüssel abgelegt, sodass nicht jedes Mal die "pass phrase" abgefragt wird. Dies verbindet die Bequemlichkeit der Bedienung mit der Sicherheit des Public-Key-Verfahrens.

Zur direkten Interaktion mit dem SSH-Agenten im Terminal dient das Programm ssh-add, wobei die Option -l die augenblicklich gespeicherten Schlüssel auflistet:

ssh-add -l {{{ The agent has no identities. ssh-add Enter passphrase for /home/user/.ssh/id_rsa: Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa) ssh-add -l 1024 24:55:ee:67:83:72:82:55:5f:b9:b4:09:2a:fa:56:a1 /home/user/.ssh/id_rsa (RSA) ssh server Last login: Wed Mar 8 11:11:58 2006 from 192.168.4.56

Wenn man nicht über Unity oder eine andere graphische Benutzeroberfläche, die unter dem ssh-agent läuft, eingeloggt ist, funktioniert das so leider nicht. Dann muss man vorher noch ein

exec ssh-agent bash

ausführen, um eine Shell zu öffnen, die mit dem ssh-agent kommunizieren kann.

Arbeitet man oft im Terminal und möchte nicht immer wieder die "pass phrase" eingeben, kann man das folgende in seine .bashrc eintragen:

if [ $SSH_AGENT_PID ]; then

   if [[ $(ssh-add -l) != *id_?sa* ]]; then
       ssh-add -t 2h  ## Haltbarkeit von 2 Std.
   fi

fi

Login über mehrere Rechner

Ab und zu muss man sich von Rechner zu Rechner hangeln, da kein direkter Zugriff besteht. Doch der Key wird nicht automatisch übertragen. Darum besteht die Möglichkeit dies direkt in der ~/.ssh/config zu vermerken.

ForwardAgent yes

SSH-Askpass

Wenn eines der Pakete ssh-askpass, ssh-askpass-gnome, ssh-askpass-fullscreen oder gtk-led-askpass installiert ist, kann ssh-add die Passphrase in Ermangelung eines Terminals auch über ein Dialogfenster abfragen. Das nutzt man sinnvollerweise, um seinen Schlüssel gleich nach der Anmeldung auf einem grafischen System zu laden [5]. Für KDE-Nutzer gibt es das Paket ksshaskpass, das für ssh-add eine graphische Oberfläche zur Verfügung stellt.

Single-Sign-On

Wem immer noch zu umständlich ist, beim Login nacheinander erst das Login-Passwort und dann die SSH-Passphrase einzugeben, der installiert sich stattdessen das Paket libpam-ssh.

Mit den richtigen Einstellungen wird man beim Login nach der Eingabe des Benutzernamens nicht mehr nach dem Passwort, sondern nach der SSH-Passphrase gefragt und kann sich danach ohne nervige Passwortabfrage mittels SSH auf seinen Systemen bewegen.

Nur wenn man die Passphrase nicht richtig eintippt, kann man sich stattdessen auch mit seinem normalen Passwort authentifizieren. Zu beachten ist allerdings, dass der GNOME-Schlüsselbund dann nicht mehr automatisch freigeschaltet wird.

Macht man hier einen Fehler, kann man sich eventuell nicht mehr am System anmelden. Sollte das passiert sein, ist es normalerweise noch möglich, sich per SSH einzuloggen und den Fehler zu beheben. Wenn auch das nicht mehr hilft, muss man das System zum Reparieren im Single-User-Runlevel oder von einer Live-CD starten.

X-Forwarding

Mit dem X11-Forwarding kann man auch grafische Programme, die man über SSH auf einem anderen Rechner startet, auf dem eigenen Display anzeigen lassen, und zwar unabhängig davon, welches Betriebssystem auf dem entfernten Rechner läuft (siehe Bild.)

Das Programm muss sich nur an den X11-Standard halten, was leider die meisten Windows- und Mac-Programme ausschließt.

Um das X11-Forwarding zu aktivieren, muss man dem ssh-Befehl die Option -X (großes X) hinzufügen, die dem Programm eingeschränkte Rechte am eigenen Display einräumt.

Für den Fall, dass es zu einem Programmabbruch kommt, weil diese eingeschränkten Rechte nicht ausreichen, existiert noch die Option -Y, die dem Programm volle Rechte gewährt.

Diese sollte man jedoch nicht verwenden, wenn man dem Administrator des entfernten Rechners nicht vertraut, denn sie öffnet einen Tunnel, der auch in der umgekehrten Richtung für einen Angriff auf das eigene Display genutzt werden könnte.

Vorsicht: mit der Option -x (kleines x) wird X11-Forwarding deaktiviert.

Hinweis: bei Nutzung von VNC (z.B. für Fernwartung) muss auf dem Server X11VNC installiert sein.

Einen deutlichen Geschwindigkeitszuwachs erreicht man durch die Wahl einer anderen Verschlüsselung und der Aktivierung der Kompression der Daten für langsame Verbindungen (DSL, etc.) mit diesen zusätzlichen Optionen im Aufruf von ssh: -c arcfour,blowfish-cbc -XC. Beispiele:

Öffnen des Programms Leafpad: ssh -X user@server leafpad & Zur bequemeren Nutzung entfernter Programme können auch die Panel-Programme der jeweiligen Desktop-Umgebung gestartet werden, z.B. LXPanel, Xfce Panel und andere: ssh -X user@server lxpanel &

Da Panel-Programme in der Regel nicht über eine Funktion "schließen" verfügen kann man diese z.B. mittels xkill schließen.

Serverkonfiguration

Dies sollte in der Regel nicht notwendig sein. Auf dem Server muss hierfür das Paket xauth installiert werden, wenn es das noch nicht ist. Außerdem muss dem SSH-Daemon des Servers mitgeteilt werden, dass X-Forwarding verwendet wird. Das wird über die Konfigurationsdatei /etc/ssh/sshd_config erledigt. Dort werden die Optionen:

X11Forwarding yes X11UseLocalhost no

gesetzt. Danach ist ein Neustart des Daemons erforderlich.

Zusätzlich müssen in der Client-Konfigurationsdatei /etc/ssh/ssh_config die Einträge:

ForwardX11 yes

und

ForwardX11Trusted yes

durch Entfernen von # am Zeilenanfang einkommentiert werden.

SSH-Tunnel

Wenn man mit Hilfe von SSH so ein nicht ganz triviales Protokoll wie X-Window tunneln kann, dann muss das doch auch mit anderen Protokollen funktionieren, oder? - Aber sicher geht das. Allerdings ist die Syntax für den SSH-Tunnelbau ein wenig verwirrend:

ssh -L [bind_address:]port:host:port user@server ssh -R [bind_address:]port:host:port user@server

Hierbei richtet die Option -L laut Dokumentation eine lokale, und die Option '-R' eine entfernte (englisch remote) Port-Weiterleitung ein.

Der verschlüsselte Tunnel wird dabei immer zwischen dem eigenen Rechner und server hergestellt. Die Verbindung vom Ende des Tunnels zu host läuft dagegen unverschlüsselt ab, und wird aus Sicht des betreffenden Systems angegeben, weswegen man host in den allermeisten Fällen wohl auf "localhost" setzen sollte. Hierbei darf "localhost" nicht mit dem lokalen Rechner verwechselt werden.

Es handelt sich um "localhost" von server aus betrachtet, daher um den Server selbst.

Die Option -L bzw. -R gibt dabei die Richtung an, aus der der Tunnel benutzt werden kann. Bei -L vom eigenen Rechner zum entfernten hin, bei -R in der entgegengesetzten Richtung. (Das merkt man sich am Besten als normaL und Rückwärts.)

Das erste port-Argument bezeichnet dabei den Einstiegsport in die Verbindung. Zu beachten ist hierbei, dass die Öffnung eines privilegierten Ports, also unter 1024, nur dem Superuser root gestattet ist. Man sollte also auf die höheren Ports ausweichen.

Mit dem optionalen Parameter bind_address kann man festlegen, auf welchen Netzwerkschnittstellen die Weiterleitung laufen soll, wobei localhost der Standard ist.

Ein * oder ein leeres bind_address-Argument vor dem Doppelpunkt bedeutet, dass die Weiterleitung an allen Schnittstellen läuft. Möglicherweise funktioniert das nicht auf jedem Ubuntu-System auf Anhieb, da die IPv6-Adresse das irgendwie verhindert, weshalb man den SSH-Tunnel mit dem Argument -4 auf die IPv4-Schnittstellen beschränken muss.

Der zweite port-Parameter gibt schließlich an, auf welchen Port von host die Weiterleitung gehen soll.

Ein weiteres nützliches Argument ist die Option -N, die das Erzeugen einer Terminal-Sitzung auf dem entfernten System unterbindet, wenn man nur die Port-Weiterleitung benutzen möchte.

Beispiele

Weiterleitung von Port 8000 auf dem lokalen System an den Webserver (Port 80) auf server:

ssh -L 8000:localhost:80 server -N & netstat -anp --inet | egrep '(^Proto|8000)' Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:8000 0.0.0.0:* LISTEN 10843/ssh fg ssh -L 8000:localhost:80 server -N [Strg-C] Killed by signal 2.

Dasselbe, aber es wird nicht nur vom lokalen Host weitergeleitet, sondern von allen Schnittstellen (hierzu ist die Option GatewayPorts in der Server-Konfiguration entsprechend zu setzen, genaueres zu finden in der Manpage; man wähle diese Option mit Bedacht!):

ssh -L *:8000:localhost:80 server -N -4 & netstat -anp --inet | egrep '(^Proto|8000)' Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:8000 0.0.0.0:* LISTEN 10906/ssh

Umgekehrte Richtung. Benutzern auf server wird ermöglicht, über localhost:3306 auf den MySQL-Server auf client zuzugreifen:

ssh -R 3306:localhost:3306 server Last login: Sat Mar 11 23:24:20 2006 from 192.168.4.56 netstat -an --inet | egrep '(^Proto|3306)' Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN exit logout Connection to server closed.

Zur Veranschaulichung folgt hier noch einmal eine grafische Darstellung dieser Beispiele:

Doppelter SSH-Tunnel über zwei Konsolen:

supportpc$ ssh -L 54321:localhost:54321 zwischennutzer@zwischen zwischen$ ssh -L 54321:localhost:8080 zielnutzer@ziel

SSH-Tunnel über Zwischenrechner mit Zielrechner verbinden:

supportpc$ ssh -L 54322:ziel:22 zwischennutzer@zwischen

Verschlüsselungsdetails

Symmetrische Verschlüsselung

Wer als Laie an Verschlüsselung denkt, der denkt meist an die "symmetrische Verschlüsselung". Hierbei gibt es genau einen Schlüssel, mit dem ein Datensatz verschlüsselt wird.

Nur wer diesen Schlüssel kennt (oder durch Probieren herausfindet) kann die Verschlüsselung umkehren und den Klartext wieder extrahieren.

Bekannte und bewährte Algorithmen wie TripleDES, AES und Blowfish machen das Erraten des Schlüssels natürlich nicht gerade leicht, genauer gesagt, nach dem heutigen Stand der Technik nahezu unmöglich.

Das einzige Problem bei der Benutzung von symmetrischer Verschlüsselung ist, den Schlüssel sicher zum Kommunikationspartner zu befördern.

Asymmetrische Verschlüsselung

Um dieses Problem der symmetrischen Verschlüsselung zu umgehen, gelang es Forschern schon vor einiger Zeit, das gemeinsame Geheimnis, das für eine erfolgreiche Ver- und Entschlüsselung nötig ist, so hinter komplizierten Algorithmen zu verbergen, dass man es unter bestimmten Bedingungen öffentlich verteilen konnte.

Bei diesem Verfahren, asymmetrische Verschlüsselung genannt, wird nicht ein Schlüssel erzeugt, sondern ein Schlüsselpaar, das mathematisch voneinander abhängt, aber nicht ohne sehr viel Aufwand voneinander abgeleitet werden kann.

Jeweils zwei zueinander passende Schlüssel wirken auf geradezu magische Weise genau entgegengesetzt: Was mit dem einen Schlüssel verschlüsselt wird, kann nur durch den anderen Schlüssel wieder entschlüsselt werden.

Dies ermöglicht es, einen der beiden Schlüssel öffentlich zur Verfügung zu stellen, um Sendungen zu verschlüsseln, die man aber einzig und allein mit dem anderen Schlüssel, den man niemals weitergibt, entschlüsseln kann.

Im Gegenzug kann man ein Datenpaket auch mit dem eigenen privaten Schlüssel chiffrieren. Wenn dieser Chiffretext sich dann mit dem öffentlichen Schlüssel wieder in Klartext zurückverwandeln lässt, weiß jeder, dass die Nachricht nur vom Besitzer des privaten Schlüssels kommen kann.

Diese Anwendungsmöglichkeit nennt man digitale Signatur.

Da der Umgang mit asymmetrischen Verschlüsselungsalgorithmen wie RSA oder DSA signifikant mehr Rechenleistung erfordert als mit symmetrischen, ist es gängige Praxis, am Beginn der Kommunikation mit Hilfe des öffentlichen Schlüssels einen neu generierten, symmetrischen Session-Schlüssel auszutauschen und für den Rest der Kommunikation auf symmetrische Verschlüsselung umzusteigen.

Links

The Secure Shell (SSH) Protocol Architecture http://www.ietf.org/rfc/rfc4251.txt
Video vom Vortrag Ubuntu im sicheren Netz - Ubucon 2011 http://www.youtube.com/watch?v=Hxsl-jj2Bq0
Putting the Secure in SSH - Tipps und Tricks für sicheres SSH. Blogbeitrag, 11/2014http://thepcspy.com/read/making-ssh-secure/
Mosh - auf SSH aufsetzende Lösung für den Fernzugriff auf andere Rechnerhttps://wiki.ubuntuusers.de/Mosh/
autossh - Monitor für SSH-Verbindungen mit Reconnect-Möglichkeit (in den Paketquellen enthalten)http://www.harding.motd.ca/autossh/
Portweiterleitung - DSL-Router für SSH freischaltenhttps://wiki.ubuntuusers.de/Portweiterleitung/
SSH Reverse Tunnel oder wie mache ich ein Loch in die Firewall - Reverse SSH (keine Portweiterleitung nötig)http://www.codejungle.org/site/SSH+Reverse+Tunnel+oder+wie+mache+ich+ein+Loch+in+die+Firewall.html

Secure Shell

Einführung

Was ist Secure Shell

Secure Shell oder SSH meint sowohl ein Netzwerkprotokoll als auch entsprechende Programme, mit deren Hilfe man auf eine sichere Art und Weise eine verschlüsselte Netzwerkverbindung mit einem entfernten Gerät herstellen kann. Häufig wird diese Methode verwendet, um sich eine entfernte Kommandozeile quasi auf den lokalen Rechner zu holen, das heißt, auf der lokalen Konsole werden die Ausgaben der entfernten Konsole ausgegeben und die lokalen Tastatureingaben werden an den entfernten Rechner gesendet.

Hierdurch wird der Effekt erreicht, als säße man vor der entfernten Konsole, was beispielsweise sehr gut zur Fernwartung eines in einem entfernten Rechenzentrum stehenden Root-Servers genutzt werden kann.

Datei:Grafik4.png

Die neuere Protokoll-Version SSH-2 bietet weitere Funktionen wie Datenübertragung per SFTP. Die IANA hat dem Protokoll den TCP-Port 22 zugeordnet, jedoch lassen sich in den Konfigurationsdateien des Daemons auch beliebige andere Ports auswählen.

Informationssicherheit

Secure Shell kann folgende Grundwerte sicherstellen* Vertraulichkeit

Integrität
Nichtabstreitbarkeit

Arbeitsweise

Secure Shell öffnet eine durch Verschlüsselung gesicherte Verbindung, zu einem entfernten Rechner, die mit unterschiedlichen Protokollen und Einsatzszenarien genutzt werden kann. Sowohl Login-, als auch Nutzdaten werden verschlüsselt übertragen.

Einsatzmöglichkeiten

* Entfernter Shell-Zugang

Dateiübertragung
Entfernte Befehlsausführung

* Einbindung in Pipes

Einbinden entfernter Dateisysteme
Tunnelung beliebiger Netzwerkprotokolle

Secure Shell kann damit viele unsichere (unverschlüsselte) Anwendungen wie telnet, ftp, rlogin oder rcp ersetzen und unsichere Protokolle wie http, pop3 oder smb absichern.

Als sicherer Telnet-Ersatz bietet ssh drei wichtige Eigenschaften:* Authentifizierung der Gegenstelle

Verschlüsselung der Datenübertragung und der Anmelde-Informationen
Datenintegrität, also Schutz vor Manipulation der Übertragung

Weitere Funktionen und Eigenschaften

Open Source Project / Freie Software
Starke Verschlüsselung (3DES, Blowfish, AES, Arcfour)
X11 Forwarding (encrypt X Window System traffic)
Strong Authentication (Public Key, One-Time Password and Kerberos Authentication)
Agent Forwarding (Single-Sign-On)
Interoperability (Compliance with SSH 1.3, 1.5, and 2.0 protocol Standards)
Kerberos and AFS Ticket Passing
Data Compression

Ursprung und Entwicklung

Datei:.png

Tatu Ylönen

Mit dem Befehl telnet kann man sich über das Netzwerk bei anderen Systemen anmelden, die den Telnet-Daemon installiert hatten, vorausgesetzt, man kenn das Passwort.

Leider bietet das Protokoll keine Verschlüsselung, so dass das Mitschneiden von Passwörtern und Daten eine triviale Angelegenheit ist.

Um solche Verbindungen abzusichern, erstellte der Finne Tatu Ylönen in den frühen Neunzigern des vorigen Jahrhunderts eine Programmsuite – bestehend aus einem Server, einem Client und mehreren Hilfsprogrammen – die er ssh (secure shell) nannte.

Das SSH-Protokoll, das er veröffentlichte, bot eine komplett verschlüsselte Alternative zu Telnet und noch vieles mehr und wurde ein voller Erfolg.

Als er später die Firma ssh.com gründete und die Version 2 der SSH-Suite nur noch unter einer kommerziellen Lizenz anbot, nahmen sich die Entwickler des Betriebssystems OpenBSD des Quellcodes von ssh1 an und entwickelten das Programm bis zum heutigen Tage unter dem Namen OpenSSH weiter.

Die OpenSSH-Suite ist Bestandteil vieler Unix-Derivate und nahezu jeder Linux-Distribution.

Auch wenn es inzwischen Erweiterungen für Telnet gibt, die bspw. SSL-Verschlüsselung oder Kerberos-Authentifizierung bieten, wurde der Telnet-Server fast komplett von SSH verdrängt und ist nicht mehr verbreitet

Grundlagen

OpenSSH

OpenSSH ist eine FREIE Version der SSH-Verbindungssuite, auf die sich technische Nutzer des Internets verlassen. Benutzer von telnet, rlogin, ftp und ähnlichen Programmen mögen es nicht wissen, dass ihr Passwort unverschlüsselt über das Internet übertragen wird. So ist es jedoch! OpenSSH verschlüsselt den gesamten Datenverkehr (inklusive der Passwörter), um das Mithören (»eavesdropping«), das Einschleichen in Verbindungen (»connection hijacking«) und ähnliche Angriffe effektiv zu unterbinden. Zusätzlich bietet OpenSSH die Möglichkeit zur Erzeugung sicherer Tunnelverbindungen, verschiedene Authentifizierungsmethoden und unterstützt sämtliche Protokollversionen von SSH.

Die OpenSSH-Suite ersetzt rlogin und telnet mit dem Programm ssh, rcp mit scp und ftp mit sftp. Außerdem sind der Server sshd und andere Werkzeuge wie ssh-add, ssh-agent, ssh-keysign, ssh-keyscan, ssh-keygen und sftp-server enthalten.

OpenSSH wird vom OpenBSD-Projekt entwickelt. Die Software wird in Ländern entwickelt, die den Export von Kryptographie erlauben, und ist somit für jeden unter der BSD-Lizenz frei nutz- und wiederverwendbar. Die Entwicklung jedoch verursacht Kosten. Solltest du also OpenSSH als nützlich empfinden (insbesondere, wenn du es in einem kommerziellen System einsetzt, das verkauft wird), so denke bitte über eine Spende nach, um das Projekt finanziell zu unterstützen.

OpenSSH wird von zwei Teams entwickelt. Ein Team führt ausschließlich OpenBSD-basierte Entwicklung durch. Das Ziel dahinter ist, einen Quelltext zu schaffen, der so sauber, einfach und sicher wie möglich ist. Wir glauben, dass die Einfachheit ohne das ganze, für die Portabilität notwendige »Drumherum«, bessere Codequalität ermöglicht. Das andere Team nimmt dann diesen sauberen Quelltext als Basis und macht ihn portabel (fügt also das »Drumherum« hinzu), sodass der Code auf vielen Betriebssystemen ausgeführt werden kann. Das sind dann die so genannten -p-Releases, zum Beispiel »OpenSSH 4.0p1«.

Ein exzellentes Buch zum Erlernen von OpenSSH wurde geschrieben, betitelt SSH Mastery. Wir empfehlen die Bestellung über die OpenBSD Bestellseite, da dies OpenSSH ein wenig weiter hilft.

Wir möchten auch auf unsere Seite Wer setzt OpenSSH ein hinweisen, auf der jene Hersteller gelistet werden, die OpenSSH in ihren eigenen Produkten - als eine sicherheitskritische Schlüsselkomponente - einsetzen, statt ihre eigene SSH-Implementation zu schreiben oder die Implementierung eines anderen Herstellers zu kaufen. Diese Liste beinhaltet insbesondere Firmen wie Cisco, Juniper, Apple, Red Hat und Novell; aber möglicherweise gehören dazu auch alle Router- oder Switchhersteller sowie Entwickler von Unix-artigen Betriebssystemen. In den 10 Jahren, in denen das OpenSSH-Projekt besteht, haben diese Firmen nicht einen einzigen Euro aus Dankbarkeit beigetragen, um das OpenSSH-Projekt zu unterstützen (lediglich unzählige Anfragen).

Projektziele

Unser Ziel ist einfach: Weil telnet und rlogin unsicher sind, sollten alle Betriebssysteme mit SSH-Unterstützung ausgeliefert werden (siehe Bild unten).

Das SSH-Protokoll gibt es in zwei inkompatiblen Varianten: SSH 1 und SSH 2.

Das ältere SSH-1-Protokoll teilt sich wieder in zwei Hauptvarianten auf: Protokoll 1.3 und Protokoll 1.5. Beide werden von OpenSSH unterstützt, verwenden für die Schlüsselübertragung den asymmetrischen Kryptographiealgorithmus RSA (dessen USA-Patent abgelaufen ist und somit für jedermann frei zur Verfügung steht) und greifen dann auf ein paar symmetrische Algorithmen zurück, um die Daten zu verstecken: 3DES und Blowfish (es gab ein paar andere Algorithmen, wie z. B. RC4, doch hätte ihre Implementation zu Sicherheitsproblemen geführt). Einige SSH-1-Protokollimplementationen unterstützen außerdem den symmetrischen IDEA-Algorithmus. OpenSSH hat aber keine Unterstützung für IDEA, weil dieser Algorithmus in einigen Nationen patentiert ist und die anderen beiden völlig ausreichend sind.

Das SSH-1-Protokoll benutzt ein einfaches CRC, um die Datenintegrität sicherzustellen, was sich aber als fehlerhaft herausstellte - ein Insertionangriff ist bekanntermaßen möglich. Angriffe sind aber wegen den vielen Heftpflastern, die über die Jahre auf SSH aufgeklebt wurden, überaus schwierig durchzuführen. Wird der 3DES-Cipher benutzt, ist der Insertionangriff bedeutend schwieriger auszuführen (wir lösen das Problem wahrscheinlich bald).

Die zweite Hauptvariante von SSH ist das SSH-2-Protokoll. SSH 2 wurde eingeführt, um die patentrechtlichen Schwierigkeiten bezüglich des RSA-Protokolls zu umgehen (was inzwischen nicht mehr nötig ist, da das Patent abgelaufen ist), das CRC-Datenintegritätsproblem von SSH 1 zu lösen und aus einer Reihe weiterer technischer Gründe. Durch die Benutzung der asymmetrischen Algorithmen DSA und DH vermeidet Protokoll 2 alle Patente. Das CRC-Problem wird durch die Benutzung eines richtigen HMAC-Algorithmus gelöst. Neben vielen neuen symmetrischen Ciphern unterstützt das SSH-2-Protokoll auch viele neue Funktionen.

Seit dem 1. Dezember 1999 beinhaltet der OpenSSH-Quelltext volle Unterstützung für die Protokolle 1.3 und 1.5.

Für viele Kryptographiefunktionen greift OpenSSH auf die nicht unter der GPL stehende OpenSSL-Bibliothek zurück.

Fast sofort nachdem wir unsere Implementation des SSH-1-Protokolls veröffentlicht hatten, zeigten verschiedene Gruppen außerhalb von OpenBSD sehr, sehr großes Interesse daran. Damien Miller, Philip Hands und eine handvoll Anderer fingen an, OpenSSH auf Linux und verschiedene andere Unix-Betriebssysteme zu portieren. Von Anfang an unserer Bemühungen hatten wir das Gefühl, dass sogar der originale SSH-Code zu kompliziert war - er hatte einfach zu viele Betriebssystemabhängigkeiten in sich. Unser Anspruch, komplett sicheren und absolut stabilen Code zu schreiben, verhindert es natürlich, sich mit solchen übermäßigen Unterschieden herumzuschlagen. Um daher den gesamten Entwicklungsprozess für uns alle einfacher zu machen, haben wir die Kernentwicklung von der Portabilität getrennt. Das hat für uns sehr gut funktioniert (vergleiche doch mal die Anzahl der Zeilen zwischen der Basisversion und den portablen Versionen).

Diesen Trend fortführend haben Mitglieder des Projektteams von OpenBSD, die an OpenSSH gearbeitet haben, sich stark bemüht, das SSH-2-Protokoll ebenfalls zu unterstützen. Diese Arbeit wurde primär von Markus Friedl gemacht. Um den 4. Mai 2000 herum wurde das SSH-2-Protokoll so weit unterstützt, dass es von da an nutzbar war.

Funktionalität

OpenSSH ist eine freie SSH/SecSH-Protokollsuite, die Verschlüsselung für Netzwerkdienste bereitstellt, wie etwa Remotelogins, also Einloggen auf einem anderen, entfernten Rechner, oder auch Dateiübertragung von oder zu einem entfernten Rechner.

Es folgt eine Liste der Fähigkeiten von OpenSSH: * Open-Source-Projekt

Freie Lizenzpolitik
Starke Verschlüsselung (3DES, Blowfish, AES, Arcfour)
X11-Weiterleitung (verschlüsselt X-Window-System-Netzwerkverkehr)
Portweiterleitung (verschlüsselte Kanäle für bestimmte Protokolle)
Starke Authentifizierung (Öffentliche Schlüssel, Einmal-Passwort- und Kerberos-Authentifizierung)
Agentweiterleitung (Single-Sign-On)
Interoperabilität (arbeitet kompatibel zu den SSH-Protokollstandards 1.3, 1.5 und 2.0)
SFTP-Client- und -Serverunterstützung sowohl im SSH1- als auch im SSH2-Protokoll.
Kerberos- und AFS-Ticketpassing
Datenkompression

Open-Source-Projekt

Der OpenSSH-Quelltext ist für jeden frei über das Internet erhältlich. Das ermutigt zur Wiederverwendung und weiteren Untersuchung des Quelltextes. Diese weitere Untersuchung stellt sicher, dass Fehler von jedem gefunden und korrigiert werden können. Das führt zu sicherem Code.

Freie Lizenzpolitik

OpenSSH wird nicht von einer restriktiven Lizenz eingeschränkt. Es kann für jeglichen Zweck eingesetzt werden und das schließt auch jegliche kommerzielle Nutzung ein. Die Lizenz für OpenSSH ist selbstverständlich der Distribution beigefügt. Wir sind der Meinung, dass die Welt besser wäre, wenn Router, Netzwerkgeräte, Betriebssysteme und alle anderen Netzwerkkomponenten ssh integriert hätten.

Alle Komponenten restriktiver Natur (z. B. Patente, siehe ssl) wurden aus dem Quellcode entfernt: Jegliche lizenzierten oder patentierten Teile werden aus externen Quellen bezogen (z. B. OpenSSL). Die symmetrische Chiffre IDEA ist nicht mehr verfügbar, da sie in vielen Ländern patentiert ist. Stattdessen empfehlen wir die Benutzung einer der anderen verfügbaren Chiffren. (Wir sehen keine Rechtfertigung für die Benutzung einer patentierten symmetrischen Chiffre, zumal es so viele andere freie gibt).

Was ist mit Copyrights, Benutzung und Patenten?

Die OpenSSH Entwickler haben sehr hart versucht, OpenSSH frei von Patent- oder Copyrightproblemen zu halten. Dazu mussten einige Optionen aus OpenSSH entfernt werden. Nämlich die Unterstützung für patentierte Algorithmen.

OpenSSH unterstützt keinerlei patentierte Transportalgorithmen. Im SSH1-Modus sind nur 3DES und Blowfish möglich. Im SSH2-Modus können nur 3DES, Blowfish, CAST128, Arcfour und AES ausgewählt werden. Der patentierte IDEA-Algorithmus wird nicht unterstützt.

OpenSSH bietet Unterstützung für sowohl das SSH1- als auch das SSH2-Protokoll.

Seit das RSA-Patent ausgelaufen ist, gibt es keinerlei Beschränkungen mehr für Software, die den RSA-Algorithmus benutzen, inklusive OpenBSD.

Starke Verschlüsselung

OpenSSH unterstützt 3DES, Blowfish, AES und Arcfour als Verschlüsselungsalgorithmen. Sie sind patentfrei. Triple DES ist ein sehr gut verstandener Chiffrieralgorithmus, der den Zahn der Zeit überstanden hat und eine starke Verschlüsselung bereitstellt.

Blowfish ist ein schneller Blockchiffrierer, der von Bruce Schneier entworfen wurde und von Leuten benutzt werden kann, die eine schnellere Verschlüsselung benötigen.

AES ist der verbesserte Verschlüsselungsstandard des US Federal Information Processing Standard (FIPS), der als Ersatz für DES entwickelt wurde. Dabei handelt es sich um eine Blockchiffre.

Arcfour ist eine schnelle Stromchiffre. Sie wird als kompatibel zu RC4[TM] angesehen, einer proprietären Chiffre von RSA Security Inc.

Die Verschlüsselung beginnt vor der Authentifizierung und es werden keine Passwörter oder andere Daten im Klartext übermittelt. Verschlüsselung wird auch benutzt, um sich gegen sogenannte Spoof-Angriffe zu verteidigen, bei denen sich eine Person als jemand anderes ausgibt.

X11-Weiterleitung

X11-Weiterleitung erlaubt die Verschlüsselung von X-Windows-Netzwerkverkehr, also Netzwerkübertragung, auf eine Weise, die niemanden den Datenverkehr mitlesen oder bösartige Kommandos einschleusen lässt. Das Programm setzt DISPLAY automatisch auf dem Server und leitet jegliche X11-Verbindung über den sicheren Tunnel weiter. Gefälschte Xauthority-Informationen werden automatisch generiert und an die entfernte Maschine weitergeleitet; der lokale Client untersucht automatisch ankommende X11-Verbindungen und ersetzt die gefälschten Authorisierungsdaten mit den echten Daten (und gibt der entfernten Maschine nie die echten Informationen).

Port-Weiterleitung

Port-Weiterleitung erlaubt die Weiterleitung von TCP/IP-Verbindungen zu einer entfernten Maschine über ein verschlüsseltes Protokoll. Standard-Internetapplikationen wie POP können damit sicherer gemacht werden.

Starke Authentifizierung

Starke Authentifizierung schützt gegen verschiedene Sicherheitsprobleme, z. B. IP-Spoofing, gefälschte Routen, und DNS-Spoofing. Die Authentifizierungsmethoden sind: .rhosts zusammen mit RSA-basierter Hostauthentifizierung, pure RSA-Authentifizierung, Einmal-Passwörter mit s/key und letztlich Authentifizierung mittels Kerberos.

Agentweiterleitung

Ein Authentifizierungsagent, der auf dem Laptop oder der lokalen Maschine des Anwenders läuft, kann benutzt werden, um den RSA- oder DSA-Authentifizierungsschlüssel des Anwenders bereitzuhalten. OpenSSH leitet die Verbindung automatisch an den Authentifizierungsagenten über jede Verbindung weiter, und es gibt keine Notwendigkeit, die RSA-Authentifizierungsschlüssel auf jeder Maschine im Netzwerk zu haben (mit Ausnahme der lokalen Maschine des Benutzers). Die Authentifizierungsprotokolle geben die Schlüssel niemals preis; sie können nur dazu benutzt werden, um abzufragen, ob der Benutzer einen entsprechenden Schlüssel hat. Eventuell könnte der Agent auf einer Smart-Card beruhen, die alle Authentifizierungsberechnungen macht.

Interoperabilität

OpenSSH-Versionen vor 2.0 unterstützen die SSH-1.3- und -1.5-Protokolle, die es erlauben, mit den meisten Unix-, Windows- und anderen, kommerziellen SSH-Implementationen zu kommunizieren.

Seit der Version 2.0 unterstützt OpenSSH neben den SSH-Protokollversionen 1.3 und 1.5 auch die SSH-Protokollversion 2.0. Dieses Protokoll vermeidet die Benutzung des RSA-Algorithmus - da zur Zeit der Einführung des Protokolls 2.0 das RSA-Patent noch gültig war - und benutzt stattdessen die frei benutzbaren DH- und DSA-Algorithmen.

Daher gibt dir OpenSSH das Beste aus beiden Welten. Du kannst mit beiden Typen von SSH-Clients und -Servern arbeiten und kommunizieren!

SFTP-Client- und -Serverunterstützung in sowohl dem SSH1- als auch dem SSH2-Protokoll

Seit OpenSSH 2.5.0 ist komplette SFTP-Unterstützung integriert; dazu wird das sftp(1)-Kommando als Client benutzt. Das sftp-server(8)-Subsystem arbeitet automatisch mit sowohl dem SSH1- als auch dem SSH2-Protokoll.

Kerberos- und AFS-Ticketpassing

OpenSSH gibt auch Tickets für Kerberos und AFS an die entfernte Maschine weiter. Ein Benutzer kann daher auf alle seine Kerberos- und AFS-Dienste zugreifen, ohne sein Passwort wieder eintippen zu müssen.

Datenkompression

Datenkompression vor der Verschlüsselung beschleunigt die Leistung über langsame Netzwerkverbindungen.

Warum sollte SSH eingesetzt werden?

OpenSSH ist eine Sammlung von Werkzeugen, die dir hilft, deine Netzwerkverbindungen sicherer zu machen. Hier ist eine Liste der Funktionalitäten: * Starke Authentifikation. Schließt verschiedene Sicherheitslöcher (z. B. IP-, ,routing'-, und DNS-,spoofing').

Verbesserte Privatsphäre. Alle Verbindungen werden automatisch und transparent verschlüsselt.
Sichere X11-Sitzungen. Das Programm setzt DISPLAY auf der Servermaschine automatisch und leitet alle X11-Verbindungen über den sicheren Kanal weiter.
Willkürliche TCP/IP-Ports können durch den verschlüsselten Kanal in beide Richtungen gelenkt werden (z. B. für e-cash-Transaktionen).
Für normale Benutzer wird keine Schulung und kein Training benötigt.
Vertraut nie dem Netzwerk. Minimales Vertrauen auf der Gegenseite der Verbindung. Minimales Vertrauen gegenüber den Domain Name Servern. Pure RSA-Authentifikation vertraut nichts und niemandem, bis auf den ,private key'.
Der Client authentifiziert die Servermaschine am Beginn jeder Verbindung mit RSA, um ,trojanischen Pferden' (durch ,routing'- oder DNS-,spoofing') und ,man-in-the-middle'-Angriffen vorzubeugen, und der Server tut das Gleiche mit der Clientmaschine bevor er .rhosts- oder /etc/hosts.equiv-Authentifikation erlaubt (um DNS-, ,routing'- oder IP-,spoofing' vorzubeugen).
Die ,host authentication key'-Distribution kann zentral laufen, wird jedoch automatisch, sobald die erste Verbindung zur Maschine geöffnet wird.
Jeder Benutzer kann beliebig viele RSA-Authentifikationsschlüssel zur eigenen Verwendung erzeugen.
Das Serverprogramm hat seinen eigenen RSA-Schlüssel, der jede Stunde automatisch neu erzeugt wird.
Ein Authentifikationsagent, der auf dem Laptop oder der Workstation des Benutzers läuft, kann benutzt werden, um die RSA-Authentifikationsschlüssel des Anwenders zu halten.
Die Software kann auch ohne root-Privilegien installiert und benutzt werden (mit eingeschränkter Funktionalität).
Der Client ist in systemweiten und benutzerspezifischen Konfigurationsdateien anpassbar.
Optionale Kompression aller Daten mittels gzip (inklusive ,forwarded X11'- und TCP/IP-Daten), was zu bedeutenden Beschleunigungen auf langsamen Verbindungen führen kann.
Kompletter Ersatz für rlogin, rsh und rcp.

Zurzeit werden fast alle Übertragungen in Computernetzwerken unverschlüsselt durchgeführt. Als Konsequenz kann jeder, der Zugriff auf irgendeine Maschine in diesem Netzwerk hat, alle Verbindungen abhören. Das wird auch von Hackern, neugierigen Administratoren, Arbeitgebern, Kriminellen, Industriespionen und Regierungen so durchgeführt. Einige Netzwerke senden derartig viel elektromagnetische Strahlung ab, dass Daten sogar in großer Entfernung noch aufgefangen werden können.

Wenn du dich einloggst, wird dein Passwort im Klartext übertragen. Daher kann dann jeder Lauscher deinen Account zu jeglicher Tat benutzen. Es gibt weltweit viele Zeugnisse dafür, dass Cracker auf dem Rechner eines Opfers unbemerkt ein Programm gestartet haben, welches ohne Wissen des Anwenders einfach nur das Netzwerk belauscht und Passwörter gesammelt hat. Programme, die das tun, gibt es im Internet oder können von einem kompetenten Programmierer innerhalb weniger Stunden selbst geschrieben werden.

Firmen haben Geschäftsgeheimnisse, Patentanträge in Vorbereitung, Preisinformationen, Informationen über Vertragspartner, Kundendaten, Personendaten, Finanzdaten etc. Zurzeit kann jeder mit Zugriff auf das Netzwerk (jede Maschine im Netzwerk) alles belauschen, was im Netzwerk vor sich geht, und das noch ohne die normalen Zugriffsbeschränkungen.

Vielen Firmen ist nicht bewusst, dass Informationen so einfach aus ihrem Netzwerk gesammelt werden können. Sie vertrauen darin, dass ihre Daten sicher sind, da niemand wissen kann, dass dort vertrauliche Informationen kursieren, oder auch, weil dort so viele andere Daten übertragen werden. Dies ist keine sichere Einstellung.

Alternativen zu OpenSSH

Putty ist eine freie Implementierung eines ssh-Clients, welche im Gegensatz zu dem in OpenSSH enthaltenen Client eine grafische Benutzeroberfläche bietet. Purry Version ist verfügbar unter http://www.chiark.greenend.org.uk/~sgtatham/putty/.

Dann gibt es noch einige kommerzielle SSH-Varianten, z.B. auf http://www.ssh.com und http://www.f-secure.com Zusätzlich zu den Möglichkeiten von OpenSSH enthalten sie Programme zur zentralen Konfiguration von Servern, Schlüsseln und Tunnels.

Unix-Alternativen

Wenn du unter Unix nicht OpenSSH benutzen willst, stehen die folgenden ,freien' SSH-Implementationen zur Zusammenarbeit mit OpenSSH zur Verfügung:* OSSH ist eine Nur-SSH1-Implementation. BSD-Lizenz.

Björn Grönvall war die eigentliche Person, die unsere Gemeinschaft daran erinnert hat, dass sehr alte Versionen von ssh eine freie Lizenz hatten. Dies ist seine eigene Implementation und basiert auf dem alten Code von Tatu. OpenSSH basierte auf einer frühen Version von OSSH, aber OpenSSH fügte SSH2-Protokollunterstützung hinzu und erweiterte die Unterstützung des SSH1-Protokolls.
LSH/psst ist eine Nur-SSH2-Implementation von Niels Möller aus Schweden, GPL-Lizenz.
"ssh benutzt kryptographische Techniken, um die Sicherheit von alltäglichen Zielen wie etwa Dateiübertragungen, ,remote logins' und ,remote Command execution' zu erhöhen. Es ist als sichere(re) Alternative zu telnet, ftp, rsh, rlogin und rexec gedacht - und braucht viel weniger Aufwand als Kerberos oder IPSEC momentan verlangen."
Dropbear ist eine kleine SSH2-nur-Serverimplementierung, die von Matt Johnston geschrieben wurde. Sie ist unter MIT-style Lizenz erhältlich.

Windows

Die folgenden ,freien' SSH-Implementationen werden für die Zusammenarbeit von Windows-Maschinen mit OpenSSH empfohlen:* PuTTY ist eine SSH1+SSH2-Implementation. PSCP, ein scp-artiges Programm für Windows, ist auch verfügbar. PuTTY unterliegt der MIT-Lizenz (BSD-ähnlich). "PuTTY ist eine freie Implementation von Telnet und SSH für Win32-Plattformen, geschrieben und gepflegt hauptsächlich von Simon Tatham, der in Großbritannien lebt."

TTSSH (SSH1) ist eine Nur-SSH1-Implementation von Robert O'Callahan. "TTSSH ist ein freier SSH-Client für Windows. Er ist als Erweiterungs-DLL für Teraterm Pro implementiert. Teraterm Pro ist ein fantastischer freier Terminal-Emulator/Telnet-Client für Windows und sein Quellcode ist verfügbar. TTSSH fügt Teraterm Pro SSH-Fähigkeiten hinzu, ohne irgendwelche bestehenden Funktionen von Teraterm zu opfern. TTSSH kann ebenfalls frei heruntergeladen und benutzt werden und sein Quellcode ist ebenfalls mit freier Lizenz erhältlich. Weiterhin wurde TTSSH vollständig in Australien implementiert [...]." Eine alternative Variante von UTF-8 TeraTerm Pro mit TTSSH2 ist ebenfalls erhältlich.
Cygwin (POSIX-Software als Aufsatz für Windows) OpenSSH (Protokolle SSH1 und SSH2) mit Cygwin kann unter Windows mit Hilfe der portablen Version von OpenSSH laufen, welche entweder aus dem Quelltext übersetzt, oder als natives Cygwin-Paket installiert werden kann.
WinSCP WinSCP ist ein GUI-sftp(1)- und -scp(1)-Clientprogramm für Windows. Der Kern des SSH-Protokolls basiert auf PuTTY.
FileZilla FileZilla ist ein mächtiger FTP-Client für Windows 9x, ME, NT4, 2000 und XP. Es wurde auf eine leichte Bedienung ausgelegt und soll dabei so viele Funktionalitäten wie möglich haben und trotzdem noch schnell und zuverlässig sein. Es unterstützt SFTP.

Mac OS

Die folgenden Clients sind für die Interoperation mit OpenSSH von ,Mac OS'-Maschinen aus empfohlen. Bedenke, dass Mac OS X OpenSSH standardmäßig beinhaltet. * NiftyTelnet 1.1 SSH ist eine Nur-SSH1-Implementation, welche mit einem scp-style Programm ausgeliefert wird. Geschrieben von Jonas Wallden.NiftyTelnet 1.1 SSH r3 ist eine erweiterte Version von Chris Newmans NiftyTelnet-1.1-Anwendung, welche die Unterstützung für verschlüsselte Terminalsitzungen unter Verwendung des SSH- (Secure Shell) Protokolls hinzufügt. Bitte lies die beigelegte Readme-Datei, bevor du diese Version verbreitest."

MacSSH ist eine Nur-SSH2-Implementation. "MacSSH ist eine modifizierte Version von BetterTelnet mit SSH2-Unterstützung. [...] Den einzigen SSH2-Client für Mac OS, den ich finden konnte, war ein kommerzielles Produkt, das mehr als 100 $ kostet und meinen Mac abstürzen lässt, wenn ich eine Sitzung beende... Da es das Beste ist, Dinge selbst in die Hand zu nehmen, ist MacSSH hier."
Fugu ist eine Implementation von SFTP und SCP für Mac OS X. "Fugu SSH ist eine Mac OS X grafische Oberfläche für OpenSSHs ,Secure File Transfer'-Anwendung (SFTP). Fugu erlaubt dir, die Vorteile von SFTPs Sicherheit zu nutzen, ohne die Benutzerfreundlichkeit einer GUI zu opfern. Fugu beinhaltet auch Unterstützung für SCP-Dateiübertragungen und die Möglichkeit, sichere Tunnel durch SSH zu erzeugen."
Cyberduck ist ein SFTP- und FTP-Browser für Mac OS X. "Cyberduck ist ein Open-Source-SFTP- (SSH Secure File Transfer) und -FTP-Browser, der unter der GPL lizenziert ist. Es wurde von Grund auf mit Benutzerfreundlichkeit im Hinterkopf entwickelt, sodass eine einheitliche Oberfläche für das SFTP- und FTP-Browsen gegeben ist. Mehrere Verbindungen sind verfügbar. [...] Kernsystem-Technologien wie zum Beispiel Keychain und Rendezvous werden unterstützt."

Was ist OpenSSH und wo kann ich sie herunterladen?

OpenSSH bietet verschlüsselten Endpunkt-zu-Endpunkt-Ersatz für Anwendungen wie zum Beispiel telnet, rlogin und ftp. Im Gegensatz zu diesen überkommenen Anwendungen, übergibt OpenSSH niemals irgend etwas (einschließlich Benutzername und Passwort) in unverschlüsselter Form an den Draht, und bietet Hostauthentifizierung, um zu überprüfen, ob man wirklich mit dem System spricht, mit dem man zu sprechen glaubt, und um zu verhindern, das jemand anderes die Sitzung übernehmen kann.
Die OpenSSH-Suite beinhaltet das ssh(1)-Programm, das rlogin und telnet ersetzt, und scp(1), das rcp(1) und ftp(1) ersetzt. OpenSSH beinhaltet auch sftp(1) und sftp-server(8), die eine einfache Lösung für Dateiübertragungen realisieren. Sie basieren auf dem secsh-filexfer-IETF-Entwurf.

OpenSSH besteht aus mehreren Programmen.

sshd(8) - Serverprogramm, das auf der Servermaschine läuft. Es lauscht, ob es Verbindungswünsche von Clientmaschinen gibt und führt dann eine Authentifikation durch, bevor es den Client bedient. Das Verhalten wird von der Konfigurationsdatei sshd_config(5) verwaltet.
ssh(1) - Dies ist das Clientprogramm, das benutzt wird, um sich auf einer anderen Maschine einzuloggen oder dort Kommandos auszuführen. slogin ist ein weiterer Name für dieses Programm. Das Verhalten wird von der systemweiten Konfigurationsdatei ssh_config(5) und den benutzerspezifischen $HOME/.ssh/config-Dateien verwaltet.
scp(1) - Kopiert Dateien sicher von einer Maschine zur anderen.
ssh-keygen(1) - Wird benutzt, um ,Pubkey'-Authentifikations-Schlüssel (RSA oder DSA) zu erzeugen (Hostschlüssel und Benutzer-Authentifikationsschlüssel).
ssh-agent(1) - Authentifikationsagent. Er kann benutzt werden, um RSA-Schlüssel für die Authentifikation bereitzuhalten.
ssh-add(1) - Wird benutzt, um neue Schlüssel beim Agenten zu registrieren.
sftp-server(8) - SFTP-Server-Subsystem.
sftp(1) - Sicheres Dateiübertragungsprogramm.
ssh-keyscan(1) - Sammelt ssh-Publickeys ein.
- - ssh-keysign(8) - ssh Hilfsprogramm für hostbasierte Authentifikation.

Bestandteile

Die OpenSSH-Distribution enthält folgende Programme:

Name	Verwendung
`ssh`	ist der ssh-Client. Er baut die Verbindung zu einem ssh-Server auf. Er wird in den folgenden Kapiteln detailliert beschrieben.
`sshd`	ist der ssh-Server. Er nimmt die Verbindung von ssh-Clients auf. Details: siehe Konfigurationshinweise
`ssh-keygen`	erstellt und konvertiert Schlüssel. Details: siehe unten.
`ssh-agent`,`ssh-add`	hält den entschlüsselten Privatekey im Arbeitsspeicher, wo er von ssh-clients angesprochen werden kann. Details: siehe unten.
`ssh-keyscan`	zeigt den Hostkey eines ssh-Servers an. Anwendungsbeispiel: siehe unten.

Unterstützte Betriebssysteme

Obwohl OpenSSH unter OpenBSD entwickelt wird, gibt es eine breite Palette an Portierungen auf andere Betriebssysteme. Die portable Version von OpenSSH wird von Damien Miller geleitet. Einen schnellen Überblick über die portable Version von OpenSSH gibt dir http://www.openssh.com/portable.html. Betriebssysteme, die zurzeit unterstützt werden, sind:

OpenBSD
NetBSD
FreeBSD
AIX
HP-UX
IRIX
Linux
NeXT
SCO
SNI/Reliant Unix
Solaris
Digital Unix/Tru64/OSF
Mac OS X
Cygwin

Eine Liste der Anbieter, die OpenSSH in ihre Distributionen einbinden, befindet sich auf der OpenSSH-Benutzerseite.

Herunterladen

Die neueste Version von OpenSSH ist Teil der aktuellen Ausgabe von OpenBSD, und wird stets zusammen mit der Basisinstallation installiert.

Heutzutage beinhalten die meisten anderen Betriebssysteme eine Version von OpenSSH (oft umetikettiert oder »geheim« gekennzeichnet), sodass die meisten Benutzer es unmittelbar benutzen können. Wie auch immer, manchmal sind die enthaltenen Versionen ziemlich alt, und lassen Merkmale vermissen, die die aktuelle Veröffentlichung von OpenSSH hat, sodass man gerne die aktuelle Version installieren möchte, oder man möchte sie auf einem der wenigen Betriebssysteme installieren, auf denen sie fehlt, und für die der Herausgeber des Betriebssystems keine moderne Version verfügbar macht. Vielleicht möchte man auch OpenSSH auch für eine eingebettete Anwendung nutzen.

Nicht-OpenBSD-Nutzer werden die portable Distribution von einem Spiegelserver in ihrer Nähe herunterladen, und dann kompilieren und installieren wollen.

Bezugsquellen

OpenSSH ist für sämtliche Betriebssysteme compiliert worden und im Lieferumfang der meisten Linux- oder BSD-Distributionen enthalten.

Ein exzellenter Windows-Port unter Verwendung der CygWin32 Bibliotheken ist erhältlich auf http://www.networksimplicity.com/openssh/

ssh-Protokolle

Datei:Grafik8.png

Beim Einsatz von OpenSSH wird meist ein ssh-Client (/usr/bin/ssh) einen ssh-Server (/usr/sbin/sshd) ansprechen, der auf einem anderen Rechner laeuft und auf Port 22 lauscht.

Im Laufe der Kommunikation kommen die verschiedensten Protokolle zum Einsatz.

user@localhost:~ $ echo SSH-1.99-user| nc -w 1 gate 22

SSH-1.99-OpenSSH_3.4p1Debian1:3.4p1-1\n[...]
diffie-hellman-group-exchange-sha1,diffie-hell
man-group1-sha1\0\0\0017ssh-rsa,ssh-dss\0\0\0faes128-cbc
,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
,rijndael-cbc@lysator.liu.se\0\0\0faes128-cbc,3des-cbc,blowfish-cbc
,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.
liu.se\0\0\0Uhmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@opens
sh.com,hmac-sha1-96,hmac-md5-96\0\0\0Uhmac-md5,hmac-sha1,hmac-ripem
d160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96\0\0\0\tnone
,zlib\0\0\0\tnone,zlib\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0

Die Liste zeigt die in der ssh-Protokollversion 2 enthaltenen Algorithmen.

Eine Untermenge war bereits in der ssh-Protokollversion 1 enthalten, die heute aus Sicherheitsgründen nicht mehr verwendet werden sollte. OpenSSH 3 spricht wahlweise die Protokollversionen 1 oder 2.

Details zu den einzelnen Algorithmen gibt es hier:*

Datei:Grafik69.png

draft-galb-secsh-gssapi-00.txt

Verschlüsselung

ssh verschlüsselt die gesamte Kommunikation zum sshd, inkl. der Anmeldung und aller Tunnels. Man kann dabei zwischen verschiedenen Verschlüsselungsalgorithmen wählen, z.B. * 3des gilt als besonders sicher, benötigt aber viel Rechenzeit

blowfish arbeitet besonders schnell

Hier sind einige Möglichkeiten zur Auswahl des blowfish-Algorithmus im lokalen Netz, der die beteiligten Prozessoren entlastet und somit die Kommunikation beschleunigt:* ssh -c blowfish ...

ssh -o Cipher=blowfish...
Eintrag Cipher blowfish für einige oder alle Hosts in der ~/.ssh/config oder /etc/ssh/ssh_config.

In Verbindung mit Portforwarding lassen sich unsichere Netzabschnitte für den Client völlig unsichtbar verschlüsseln, etwa um zwei Firmenstandorte über das Internet zu verbinden:

Datei:Grafik72.png

Symmetrische Verschlüsselung

Wer als Laie an Verschlüsselung denkt, der denkt meist an die "symmetrische Verschlüsselung".

Hierbei gibt es genau einen Schlüssel, mit dem ein Datensatz verschlüsselt wird.

Nur wer diesen Schlüssel kennt (oder durch Probieren herausfindet) kann die Verschlüsselung umkehren und den Klartext wieder extrahieren.

Datei:Grafik12.png

Bekannte und bewährte Algorithmen wie TripleDES, AES und Blowfish machen das Erraten des Schlüssels natürlich nicht gerade leicht, genauer gesagt, nach dem heutigen Stand der Technik nahezu unmöglich.

Das einzige Problem bei der Benutzung von symmetrischer Verschlüsselung ist, den Schlüssel sicher zum Kommunikationspartner zu befördern.

Asymmetrische Verschlüsselung

Um das Problem der Verteilung symmetrischen Verschlüssel zu umgehen, wird das Geheimnis für Ver- und Entschlüsselung hinter Algorithmen verborgen, damit es öffentlich verteilen kann.

Bei dieser asymmetrische Verschlüsselung, wird ein Schlüsselpaar erzeugt, das mathematisch voneinander abhängt, aber nur mit sehr großem Aufwand voneinander abgeleitet werden kann.

Zwei zueinander passende Schlüssel wirken genau entgegengesetzt:

Was mit dem einen Schlüssel verschlüsselt wird, kann nur durch den anderen Schlüssel wieder entschlüsselt werden.

Datei:Grafik10.png

Dies ermöglicht es, einen der beiden Schlüssel öffentlich zur Verfügung zu stellen, um Sendungen zu verschlüsseln, die man aber einzig und allein mit dem anderen Schlüssel, den man niemals weitergibt, entschlüsseln kann.

Im Gegenzug kann man ein Datenpaket auch mit dem eigenen privaten Schlüssel chiffrieren.

Wenn dieser Chiffretext sich dann mit dem öffentlichen Schlüssel wieder in Klartext zurückverwandeln lässt, weiß jeder, dass die Nachricht nur vom Besitzer des privaten Schlüssels kommen kann. Diese Anwendungsmöglichkeit nennt man digitale Signatur.

Asymmetrischen Verschlüsselungsalgorithmen wie RSA oder DSA erfordert deutlich mehr Rechenleistung als symmetrische.

Es ist gängige Praxis, am Beginn der Kommunikation mit Hilfe des öffentlichen Schlüssels einen neu generierten, symmetrischen Session-Schlüssel auszutauschen und für den Rest der Kommunikation auf symmetrische Verschlüsselung umzusteigen.

Datei:Grafik7.png

Secure Shell nutzt für viele seiner Funktionen Bibliotheken der OpenSSL-Suide.

Grafische Verbindungsverwaltung

Wem es zu mühsam ist, in der Konsole die SSH-Verbindung zu einem Server aufzubauen, der sucht vielleicht ein grafisches Programm, um seine Verbindungsdaten zu verwalten.* kssh - Das Programm erlaubt, Server, Benutzernamen und Optionen zu speichern, und öffnet dann eine Konsole mit dem entsprechenden Login.

gnome-rdp - Mit dem Programm kann man nicht nur RDP und VNC Verbindungen aufbauen, sondern auch normale SSH Terminal Sitzungen. Leider kann man in der aktuellen Version die Zugangspasswörter nicht speichern lassen und keine Angaben zum verwendeten Port machen, es funktioniert somit nur mit Servern die den Standard-SSH-Port nutzen.
putty - Das eher unter Windows bekannte Programm gibt es sehr wohl auch unter Linux.

Anwendungen

Entferntes Konsolen-Login

Der SSH-Client

Mit dem Konsolen-Programm ssh können folgende Aufgaben erledigt werden* Aufruf einer entfernten Shell

Weiterleiten der Ausgabe grafischer Programme
Entfernte Programmausführung
Einrichtung von Tunneln

ssh --h

usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
           [-D [bind_address:]port] [-e escape_char] [-F configfile]
           [-I pkcs11] [-i identity_file]
           [-L [bind_address:]port:host:hostport]
           [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
           [-R [bind_address:]port:host:hostport] [-S ctl_path]
           [-W host:port] [-w local_tun[:remote_tun]]
           [user@]hostname [command]

Durch Eingabe von

ssh hostname

eröffnet man eine Shell auf dem Rechner hostname.

Die Anmeldung erfolgt mit dem lokalen Usernamen

Wenn man sich auf dem anderen Rechner unter einem anderen Usernamen anmelden möchte, hilft entweder* ssh -l username hostname

ssh username@hostname
ssh -o User=username hostname
ssh hostname und User hostname in der config-Datei.

Escape-Kommandos

Während der ssh-Sitzung kann man nach Eingabe von <Enter><Tilde> mit den folgenden Tasten Funktionen des ssh-Clients aufrufen:

`.`	Beendet die Sitzung inkl. aller Tunnels.
`&`	beendet die Sitzung. Die Tunnels bleiben bestehen.
`C`	Zeigt einen Prompt (`ssh>`), an dem man mit den Befehlen `-L` und `-R` nachträglich Portforwarding einrichten kann (Details: siehe Teil 2).
`<Strg-Z>`	Suspended die ssh. Man landet in der Shell, aus der man ssh aufgerufen hatte. Mit `fg` geht's weiter.
`#`	zeigt alle Verbindungen an, die gerade über die aktuelle ssh tunneln.
`?`	Hilfemenü. Zeigt auch die hier nicht genannten, eher unwichtigen Befehle an.

Wer ein Keyboard-Layout mit deadkeys verwendet, drückt für ein Tildezeichen zweimal auf die Tilde-Taste.

Wer mehrere ssh-Sitzungen ineinander geschachtelt hat, erreicht den Escape-Modus der n-ten Shell (von außen gezählt) durch <Enter> und n-fachen Druck (bei deadkeys 2n-fach) auf die Tilde-Taste. Wem das zu kompliziert ist, der kann mit dem -e Parameter für jede ssh einen eigenen Escape-Charakter (z.B. <Strg-B>) bestimmen:

user@gateway:~ $ ssh -e ^B localhost

user@localhost:~ $ <Strg-B>.
Connection to localhost closed.

user@gateway:~ $

Interaktive Programme automatisch starten

ssh tp -t vim /etc/hosts

Aufruf einer entfernten Shell

Das funktioniert normalerweise in einen Terminal-Fenster so:

ssh user@server

user@server's password:
Last login: Sun Feb 12 07:38:50 2006 from client.local
Sun Microsystems Inc.   SunOS 5.9       Generic_112234-03       November 2002
bash-2.05$

Und schon befindet man sich auf einem anderen Rechner, in diesem Fall mit dem Betriebssystem Solaris.

Die Angabe eines Benutzernamens ist nur notwendig, wenn er sich von dem des lokalen Systems unterscheidet.

ssh server

Password:
Last login: Sun Feb 12 07:38:23 2011 from client.local

user@server:~$

Beenden der Sitzung

Strg + D

exit

Dateimanagement

Wenn man also ein Protokoll hat, das so sicher wie nach dem heutigen Stand der Technik möglich Daten durch einen verschlüsselten Kanal senden und empfangen kann, dann wäre es wohl Verschwendung, dieses Protokoll nur für interaktive Terminal-Sessions zu benutzen.

Sehr häufig möchte man bspw. einfach nur Dateien sicher von einem System zum anderen bewegen.

Dafür existieren verschiedene Programme der grafischen Benutzeroberfläche sowie gleich zwei Terminalbefehle nämlich scp und sftp.

Secure Copy mit scp

Das Kommandozeilenwerkzeug scp funktioniert in etwa so wie das normale Unix-Kommando cp, nur dass es über Systemgrenzen hinweg funktioniert.

Jedes Datei- oder Verzeichnisargument kann dabei optional, getrennt durch einen Doppelpunkt, durch einen vorangestellten Benutzer- bzw. Hostnamen ergänzt werden.

Dabei werden weggelassene Teile durch den aktuellen Benutzernamen, localhost bzw. das Homeverzeichnis (bzw. das aktuelle Verzeichnis) ergänzt, etwa so:

scp benutzerx@server1:datei1 datei2 benutzery@server2:

In diesem Beispiel wurde die datei1 aus dem Homeverzeichnis von benutzerx auf server1 und die datei2 aus dem aktuellen Verzeichnis des lokalen Hosts in das Homeverzeichnis von benutzery auf server2 kopiert.

Der Befehl scp versteht auch einige von cp bekannte Optionen, bspw. -r für das rekursive Kopieren ganzer Verzeichnisbäume. Bedauerlicherweise unterstützt scp aber nicht alle cp-Optionen, die für das exakte Klonen von Verzeichnissen, inkl. aller Dateirechte und symbolischen Verknüpfungen notwendig sind.

Für die exakte Replikation sollte deswegen entweder das Werkzeug rsync -e ssh genutzt werden (man beachte die Handbuchseite zu diesem Tool) oder der oben schon genutzte Trick mit tar und einer Pipe.

ssh root@server 'cd verzeichnis; tar czvf - verz./dateien' | tar xzf -

Entfernte Dateisysteme einbinden (sshfs)

Man kann das Dateisystem eines entfernten Rechners in sein eigenes Dateisystem mittels sshfs einbinden. Damit ist eine transparente Nutzung von Dateien auch über unsichere Netze hinweg möglich.

sshfs -p22 user@sshserver:/ /mnt

Bindet das root-Dateisystem von sshserver in /mnt ein. Bei langsamen Verbindungen kann es sinnvoll sein mit -C die Komprimierung der Datenübertragung einzuschalten.

Fehlersuche

sshfs -odebug,sshfs_debug,loglevel=debug -p22 user@sshserver:/ /mnt

Secure File Transfer mit sftp

Die andere Möglichkeit des Dateitransfers lautet sftp. Das funktioniert genau so wie der normale Kommandozeilen-FTP-Client:

sftp server

Connecting to server...
user@server's password:
sftp> pwd
Remote working directory: /export/home/user
sftp> ls
[...]
wichtige_datei.txt
[...]
sftp> get wichtige_datei.txt
Fetching /export/home/user/wichtige_datei.txt to wichtige_datei.txt

/export/home/user/wichtige_datei.txt
100%   62KB  62.2KB/s   00:00
sftp> quit
$ ls -la wichtige_datei.txt
-rw-r--r--  1 user user 63664 2006-03-10 17:26 wichtige_datei.txt

$

Befehle in der SFTP-Shell

`bye oder exit`	sftp verlassen
`cd`	Entferntes Verzeichnis wechseln
`chgrp grp path`	Entfernte Gruppenrechte ändern
`chmod mode path`	Entfernte Zugriffsrechte ändern
`chown own path`	Besitzrechte ändern
`df [-hi] [path]`	Entfernten freien Speicherplatz anzeigen
`exit oder quit`	sftp verlassen
`get remote [local]`	Datei herunterladen
`help oder ?`	Hilfe anzeigen
`lcd path`	Lokales Verzeichnis ändern
`lls [ls-options [path]]`	Lokales Verzeichnis auflisten
`lmkdir path`	Lokales Verzeichnis erstellen
`ln [-s] oldpath newpath`	Entfernten Link erstellen
`lpwd`	Lokales Arbeitsverzeichnis anzeigen
`ls [-1afhlnrSt] [path]`	Entferntes Verzeichnis auflisten
`lumask umask`	Lokale umask setzen
`mkdir path`	Entferntes Verzeichnis erstellen
`progress`	Schaltet Fortschrittsbalken an/ab
`put [-Ppr] local [remote]`	Datei hochladen
`pwd`	Entferntes Arbeitsverzeichnis anzeigen
`rename oldpath newpath`	Entfernte Datei umbenennen
`rm path`	Entfernte Datei löschen
`rmdir path`	Entferntes Verzeichnis löschen
`symlink oldpath newpath`	Entfernten Symlink erstellen
`version`	SFTP-Version anzeigen
`!command`	Führt 'command' in lokaler Shell aus
`!`	Öffnet eine lokale Shell (kann mit exit verlassen werden)

Weitere Informationen können der man-page zu sftp(1) entnommen werden.

Grafischer Dateimanagement

KDE

Zugriff per Dateimanager Dolphin

Die meisten User möchten keine grafischen Programme auf dem entfernten Rechner ausführen, sondern oftmals Daten vom Laptop zum Heimrechner transferieren.

KDE bringt dazu einen kio-slaves mit, der einen transparenten Zugriff aus allen KDE-Anwendungen zulässt.

Im Dateimanager Dolphin oder Konqueror kann folgende URL in der Adresszeile verwendet werden

fish://<benutzer>@<rechner>/pfad fish://user@localhost/home/dirkwagner

Daraufhin wird das Benutzerpasswort des Rechners abgefragt und man ist im Home-Verzeichnis des entfernten Rechners und kann nach belieben Daten von einem Rechner zum anderen verschieben und kopieren.

Zugriff aus anderen KDE-Anwendungen

Auch in Datei -> Öffnen-Dialogen kann in die Adresszeile eine fish:// - Adresse eingegeben werden

Netzwerkordner

Im Dateimanager Dolphin können über das Bookmark "Netzwerk" und den Assistenten "Netzwerkordner hinzufügen" neue ssh-basierte Netzwerkordner als feste Bookmarks erstellt werden.

Probleme mit Umlauten

Wenn der Zielrechner ebenfalls ein UTF-8 codiertes Dateisystem hat, sind u.U. die Umlaute falsch angezeigt. Um dies zu ändern, muss man im Konqueror eine fish-Adresse aufrufen und kann nun unter "Extras -> Entfernte Zeichencodierung wählen..." die entsprechende Codierung einstellen. Diese Einstellung ist fortan auch in Dolphin gültig. Diese Option einzustellen wird in KDE4 vermutlich in Dolphin selbst möglich sein.

Gnome

Der Gnome-Dateimanager Nautilus unterstützt das SSH-Protokoll von Haus aus. Dazu benutzt man eine Adresse der Form ssh://rechnername/pfad, um über SSH die Dateien auf dem angegebenen Rechner zu sehen.

Wenn man sich als ein anderer Benutzer anmelden möchte, verwendet man stattdessen eine Adresse der Form ssh://andererbenutzer@rechnername/pfad .

Diese Adressen funktionieren übrigens auch in einigen anderen Gnome-Anwendungen - z.B. bietet der Texteditor GEdit mittels "Datei -> Adresse öffnen" die Möglichkeit, über SSH direkt eine Datei auf einem anderen Rechner zu bearbeiten.

Weitere grafische Programme

Die meisten grafischen FTP-Clients (FTP) unterstützen auch sftp oder scp über das SSH-Protokoll. SSH-Verbindungen zu Datenverzeichnissen auf Fremdrechnern unterstützen auch Datensynchronisationsprogramme wie Unison und Backupprogramme wie Keep.

Windows (Cyberduck)

Cyberduck ist ein freier FTP-Client, ursprünglich für Mac OS X entwickelt. Am 8. März 2011 erschien Version 4.0, die auch unter Microsoft Windows lauffähig ist.

Cyberduck unterstützt Verbindungen per FTP, FTP/TLS, WebDAV und SSH File Transfer Protocol sowie einfaches Hoch- und Herunterladen mittels Drag and Drop.

Auch die Synchronisation von Dateien und Ordnern und das Öffnen und Bearbeiten von Dateien in einem Texteditor ist möglich.

Cyberduck enthält eine Lesezeichenfunktion und unterstützt den Netzwerkstandard Bonjour sowie den Passwortmanager Schlüsselbund. Bestehende Lesezeichen aus anderen FTP-Clients, etwa FileZilla, können importiert werden.

Soweit installiert, wird der Benutzer mittels Growl über den Verbindungsstatus und den Ladefortschritt informiert.

Cyberduck ist in einer großen Zahl von Sprachen verfügbar, darunter unter anderem Chinesisch, Deutsch, Englisch, Französisch, Japanisch und Spanisch.

Download: https://cyberduck.io

Entfernte Befehlsführung

Man kann auch einfach einen Befehl anhängen, der anstelle der Terminal-Session ausgeführt wird. Nach der Ausführung des Befehls wird die SSH-Session dann automatisch beendet:

ssh server 'cat /etc/issue'

Password:

Debian GNU/Linux 3.1

Oder etwas aufwendiger - eine Datensicherung machen ("backup"):

ssh root@server 'cd /etc; tar czvf - network/' | cat > etc_network_backup.tar.gz

Password:
network/
network/interfaces
network/if-post-down.d/
network/if-pre-up.d/
network/if-up.d/
network/if-down.d/
network/options
network/interfaces.pre-etherconf
network/interfaces.1
network/run
$ ll etc_network_backup.tar.gz

-rw-r--r-- 1 user user 10240 2006-03-07 02:17 etc_network_backup.tar.gz

Bei einer langsamen Verbindung empfiehlt sich zusätzlich die Benutzung der Option -C (großes C), die zusätzlich zur Verschlüsselung eine transparente Kompression der übertragenen Daten aktiviert.

Bei einer schnellen Verbindung wird die Kompression aber vermutlich bremsen.

Woher weiß man nun aber, dass man tatsächlich mit dem richtigen Rechner verbunden ist, und nicht ein Angreifer die Verbindung umgeleitet hat?

Dafür gibt es den Host-Schlüssel, der jeden SSH-Server eindeutig identifiziert.

Greift man zum ersten Mal auf einen bestimmten Server zu, kennt man diesen Schlüssel natürlich noch nicht. (Außer man hat ihn sich auf anderen Wegen im Voraus besorgt.)

ssh server

The authenticity of host 'server (192.168.1.5)' can't be established.
RSA key fingerprint is b5:0e:ec:b7:16:06:e6:24:a6:39:18:58:4e:ec:3b:d1.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'server' (RSA) to the list of known hosts.

Password:

Wenn gerade in diesem Moment jemand die Verbindung gekapert hat, hat man natürlich Pech, außer man kann den Administrator des Servers nach dem richtigen Fingerprint des Host-Schlüssels fragen.

Fingerprint

Den RSA-Fingerprint eines Servers kann man mit dem Systemprogramm ssh-keygen erfahren:

der Befehl ssh-keygen -f /etc/ssh/ssh_host_rsa_key.pub -l gibt den Fingerprint und einige weitere Informationen aus, z.B.

1024 b5:0e:ec:b7:16:06:e6:24:a6:39:18:58:4e:ec:3b:d1 /etc/ssh/ssh_host_rsa_key.pub

Wenn man auf Nummer-sicher gehen möchte, lässt man sich vom Administrator des Servers diese Ausgabe mitgeben (evtl. ausdrucken) und kann dann beim ersten Verbindungsversuch überprüfen, ob man sich tatsächlich zum richtigen SSH-Server verbunden hat und nicht zu einem dazwischengeschalteten Angreifer.

Bei allen weiteren Kontakten stellt das ssh-Programm jedoch von nun an über asymmetrische Kryptografie sicher, dass der Server auch über den richtigen privaten Schlüssel verfügt, der zum öffentlichen, in der Datei ~/.ssh/known_hosts abgelegten passt, und verweigert im Zweifelsfall den Verbindungsaufbau.

Sollte sich dieser Schlüssel einmal aus legitimen Gründen geändert haben, bspw. weil das System neu aufgesetzt wurde, muss man den entsprechenden veralteten Schlüssel erstmal auf dem Client mit dem Befehl

ssh-keygen -R hostname

aus der known_hosts-Datei entfernen.

Sollte die Verbindung nicht mehr reagieren, z.B. wenn der SSH-Server heruntergefahren wurde, lässt sich der ssh-Client mit der Eingabe von "~." (Nacheinander) beenden.

Komprimierung

Wenn sich das Netz als Engpass herausstellt, kann man die Kommunikation zwischen ssh und sshd komprimieren. Das benötigt auf beiden Seitem etwas mehr Rechenzeit, spart jedoch etwa 50% der Netz-Pakete ein.

Um die Komprimierung zu aktivieren:* ssh -C ...

ssh -o Compression=yes ...
Compression yes in ~/.ssh/config oder /etc/ssh/ssh_configeinbauen.

Zusätzlich sollte auf dem Server in /etc/ssh/sshd_config die Zeile Compression yes stehen.

In Verbindung mit Portforwarding lassen sich langsame Netzabschnitte (z.B. DSL-Strecken) für den Client völlig unsichtbar beschleunigen:

X11-forwarding

Unter Unix ist es üblich, Anwendungen ("X-Clients") auf anderen Rechnern aufzurufen und am eigenen Bildschirm ("X-Server") zu bedienen. Es gibt zwei Methoden des Verbindungsaufbaus:

ohne X11-Tunne

xhost gate

gate being added to access control list
ssh gate
user@gateway: $ export DISPLAY=localhost:0
user@gateway: $ netscape &

[1] 17101

mit X11-Tunnel

export DISPLAY=:0

ssh -X gate
user@gateway: $ echo $DISPLAY
localhost:10.0
user@gateway: $ netscape &

[1] 17153

Hierzu muß auf gate die libX.so und xauth installiert sein und X11Forwarding yes in /etc/ssh/sshd_config stehen.

Alternativ zu dem -X-Parameter kann man dem ssh den Parameter -o ForwardX11=yes übergeben oder in der ~/.ssh/config-Datei ForwardX11 yes eintragen.Bewertung

Kriterium	ohne X11-Tunnel	mit X11-Tunnel
Verschlüsselung	- Die Kommunikation läuft unverschlüsselt über's Netz. Ein anderer Netzteilnehmer könnte z.B. alle Tastendrücke und eingegebenen Passwörter mitschneiden.	+ Die Kommunikation erfolgt verschlüsselt. Der Zeitverlust für die Verschlüsselung wird durch die Kompression mehr als wett gemacht.
X11-security	- Der X-Server muß von aussen per tcp-port 6000 erreichbar sein, was weitere Gefahren bietet, z.B. unbefugtes Bildschirmauslesen	+ Der X-Server darf mit `-nolisten tcp` aufgerufen sein, was vor unberechtigten Zugriffen anderer Netzteilnehmer schützt.
Firewall/NAT	- Diese Methode funktioniert nicht mehr, sobald eine Firewall dazwischen steht.	+ Kein Problem mit Firewalls, solange sie ssh durchlassen.

Die Verwendung von X11-Tunnels über ssh bringt also klare Vorteile.

X-Forwarding

-X schaltet das X-Forwarding ein. Mit der Option -X lassen sich also alle grafischen Programme auf dem entfernten Rechner starten und auf dem Clienten wiedergeben.

Mit dem X11-Forwarding kann man auch grafische Programme, die man über SSH auf einem anderen Rechner startet, auf dem eigenen Display anzeigen lassen, und zwar unabhängig davon, welches Betriebssystem auf dem entfernten Rechner läuft. (Siehe Bild.)

Das Programm muss sich nur an den X11-Standard halten, was leider die meisten Windows- und Mac-Programme ausschließt.

Um das X11-Forwarding zu aktivieren, muss man dem ssh-Befehl die Option -X (groß X) hinzufügen, die dem Programm eingeschränkte Rechte am eigenen Display einräumt.

Datei:Grafik27.png

Für den Fall dass es zu einem Programmabbruch kommt, weil diese eingeschränkten Rechte nicht ausreichen, existiert noch die Option -Y, die dem Programm volle Rechte gewährt.

Diese sollte man jedoch nicht verwenden, wenn man dem Administrator des entfernten Rechners nicht vertraut, denn sie öffnet einen Tunnel, der auch in der umgekehrten Richtung für einen Angriff auf das eigene Display genutzt werden könnte. Vorsicht: mit der Option -x (klein x) wird X11-Forwarding deaktiviert.

Die ausgeführten Programme sollten nun auf dem lokalen Bildschirm angezeigt werden.

Serverkonfiguration

Auf dem Server muss das Paket xauth installiert sein. Außerdem muss dem SSH-Daemon des Servers mitgeteilt werden, dass X-Forwarding verwendet wird. Das wird über die Konfigurationsdatei erledigt.

/etc/ssh/sshd_config

Dort wird folgende Option gesetzt. Danach ist ein Neustart des Daemons erforderlich.

X11Forwarding yes

Zusätzlich müssen in der Client-Konfigurationsdatei /etc/ssh/ssh_config folgende Einträge einkommentiert werden.

ForwardX11 yes

ForwardX11Trusted yes

Gesamter entfernter Desktop

Eine weitere Möglichkeit besteht darin, sich den gesamten entfernten Desktop grafisch in einem Fenster des Clienten zu holen. Das "Zauberwort" für diese Möglichkeit heißt "Xnest"

xnest befindet sich im Paket xorg-x11-server-extra, dass es mit Yast zu installieren gilt sofern es nicht schon auf dem Rechner ist. Für diese Vorgehensweise ist es erforderlich, dass der entfernte Rechner hochgefahren ist aber keine KDE-Anmeldung erfolgt ist.

Man sollte also auf dem Remote-Rechner den KDM-Anmeldungsmanager sehen. Logge Dich per ssh ein:

ssh -XC <user>@<remote-rechner>

Die hinzugefügte Option "C" dient dazu, dass die Daten komprimiert übertragen werden, weil beim Remote-Betrieb von X-Anwendungen sehr viel mehr Daten übertragen werden müssen. Dann gibt man ein:

Xnest :1 &

um Xnest eine X-Session starten zu lassen.

Man sieht nun ein leeres Fenster auf seinem Heimrechner. Gib dann ein:

export DISPLAY=localhost:1

Mit 1 legst Du eine Displaynummer fest; meist ist die 0 schon vergeben. Der Befehl soll im Hintergrund gestartet werden (&), weil noch weitere Eingaben folgen.

"export" legt fest, das alle folgenden grafischen Ausgaben dem Display 1 übergeben werden. Xnest lenkt sie auf das bisher leere Fenster auf Deinem Heimrechner um. Mit

startkde &

startet man auf dem entfernten Rechner KDE sofern es dort installiert ist. Ansonsten icewm-session & oder einen Startbefehl für einen anderen Windowmanager der dort installiert ist.

X11 Forwarding

Nachdem ssh häufig in einer X11-Umgebung eingesetzt wird, in der graphische Programme auf einem Server aufgerufen werden, aber auf dem Bildschirm (genauer: auf dem X-Server) einer Workstation dargestellt werden sollen, hat ssh einen eingebauten Mechanismus, der eine sichere verschlüsselte Übertragung für solche Anwendungen bietet.

X11-Anwendungen erfahren aus der Umgebungsvariable DISPLAY, auf welchem Display, also auf welchem X-Server sie sich darstellen sollen. Außerdem arbeiten diese Anwendungen mit einem sogenannten Cookie, das ihre Berechtigung festlegt, auf dem Bildschirm eines anderen Rechners etwas darzustellen. All diese Arbeiten nimmt uns ssh komplett ab.

Normalerweise müssten wir auf dem Client folgenden Befehl eingeben, um das Programm xclock des Servers auf unserem Bildschirm zu sehen:

 ssh SERVER /usr/X11R6/bin/xclock -display CLIENT:0.0

Diese Übertragung wäre - ganz nebenbei - auch nicht verschlüsselt, denn wir haben ja nur den Befehl verschlüsselt übertragen. Der Weg zurück, vom Server auf unseren Bildschirm, würde ja vom X11-Protokoll übertragen und wäre somit völlig unverschlüsselt. (Auch wenn die Übertragung einer Uhr in der Regel nicht so geheim sein wird...)

Wenn wir aber auf dem Server jetzt den sshd so konfigurieren, dass er in seiner Konfigurationsdatei /etc/ssh/sshd_config den Eintrag

 X11Forwarding yes

aufweist und wir gleichzeitig auch unserem Client in der Datei /etc/ssh/ssh_config die Anweisung

 ForwardX11 yes

verpassen, dann funktioniert obiger Befehl jetzt viel einfacher. Wir schreiben auf dem Client nur noch

 ssh SERVER /usr/X11R6/bin/xclock

und schon ist die Uhr auf unserem Bildschirm. Die Vorteile sind jetzt im Einzelnen:* Verschlüsselte Übertragung der Daten (ssh-Tunnel, der das X11-Protokoll transportiert)

Keine Angabe von DISPLAY, denn der ssh-Server hat automatisch einen "virtuellen" X-Server gestartet, der sozusagen das eine Ende des Tunnels darstellt. Die Umgebungsvariable DISPLAY auf dem Server ist jetzt standardmäßig auf localhost:10 gesetzt.
Keine Einstellungen für Cookies nötig. SSH stellt automatisch "gefälschte" Cookies zur Verfügung und erledigt andere Fragen der Authorisierung.

Wichtig ist, dass nicht vergessen werden darf, dass auch auf der Client-Seite von SSH die Einstellung ForwardX11 yes in der Datei /etc/ssh/ssh_config vorgenommen werden muß. Nicht verwechseln, es handelt sich nicht um die Datei der Servereinstellung (sshd_config) sondern um die Clientkonfiguration (ssh_config)!

Public key authentication

Wem die Authentifizierung über Passwörter trotz der Verschlüsselung zu unsicher ist, - immerhin könnte das Passwort ja erraten werden - der benutzt am besten das Public-Key-Verfahren.

Hierbei wird asymmetrische Verschlüsselung genutzt, um den Benutzer zu authentifizieren.

Datei:Grafik11.png

Der (oder die) öffentliche(n) Schlüssel des Benutzers befindet sich dabei in der Datei ~/.ssh/authorized_keys des Zielsystems, der private Schlüssel in einer Datei (meist id_rsa) im Verzeichnis ~/.ssh auf dem lokalen System, wo er zusätzlich von einer "pass phrase" geschützt wird.

Wenn man sich nun mit der Public-Key-Methode auf einem SSH-Server anmelden möchte, so schickt der Server dem Klienten eine zufällig generierte Challenge.

Der Klient verschlüsselt diesen Datenblock mit seinem privaten Schlüssel, (wofür nötigenfalls die Passphrase abgefragt wird,) und wenn der Server diesen Chiffre mit dem zugehörigen öffentlichen Schlüssel wieder entschlüsseln kann, ist die Identität des Benutzers bestätigt.

Die Publickey-Authentifizierung beruht auf dem Prinzip asymmetrischer Verschlüsselung: Der Client und der Server besitzen einen Schlüssel und können damit Nachrichten so verschlüsseln, dass nur der andere sie entschlüsseln kann.

Wenn einer nun seinen Schlüssel geheim hält ("private key"), kann der andere von der Authentizität seines Gegenüber ausgehen, sobald er eine Nachricht mit einem seiner eigenen Schlüssel ("public key") entschlüsseln kann.

Datei:Grafik74.png

Hierzu stehen drei verschiedene Algorithmen zur Verfügung

Algorithmus	Parameter für `ssh-keygen`	Dateinamen	Publickey beginnt mit
RSAfür SSH ab Version 2	`-t rsa`	`~/.ssh/id_rsa[.pub]`	`ssh-rsa`
RSAfür SSH Version 1	`-t rsa1`	`~/.ssh/identity[.pub]`	`1024 35` o.ä, (bits exponent)
DSA	`-t dsa`	`~/.ssh/id_dsa[.pub]`	`ssh-dss`

Auf die Spezialitäten der einzelnen Algorithmen gehe ich hier nicht weiter ein, als dass DSA die meiste Rechenlast erzeugt und RSA1 besonders leicht verwundbar ist. In vielen Fällen bietet RSA einen guten Kompromiss.

Jeder Publickey (z.B. ~/.ssh/id_rsa.pub) setzt sich wie folgt zusammen:* Der Key-Type (z.B. ssh-rsa, siehe Tabelle oben)

Ein Leerzeichen
Der Modulus (das ist die lange Folge von Buchstaben/Ziffern)
optional: Ein Leerzeichen, gefolgt von einem Kommentar

Er wird mittels uuencode auf 6 bit Ascii codiert. Damit sieht er wie eine lange Text-Zeile aus und lässt sich leicht im Text einer Mail verschicken:

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAxtWFO8XbyT6+IlBAWYyOb

/VWraJ7iymKVsb0TNmieBSzF6fgustkT0nX3udbSqTqiEC/wXFKqeyl27
bkd+rEcFba+s+wgv9MKRaiV0kOFVQrAvwrKnS1QI6YZWZIhSP7KS5QE0H

Rra+gy/47vGwHUn0RxksGOQ6YsKP5lNN8H3E= user@localhost

Schlüsselgenerierung

Grundsätzlich werden die notwendigen Schlüsselpaare mit dem Programm ssh-keygen erstellt. Dieses Programm erstellt sowohl die Schlüsselpaare der User für die oben genannte Authentifizierung, als auch die Hostschlüssel, die zur Verschlüsselung des Datentransfers selbst verwendet werden.

Generierung der User-Schlüsselpaare

Jeder User kann seine ssh-Schlüssel selbst anlegen. Das Programm ssh-keygen erwartet als Parameter mindestens die Angabe, um welchen Typ von Schlüssel es sich hierbei handeln soll. Folgende Typen stehen zur Verfügung:

-t rsa1

Generiert wird ein RSA-Schlüsselpaar, das für die Protokollversion 1 von ssh geeignet ist. Der Private-Key wird in die Datei $HOME/.ssh/identity geschrieben, der Public-Key liegt in $HOME/.ssh/identity.pub

-t rsa

Hiermit wird ein RSA-Schlüsselpaar für die Protokollversion 2 des SSH-Protokolls erzeugt. Der Private-Key wird nach $HOME/.ssh/id_rsa geschrieben, der Public-Key liegt in $HOME/.ssh/id_rsa.pub

-t dsa

Hiermit wird ein DSA-Schlüsselpaar für die Protokollversion 2 des SSH-Protokolls erzeugt. Der Private-Key wird nach $HOME/.ssh/id_dsa geschrieben, der Public-Key liegt in $HOME/.ssh/id_dsa.pub

Der Befehl

 ssh-keygen -t rsa

erzeugt also das Schlüsselpaar vom Typ RSA für die Version 2 des SSH-Protokolls.

Beim Anlegen der Schlüsselpaare wird jeweils nach einem Passwort gefragt, das auch leer gelassen werden kann.

Der Inhalt der Datei, die den Public-Key enthält, kann jetzt an die Datei $HOME/.ssh/authorized_keys auf dem Server angehängt werden. Das kann einfach mit dem cat-Befehl erfolgen, entweder über den Transport via Datenträger oder eleganter auch über ssh, indem ein Befehl in der Art

 cat PublicKeyDatei | ssh Servername "cat >> .ssh/authorized_keys"

eingegeben wird. Zu beachten sind die Anführungszeichen, damit die Umleitungssymbole nicht von der lokalen Shell interpretiert werden, sondern von der des Servers. Das erste Mal, wenn dieser Befehl ausgeführt wird, muss noch ein Passwort eingegeben werden, da ja die Authentifizierung über die Schlüssel noch nicht funktioniert, schon direkt nach dem ersten Befehl sollte aber ein ssh-Befehl kein Passwort mehr verlangen.

Generierung eines Hostschlüsselpaares

Die Generierung des Hostschlüsselpaares läuft im Pronzip genauso ab, wie die der Userschlüssel. Allerdings sind hier ein paar Besonderheiten zu beachten: * Der Hostschlüssel darf kein Passwort benutzen, die Frage nach dem Passwort muss also leer gelassen werden.

Der Hostschlüssel wird in der Regel im Verzeichnis /etc/ssh gespeichert, ältere Versionen erwarten ihn in /etc selbst.
Der Namen der Hostschlüsseldatei ist in der Regel
ssh_host_key und ssh_host_key.pub
Die RSA1 Schlüssel für Protokollversion 1
ssh_host_rsa_key und ssh_host_rsa_key.pub
Die RSA Schlüssel für Protokollversion 2
ssh_host_dsa_key und ssh_host_dsa_key.pub
Die DSA Schlüssel für Protokollversion 2
Welche Namen tatsächlich verwendet werden, wird in der Serverkonfigurationsdatei sshd_config eingestellt (siehe unten).

Im Normalfall wird das Hostschlüsselpaar bei der Installation von SSH automatisch durch ein Script erzeugt, die entsprechenden Befehle ausführt:

 ssh-keygen -f /etc/ssh/ssh_host_key -N "" -t rsa1
 ssh-keygen -f /etc/ssh/ssh_host_rsa_key -N "" -t rsa
 ssh-keygen -f /etc/ssh/ssh_host_dsa_key -N "" -t dsa

Das -N "" bedeutet, dass das neue Passwort leer ist, mit -f Dateiname wird der Name der Datei angegeben, in die der Schlüssel abgelegt werden soll.

Falls es notwendig sein sollte, ein neues Schlüsselpaar von Hand zu erzeugen, können diese Befehle vom Systemverwalter jederzeit auch manuell eingegeben werden.

Schlüsselpaar erzeugen (ssh-keygen)

Damit man dieses Verfahren überhaupt verwenden kann, muss man sich zunächst mit Hilfe des Kommandozeilenprogramms ssh-keygen ein entsprechendes Schlüsselpaar erzeugen:

ssh-keygen -t rsa

Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
24:55:ee:67:83:72:82:55:5f:b9:b4:09:2a:fa:56:a1 user@client.local
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|                 |
|                 |
|         +    .  |
|        S    E   |
|         .  + +  |
|          .o . o.|
|         o.oo. oo|
|          ==o.BO+|
+-----------------+
$

Der voreingestellte Dateiname (id_rsa) kann einfach mit der Taste ⏎ bestätigt werden, außer man möchte sich ein weiteres Schlüsselpaar erzeugen.

Von der Benutzung einer leeren Passphrase ist jedoch abzuraten, weil sonst jeder, der evtl. in den Besitz dieser Datei kommt, sofortigen Zugriff auf alle zugehörigen Systeme erhält.

Nun muss noch der öffentliche Schlüssel, zu erkennen an der Endung .pub (id_rsa.pub), auf dem Zielsystem deponiert werden.

Dazu dient das Programm ssh-copy-id.

Zu diesem Zeitpunkt muss die Authentifizierung per Passwort noch erlaubt sein (PasswordAuthentication yes):

ssh-copy-id -i ~/.ssh/id_rsa.pub user@server

Password:
Now try logging into the machine, with "ssh 'user@server'", and check in:
  .ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.

Sollte der Port nicht gerade 22 sein, dann muss der Befehl wie folgt aussehen:

ssh-copy-id '-p 12345 -i ~/.ssh/id_rsa.pub user@server'

Sollte ssh-copy-id nicht funktionieren kann man den öffentlichen Schlüssel auch anders auf das Zielsystem kopieren und in die Datei ~/.ssh/authorized_keys einfügen.

Wenn ein vom Standard abweichender Dateiname für den Key gewählt wurde, muss er mittels der Kommandozeilenoption -i ~/pfad/dateiname gesondert angegeben werden.

Für die dauerhafte Nutzung empfiehlt sich ein Eintrag in der ~/.ssh/config: mittels IdentityFile-Parameter.

Anschließend kann man sich ohne Passwort anmelden:

ssh user@server

Enter passphrase for key '/home/user/.ssh/id_rsa':
Linux server.local 2.6.12-10-686 #1 Mon Feb 13 12:18:37 UTC 2006 i686 GNU/Linux
The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.
Last login: Fri Mar  3 03:51:14 2006
user@server:~$

Hinweis

Falls es noch nicht klappt kann es daran liegen, dass die Rechte beim Server nicht korrekt sind.

sshd achtet darauf, dass das Homeverzeichnis, das dem Login-Namen entspricht (also die "Mappe" selbst), das .ssh-Verzeichnis und authorized_keys nur für den Eigentümer Schreibrechte hat.

Hintergrund ist wohl, die Gefahr zu verringern, dass authorized_keys manipuliert wird und man keinen Zugriff mehr hat, wenn der Passwortzugang (s.u.) gesperrt ist.

Wer also bei bestimmten Accounts beim Server auch einer Gruppe Schreibrechte gewähren will, muss evtl. die Optionen in /etc/ssh/sshd.conf prüfen.

Jetzt ist es aber immer noch möglich sich mit dem Passwort anzumelden.

Damit man sich nur noch mit dem Key anmelden kann, sollte man noch die Optionen

PasswordAuthentication no

UsePAM no

in der Datei /etc/ssh/sshd_config setzen und mit einem

# /etc/init.d/ssh reload

die Konfiguration neu einlesen lassen.

Alternativ: Auf der Serverseite eingeben passwd -l <user>. Damit sind Passwörter nur für ausgewählte Accounts sperrbar.

Und nochmals der Hinweis: Sollte sich dieser Schlüssel einmal aus legitimen Gründen geändert haben, bspw. weil das System neu aufgesetzt wurde, muss man den entsprechenden veralteten Schlüssel erstmal auf dem Client mit dem Befehl

ssh-keygen -R hostname

aus der known_hosts-Datei entfernen.

Jeder Authentifikationsalgorithmus benötigt ein eigenes Schlüsselpaar, das man mit dem Befehl ssh-keygen erstellen kann. Mit dem -t-Parameter bestimmt man den Algorithmus, zu dem man das Schlüsselpaar erzeugen möchte.

ssh-keygen -t rsa

Generating public/private rsa key pair.
Enter file in which to save the key (/export/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /export/home/user/.ssh/id_rsa.
Your public key has been saved in /export/home/user/.ssh/id_rsa.pub.
The key fingerprint is:

7c:02:29:1c:d4:8a:90:ad:f2:b0:65:9e:71:92:ef:0f user@localhost

Der Fingerprint ist eine gemeinsame Eigenschaft von Private- und Publickey und ermöglicht es später festzustellen, welcher Privatekey zu einem Publickey passt:

ssh-keygen -l -f .ssh/id_rsa 1024 5a:b6:c4:50:ce:ec:18:78:e9:b2:e7:5b:04:c2:e4:c7 .ssh/id_rsa.pub

Man kann die Passphrase des Privatekey nachträglich ändern:

ssh-keygen -p -f ~/.ssh/id_rsa

Enter old passphrase:
Key has comment '/export/home/user/.ssh/id_rsa'
Enter new passphrase (empty for no passphrase):
Enter same passphrase again:

Your identification has been saved with the new passphrase.

Wer seinen Publickey verlegt hat, kann sich aus dem Privatekey einen neuen Publickey erzeugen:

ssh-keygen -y -f ~/.ssh/id_rsa ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA5+UaqG/zI...

Aber nicht vergessen, es gibt keine Möglichkeit, einen verlorenen Privatekey aus dem Publickey zu erstellen.

Hostkeys verwenden

known_hosts

Wer beim Aufbau einer ssh-Verbindung ganz sicher gehen möchte, dass der erreichte Server auch der richtige ist, gibt die Option -o StrictHostkeyChecking=yes an oder trägt in der ~/.ssh/config für die betreffenden Hosts StrictHostkeyChecking yes ein.

Der Client bricht dann die Verbindung ab, wenn der geheime Hostkey des Servers nicht zu dem Public-Key passt, der bereits auf dem Client in ~/.ssh/known_hosts oder /etc/ssh/ssh_known_hosts abgelegt worden ist:

ssh -o StrictHostkeyChecking=yes gate

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
5c:6e:b2:99:3d:44:03:32:fb:e8:c1:ca:4f:cb:9e:8f.
Please contact your system administrator.
Add correct host key in /export/home/user/.ssh/known_hosts to get rid of this message.
Offending key in /export/home/user/.ssh/known_hosts:45
RSA host key for gate has changed and you have requested strict checking.

Host key verification failed.

oder, wenn dieser Host noch gar nicht in der known_hosts eingetragen ist:

ssh -o StrictHostkeyChecking=yes gate

No RSA host key is known for gate and you have requested strict checking.

Host key verification failed.

Wer nicht alle Hostkeys manuell in die known_hosts-Datei aufnehmen möchte, sondern nur bei Veränderungen gewarnt werden möchte, sollte StrictHostkeyChecking auf ask setzen:

ssh -o StrictHostkeyChecking=ask gate

The authenticity of host 'gate (192.168.42.1)' can't be established.
RSA key fingerprint is 5c:6e:b2:99:3d:44:03:32:fb:e8:c1:ca:4f:cb:9e:8f.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'gate,192.168.42.1' (RSA) to the list of known hosts.

user@gateway $

Die Zeilen der known_hosts haben folgendes Format:# Liste von Hostnamen oder IP-Adressen eines Servers, durch Komma getrennt. Wildcards *? und Negation ! sind erlaubt

Ein Leerzeichen
Der Publickey dieses Servers (ohne Kommentar)
optional: ein Leerzeichen, gefolgt von einem Kommentar

Die Hostkeys befinden sich auf dem Server an folgenden Stellen:* /etc/ssh/ssh_host_dsa_key[.pub] (DSA-Format)

/etc/ssh/ssh_host_rsa_key[.pub] (RSA-Format f. SSH version 2+)
/etc/ssh/ssh_host_key[.pub] (im RSA-Format f. SSH version 1)

Man kann diese Schlüssel mit ssh-keygen herstellen. Dabei ist zu beachten. dass man dem Privatekey eine leere Passphrase gibt. Bei vielen Distributionen wird diese Aufgabe beim Einspielen des sshd-Pakets automatisch erledigt.

Ändert sich der Hostkey eines Servers (z.B. nach einem SSH Versions-Update), muß man auf dem Client die entsprechenden Zeile aus der known_hosts entfernen oder aktualisieren.

known_hosts verwalten

Host 192.168.0.197 aus known_hosts entfernen

user@localhost:~> ssh-keygen -R 192.168.0.197 -f /home/dirkwagner/.ssh/known_hosts

# Host 192.168.0.197 found: line 39 type ECDSA
/home/dirkwagner/.ssh/known_hosts updated.

Original contents retained as /home/dirkwagner/.ssh/known_hosts.old

ssh-keyscan

Wer viele Hostkeys in eine known_hosts-Datei eintragen muss, kann diese mit ssh-keyscan von jedem Client aus abfragen und die Ausgabe direkt an die known_hosts anhängen.

Da Fehler beim Auslesen des Hostkeys auf Netz- oder Serverprobleme hinweisen, kann man ssh-keyscan zur schnellen Diagnose solcher Probleme einsetzen: Wenn es den Hostkey nicht anzeigt, besteht ein Problem.

ssh-keyscan localhost

# localhost SSH-2.0-OpenSSH_6.2
localhost ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBO2J+IntEBJAdMWRid7ngHLehy1os8pOD/NCXnFfDCzA6nrCm1zXRS5Q5IYpe0Vd/fE5aIFi+ogvUGcB5XbEZQE=
# localhost SSH-2.0-OpenSSH_6.2

localhost ssh‑rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCngPhrnc6QbxUwO8OQPdK9TIbPY2NBHimgs4WPDSfsf8FqHCrjyMyjHdlbeYTJFa3WqV/yEnSInReGKFzP7EvoM4zHbwWRb+0AMkB5+1c1qvl7uq5P9get7PMRmFXqq/aXAfdRBWyhlLPPCEauHt6IB5O/mvC4U4Rm/Ke4kurQLjcPv85dFFLQzbgVQiea5WUohfng12qHC1pjKuHVtpbhHIA5/JJdTFey/z7/wycS3W1RaNgiry/mc+fIxCzroiL37I4gqegzUBN1JmRkLXARmRUaJgnFKFQR7XNBVV6J68CnqWycwQn4Nj2e4QABu7UpJ07dFSQhzc1k968OM2G

Create a Known Hosts File with ssh-keyscan

As the starting point for the ssh-keyscan tool, create an ASCII file containing all the hosts from which you will create the known hosts file, e.g. sshhosts.
Each line of this file states the name of a host (alias name or TCP/IP address) and must be terminated with a carriage return line feed (Shift + Enter), e.g.
linuxos2.hobsoft.com

sunultra.hobsoft.com

Execute ssh-keyscan with the following parameters to generate the file sshknownhost:
ssh-keyscan -t rsa,dsa -f /home/user/sshhosts >/home/user/sshknownhosts
The parameter -t rsa,dsa defines the host’s key type as either rsa or dsa.
The parameter -f /home/user/sshhosts states the path of the source file sshhosts, from which the host names are read.
The parameter >/home/user/sshknownhosts states the output path of the known host file to be created (sshknownhosts).

Known Host format

Each line of the created file contains the following information:

hostname sshparameter hostpublickey* hostname: States the host’s name.

Shhparameter: States the key type used by the host.
Hostpublickey: States the public key of the corresponding host; this is BASE64-coded.

Weitere Informationenssh-keyscan(1)

Identity-Keys verwenden

authorized_keys

Alternativ zu der Eingabe eines Passwortes kann man ein Schlüsselpaar zur Authentifikation verwenden, wobei der Privatekey wiederum mit einer Passphrase geschützt sein kann.

Vorteile der Publickey- gegenüber Passwort-Authentifikation:* Die Schlüssel sind mit Brute-Force wesentlich aufwendiger zu erraten als Passwörter

Wer meinen Publickey hat, kann mich leicht auf seinen Server einladen.
Ich muß mir für alle Zugänge nur eine einzige Passphrase merken, die ich jederzeit mit einem Kommando ändern kann
Auf dem Server liegt nur mein Public-Key, mit dem allein noch niemand auf andere Systeme zugreifen kann. Es besteht insbesondere nicht das Risiko, dass jemand mit Brute-Force auf /etc/shadow mein Passwort ertestet.
Wenn mehrere User auf den selben Account zugreifen, kann jeder seine eigene Passphrase verwenden.

Die Verwendung von Public-keys ist einfach: Zunächst erstellt man auf dem Client beispielsweise mit ssh-keygen -t rsa ein Schlüsselpaar, wie oben beschrieben. Den Public-key kopiert man dann als eine lange Zeile in die Datei ~/.ssh/authorized_keys auf dem Server.

Am Zeilenanfang der Einträge in der ~/.ssh/authorized_keys kann man zusätzlich dem sshd jeweils mitteilen, von welchen Rechnern man sich mit diesem Schlüssel einloggen darf und welche Besonderheiten (Environmentvariablen, Shell, ssh-Optionen) dabei gelten. Die genaue Syntax der Zeilen lautet:# Optional eine Liste von Optionen, durch Komma getrennt, gefolgt von einem Leerzeichen. Beispiele:

1. environment="SSHKEY=user"(ab openssh ≥3.5p1 muß man hierzu PermitUserEnvironment=yes in /etc/ssh/sshd_config setzen.)
2. command="./menu.pl"
3. from="*.user.de,egal.our-isp.org"
4. no-port-forwarding
5. no-X11-forwarding
6. permitopen="host:port"
7. no-agent-forwarding
8. no-pty
Der Public-Key (siehe *.pub-Datei) ohne Kommentar
optional: Ein Leerzeichen und ein Kommentar

Wenn dann noch auf dem Server in der /etc/ssh/sshd_config die Option PasswordAuthentication No eingestellt ist, kann man sich nur noch mit dem Schlüssel anmelden, was ziemlich gute Sicherheit gegen Brute-ForceAngriffe bietet.

Weitere Informationensshd(8)

ssh-copy-id

Wer öfters seinen Publickey auf Servern platzieren muß, wird gerne auf ein kleines Shellscript namens ssh-copy-id zurückgreifen, das über eine ssh-pipe einfach den Publickey an die authorized_keys auf dem Server anhängt.

./ssh-copy-id user@localhost

user@localhost's password:
Now try logging into the machine,
with "ssh 'user@localhost'", and check in:
  .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

Weitere Informationenssh-copy-id(1)

Login ohne Passwortabfrage

Leere Passphrase

Wenn die Passphrase eines Privatekey leer und der Publickey in der ~/.ssh/authorized_keys auf dem Server enthalten ist, lässt sich ssh wunderbar in Scripte einbauen. Dann sollte man jedoch darauf achten, dass kein Unbefugter Zugriff auf die Privatekey-Datei hat, insbesondere wenn dieser auf einem NFS- oder CIFS-Fileserver liegt.

SSH ohne Passwort

Die SSH ist Ersatz für rsh, rlogin, rcp, ... und bietet * mehr Sicherheit bei der Authentisierung/Authorisierung

verschlüsselte Sessions
einfachen transparenten Zugriff auf fremde Rechner
ad-hoc VPN (über tun-Devices)

ssh/slogin/scp kann als Ersatz für rsh/rlogin/rcp genutzt werden. Bei vorhandener .rhosts auf dem Zielrechner kann sie sich wie die r* commands verhalten.

Sollten dann doch Passwörter übertragen werden, sind diese verschlüsselt. Bei der Nutzung von .rhosts ist die Authentisierung nicht sonderlich sicher, das Paar aus `host' und `user' ist doch ziemlich leicht durch Fremde zu nachzuempfinden.

Sie beruhen ausschliesslich auf Vertrauen gegenüber dem DNS und dem fremden Host. Die ssh nutzt host- und userspezifische Keys zur Authentisierung. Spoofing wird damit schwerer.

Für die Nutzung der ssh als Ersatz für telnet und rlogin sind folgende Dinge zu tun:

ssh-keygen -t rsa1 # für Protokol 1 (!! nicht mehr verwenden !!)

ssh-keygen -t rsa       # für Protokol 2

ssh-keygen -t dsa # für Protokol 2

Damit werden eigene Schlüsselpaare erzeugt. (Für Protokol 2 gibt es RSA und DSA Keys, eigentlich reicht normalerweise einer von beiden.) Die Passphrase sollte nicht zu lang sein, denn sie wird doch das eine oder andere Mal abgefragt. Zeitweise wurden DSA-Keys für unsicher gehalten, da wohl der Algorithmus schlecht implementiert war.

Es entstehen Dateien mit den Schlüsselpaaren: Für Protokoll 1 (RSA1) ~/.ssh/identity und ~/.ssh/identity.pub, für Protokoll 2 (RSA, DSA) ~/.ssh/id_{rsa,dsa} und ~/.ssh/id_{rsa,dsa}.pub.

Die *.pub-Dateien können nun auf den Zielhost kopiert werden und dort an ~/.ssh/authorized_keys angehängt werden:

ssh-copy-id user@remote-system

ssh-copy-id -i ~/.ssh/id_rsa.pub user@remote-system

ssh-copy-id -i ~/.ssh/id_dsa.pub user@remote-system

Oder, wenn ssh-copy-id nicht vorhanden ist:

cat ~/.ssh/*.pub | ssh user@remote-system 'umask 077; cat >>.ssh/authorized_keys'

Sonst ist das andere Theater witzlos.

Nutzt man nun slogin, ssh, oder scp, will der Server auf der anderen Seite den Beweis, daß man zu einem der dort in der authorized_keys liegenden öffentlichen Schlüssel den privaten Teil hat.

Der lokale Client verlangt also nach der Passphrase, um den (lokal in id_{dsa,rsa}) gespeicherten privaten Schlüssel zu "aktivieren". Passen beide Schlüssel zusammen, ist der Server davon überzeugt, daß wir einer derjenigen sind, die Zugang erhalten sollen.

Um das beständige Nachfragen nach der Passphrase zu unterdrücken, ist es möglich, einen ssh-agent beim Login zu starten. Dieser Agent bekommt die Passphrase übergeben, kann den privaten Schlüssel aktivieren und in Zukunft alle Fragen nach diesem Schlüssel stellvertretend beantworten.

Für normale Konsolen-Logins geht das etwa so: (in der .profile oder wie immer die heißt) -- meine Login-Shell ist eine Bash.

test "$SSH_AUTH_SOCK" || exec ssh-agent $SHELL -c "ssh-add; exec $SHELL -login"

Für X11-Nutzer: in meiner .xsession findet sich z.B. folgendes:

test "$SSH_AUTH_SOCK" || exec ssh-agent $SHELL -c "ssh-add </dev/null; exec fvwm2" exec fvwm2

Natürlich gibt's noch die "classic-Variante" mit eval `ssh-agent` und einem anschließenden ssh-add. Aber es bleiben dann Probleme beim Killen der nach Sessionende übrigbleibenden Agents.

Problembehebung

Falls das passwortlose Login nicht funktionert, sollte folgendes geprüft werden* Ist der ssh-Zugriff überhaupt möglich? (Ein beliebtes Problem ist ... key_exchange ... connection closed by foreign host. Das liegt dann meist daran, daß die Reverse-Auflösung der eigenen IP-Adresse nicht mit dem Namen für den eigenen Host übereinstimmt.

Auf der anderen Seite in /etc/hosts.deny die ALL: PARANOID Zeile auskommentieren. Oder DNS in Ordnung bringen!
Passwort wird verlangtMeistens ein Problem der Permissions auf der eigenen und/oder der anderen Seite: Das Verzeichnis .ssh/ und die die Datei .ssh/authorized_keys darf nur für den Eigentümer, der auch der "angepeilte" Nutzer sein muß, schreibbar sein. Auch das Home-Verzeichnis des angepeilten Nutzers darf ausschließlich für den Eigenümer beschreibbar sein.
ssh -v ... hilft, diese Art von Problemen zu diagnostizieren.
Die SSH2 verlangt die Keys in ~/.ssh/authorized_keys2. M.W. ist die SSH2 auf Debian/GNU-Linux gepatcht und sucht die wie gehabt in ~/.ssh/authorized_keys, aber u.a. auf SuSE-Systemen habe ich schon gesehen, daß eben diese 2 angehängt werden muß.

Erzwingen der Verwendung von Schlüsseln

Wenn das jetzt alles so schön funktioniert, wollen wir ja auch die Anmeldung mit den Schlüsseln erzwingen. Wenn es nur den Root-Account betrifft, ist das relativ einfach:

# /etc/ssh/sshd_config PermitRootLogin without-password

Wenn auch andere Nutzer von der Schlüsselnutzung überzeugt werden sollen, dann sieht es etwas komplexer aus:

# /etc/ssh/sshd_config

…
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes

...

Wenn eine schlüsselfreie Anmeldung erkannt wird, versucht die SSH zuerst, PAM zu nutzen (UsePAM und ChallengeResponseAuthentication), zu erkennen am Passwort-Prompt Password:. Wenn das nicht funktioniert, versucht die SSH anschließend noch mal selbst, das Passwort zu prüfen (PasswordAuthentication), der Passwort-Prompt ändert sich zu user@host's password:.

PAM auszuschalten wäre auch möglicht, ist aber nicht nützlich, weil dann z.B. Session-Management über PAM nicht mehr funktioniert, einige Umgebungsvariablen nicht gesetzt werden usw. usf. Waren die oben angegebenen Manipulationen erfolgreich, so darf keinesfalls nach einem Passwort, sondern nur nach einer Passphrase (das ist dann die für den privaten Schlüssel) gefragt werden. Natürlich muss für derlei Versuche der SSH-Agent ausgeschaltet, oder wenigstens "gelähmt" sein (ssh-add -x).

PermitUserEnvironment

Wenn mehrere Benutzer mit dem selben Account (z.B. root) eine Maschine zugreifen müssen und es sollen noch personenspezifische Dinge (History, Begrüßung, ... ) konfiguriert werden, dann gibt es eine clevere Lösung:

An den Anfang der dem Nutzer entsprechenden Zeile in wird eine Option eingetragen. Diese Zeile sieht dann etwa so aus:

enviroment="REMOTE_USER=heinz" 1024 37 1452609839509....

Diese Umgebungsvariable lässt sich auswerten. In der Manualseite zum sshd wird dies genauer beschrieben.

Bei neueren SSH (>3.4) muss in der Konfiguration erlaubt werden, dass Environment-Variablen gesetzt werden dürfen. Sonst werden die betroffenen Zeilen der authorized_keys einfach ignoriert. Die entsprechende Option heißt PermitUserEnvironment.

Authentifizierungsagent ssh-agent

Das Programm ssh-agent ist ein Programm, das geeignet ist, die Private-Keys zu verwalten, die dazu benötigt werden, um sich mit Public-Keys zu authentifizieren. Die Idee dahinter ist die, dass ssh-agent am Anfang einer ssh-Sitzung (oder einer X-Sitzung, die über ssh getunnelt wird) gestartet wird und alle weiteren zu startenden Programme als Clients des SSH-Agenten laufen. Damit kann festgelegt werden, dass nicht jeder Rechner im Netz die entsprechenden Private-Keys gespeichert haben muss, es reicht wenn sie auf dem Rechner liegen, auf dem der Agent läuft.

SSH-Agent

Praktisch wäre es, wenn man nicht jedesmal die "pass phrase" eingeben müsste. Dann würde die Verwendung von Public-Keys nicht nur zur Sicherheit beitragen, sondern auch zur Bequemlichkeit (selten genug, dass sich das beides unter einen Hut bringen lässt).

Hier kommt der SSH-Agent ins Spiel. Im SSH-Agenten kann man seine(n) privaten Schlüssel ablegen, so dass sich der Agent von nun an um die Authentifizierung kümmert. Man muss also nur einmal seine "pass phrase" angeben, und der Agent behält dann den Schlüssel bis zu seiner Beendigung (normalerweise beim Abmelden des Benutzers ("logout")) im Speicher.

Der SSH-Agent wird bei einer Ubuntu-Desktop-Sitzung automatisch im Hintergrund gestartet. Zur Interaktion mit dem SSH-Agenten dient das Programm ssh-add, wobei die Option -l die augenblicklich gespeicherten Schlüssel auflistet:

ssh-add -l

The agent has no identities.
$ ssh-add
Enter passphrase for /home/user/.ssh/id_rsa:
Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)
$ ssh-add -l
1024 24:55:ee:67:83:72:82:55:5f:b9:b4:09:2a:fa:56:a1 /home/user/.ssh/id_rsa (RSA)
$ ssh server
Last login: Wed Mar  8 11:11:58 2006 from 192.168.4.56

user@server:~$

Wenn man nicht über Gnome (oder eine andere graphische Benutzeroberfläche, die unter dem ssh-agent läuft) eingeloggt ist, funktioniert das so leider nicht. Dann muss man vorher noch ein

user@server1:~$ exec ssh-agent bash

ausführen um eine Shell zu öffnen, die mit dem ssh-agent kommunizieren kann.

SSH-Askpass

Wenn eines der Pakete ssh-askpass, ssh-askpass-gnome, ssh-askpass-fullscreen oder gtk-led-askpass installiert ist, kann ssh-add die Passphrase in Ermangelung eines Terminals auch über ein Dialogfenster abfragen.

Das nutzt man sinnvollerweise, um seinen Schlüssel gleich nach der Anmeldung auf einem grafischen System zu laden.

Für KDE-Nutzer gibt es ab Intrepid das Paket ksshaskpass, das für ssh-add eine graphische Oberfläche zur Verfügung stellt.

ssh-agent, ssh-add

Der ssh-agent bietet eine Lösung für User, die es leid sind, immer wieder die selbe Passphrase einzugeben, aber aus Sicherheitsgründen auch nicht ganz auf eine Passphrase verzichten möchten. Damit muß ein Hacker zumindest Zugriff auf den lokalen Rechner und die Socketdatei erlangen, wenn er den Privatekey benutzen möchte.

Wenn man den ssh-agent ohne Parameter aufruft, erstellt er einen Unix-Domain-Socket, teilt mit, wie man ihn dort erreichen kann und lauscht im Hintergrund darauf:

ssh-agent > myagent.sh

cat myagent.sh
SSH_AUTH_SOCK=/tmp/ssh-XXcMloql/agent.21753; export SSH_AUTH_SOCK;
SSH_AGENT_PID=21754; export SSH_AGENT_PID;

echo Agent pid 21754;

Mit ssh-add bringt man dem ssh-agent seine Privatekeys bei:

. ./myagent.sh

Agent pid 21754;
ssh-add ~/.ssh/id_rsa
Enter passphrase for /export/home/user/.ssh/id_rsa:

Identity added: /export/home/user/.ssh/id_rsa (/export/home/user/.ssh/id_rsa)

Wenn man keinen Privatekey angibt, werden die Standard-keys (identity,id_rsa und id_dsa) geladen.

Eine Übersicht der in den agent geladenen Keys erhält mit ssh-add -l, und die zugehörigen Publickeys mit ssh-add -L.

Der ssh-Client wird dann bei jedem Verbindungsaufbau die Privatekeys aus dem ssh-agent probieren, statt denen aus den Identity-Dateien:

. ./myagent.sh

Agent pid 21754;
ssh gate
[…]
debug1: userauth_pubkey_agent: testing agent key /export/home/user/.ssh/id_rsa
debug1: input_userauth_pk_ok: pkalg ssh-rsa blen 149 lastkey 0x80926f8 hint -1

[…]

Alternativ zu der myagent.sh kann man die Werte für die Environment-Variablen auch mit lsof bestimmen:

/usr/sbin/lsof -a -u user -U -c ssh-agent

COMMAND   PID     USER   FD   TYPE     DEVICE SIZE NODE NAME
ssh-agent 477 user    3u  unix 0xc1da1aa0      1155 /tmp/ssh-XXWzoqlO/agent.452

export SSH_AUTH_SOCK=/tmp/ssh-XXWzoqlO/agent.452 SSH_AGENT_PID=477

Wer möchte, dass die Variablen sich automatisch bei jedem Login auf den laufenden ssh-agent einstellen, kann das Programm keychain in seine ~/.bash_profile aufnehmen.

Weitere Informationenssh-agent(1) , ssh-add(1)

Single-Sign-On

Wem immer noch zu umständlich ist, beim Login nacheinander erst das Login-Passwort und dann die SSH-Passphrase einzugeben, der installiert sich stattdessen das Paket libpam-ssh.

Mit den richtigen Einstellungen wird man beim Login nach der Eingabe des Benutzernamens nicht mehr nach dem Passwort, sondern nach der SSH-Passphrase gefragt und kann sich danach ohne nervige Passwortabfrage mittels SSH auf seinen Systemen bewegen.

Nur wenn man die Passphrase nicht richtig eintippt, kann man sich stattdessen auch mit seinem normalen Passwort authentifizieren.

Zu beachten ist allerdings, dass der GNOME-Schlüsselbund dann nicht mehr automatisch freigeschaltet wird.

Vorsicht

Macht man hier einen Fehler, kann man sich eventuell nicht mehr am System anmelden. Sollte das passiert sein, ist es normalerweise noch möglich, sich per SSH einzuloggen und den Fehler zu beheben. Wenn auch das nicht mehr hilft, muss man das System zum Reparieren im Single-User-Runlevel oder von einer Live-CD starten.

Opensuse

TODO

Ubuntu 9.10

Zur Anmeldung mit einer Passphrase muss man die Dateien login (für Konsolenzugang) und gdm (wahlweise kdm oder xdm; für den grafischen Login) im Verzeichnis /etc/pam.d anpassen. Dort muss man die Zeile

@include common-auth

durch

auth sufficient pam_ssh.so auth required pam_unix.so nullok_secure use_first_pass

ersetzen und außerdem direkt hinter die Zeile @include common-session ein session optional pam_ssh.so setzen.

/etc/pam.d/gdm sieht dann in etwa so aus:

auth requisite pam_nologin.so

auth     required     pam_env.so
auth     sufficient     pam_ssh.so
auth     required     pam_unix.so nullok_secure use_first_pass
@include common-account
session     required     pam_limits.so
@include common-session
session     optional     pam_ssh.so

@include common-password

Danach wird in der Konsole nach der SSH-Passphrase gefragt, hier kann jedoch auch problemlos das normale Passwort eingegeben werden.

Alternative Einstellmöglichkeiten finden sich bei Debian z.B. in der Datei /usr/share/doc/libpam-ssh/README.Debian.

Ubuntu 9.04 und früher

Zur Anmeldung mit einer Passphrase muss man die Dateien login (für Konsolenzugang) und gdm (wahlweise kdm oder xdm; für den grafischen Login) im Verzeichnis /etc/pam.d anpassen.

Dort muss man jeweils direkt vor die Zeile @include common-auth ein @include pam-ssh-auth setzen, und direkt nach die Zeile @include common-session ein @include pam-ssh-session. /etc/pam.d/gdm sieht dann bspw. in etwa so aus:

#%PAM-1.0

auth    requisite       pam_nologin.so
auth    required        pam_env.so
@include pam-ssh-auth
@include common-auth
@include common-account
session required        pam_limits.so
@include common-session
@include pam-ssh-session
@include common-password

(/etc/pam.d/login ist etwas länger...)

Vorlage:Anchor SSH-Tunnel

Je nach SSH-Konfiguration können das auch grafische Anwendungen sein (X-Anwendungen).

Falls beim obigen Anmelden eine Fehlermeldung kommt wie:

Error: Can`t open display:

beendet man den Login-Versuch mit

und verbindet sich erneut mit eingefügtem Parameter <-X>

ssh -X <benutzer>@<rechner>

SSH-Tunnel

Mit SSH lässt sich jedes Protokoll durch eine verschlüsselte Kanal tunneln.

Das bedeutet, dass auch potentiell unsichere Protokolle sicher über nicht vertrauenswürdige Verbindungen genutzt werden können.

Datei:Grafik2.png

Die Syntax für den SSH-Tunnelbau ist jedoch ein wenig verwirrend:

ssh -L [bind_address:]port:host:port user@server

ssh -R [bind_address:]port:host:port user@server

Hierbei richtet die Option -L laut Dokumentation eine lokale, und die Option '-R' eine entfernte (englisch remote) Port-Weiterleitung ein.

Der verschlüsselte Tunnel wird dabei immer nur zwischen dem ssh-Client und dem ssh-Server hergestellt.

Die Verbindung vom Ende des Tunnels zu host läuft dagegen unverschlüsselt ab, und wird aus Sicht des betreffenden Systems angegeben, weswegen man host in den allermeisten Fällen wohl auf "localhost" setzen sollte.

Hierbei darf "localhost" nicht mit dem lokalen Rechner verwechselt werden.

Es handelt sich um "localhost" von server aus betrachtet, daher um den Server selbst.

Die Option -L bzw. -R gibt dabei die Richtung an, aus der der Tunnel benutzt werden kann. Bei -L vom eigenen Rechner zum entfernten hin, bei -R in der entgegengesetzten Richtung. (Das merkt man sich am Besten als normaL und Rückwärts.)

Das erste port-Argument bezeichnet dabei den Einstiegsport in die Verbindung.

Zu beachten ist hierbei, dass die Öffnung eines privilegierten Ports, also unter 1024, nur dem Superuser root gestattet ist. Man sollte also auf die höheren Ports ausweichen.

Mit dem optionalen Parameter bind_address kann man festlegen, auf welchen Netzwerkschnittstellen die Weiterleitung laufen soll, wobei localhost der Standard ist.

Ein * oder ein leeres bind_address-Argument vor dem Doppelpunkt bedeutet, dass die Weiterleitung an allen Schnittstellen läuft.

Möglicherweise funktioniert das nicht auf jedem System auf Anhieb, da die IPv6-Adresse das irgendwie verhindert, weshalb man den SSH-Tunnel mit dem Argument -4 auf die IPv4-Schnittstellen beschränken muss.

Der zweite port-Parameter gibt schließlich an, auf welchen Port von host die Weiterleitung gehen soll.

Ein weiteres nützliches Argument ist die Option -N, die das Erzeugen einer Terminal-Sitzung auf dem entfernten System unterbindet, wenn man nur die Port-Weiterleitung benutzen möchte.

Tunneling unsicherer Anwendungen

Um sichere Tunnels zwischen zwei Rechnern aufzubauen, wird der SSH-Client benutzt. Eigentlich handelt es sich um eine Art Port-Forwarding, denn es wird ein lokaler (oder entfernter) Port auf einen entfernten (oder lokalen) Port abgebildet und dazwischen wird eine ssh Verbindung aufgebaut.

ssh -L localerPort:fremderRechner:fremderPort User@Rechner

Mit diesem Befehl wird veranlasst, dass der angegebene Port des lokalen Rechners (localerPort) mit dem Port fremderPort des Rechners fremderRechner verbunden wird und das diese Verbindung über ssh verschlüsselt läuft. Die Angabe User@Rechner bezieht sich auf den Eigentümer der Verbindung und den Rechner, auf dem der lokale Port läuft. Um also den Port 12345 des Rechners einstein mit dem Port 80 des Rechners bohr zu verbinden, schreibt der User root auf einstein

ssh -L 12345:bohr:80 root@einstein

ssh -R fremderPort:fremderRechner:lokalerPort User@Rechner

Das ist sozusagen die Umkehrung des vorherigen Prinzips.

Beispiele

Weiterleitung von Port 8000 auf dem lokalen System an den Webserver (Port 80) auf server:

ssh -L 8000:localhost:80 server -N &

[1] 10843
$ netstat -anp --inet | egrep '(^Proto|8000)'
Proto Recv-Q Send-Q Local Address           Foreign Address         State    PID/Program name
tcp        0      0 127.0.0.1:8000          0.0.0.0:*               LISTEN     10843/ssh
$ fg
ssh -L 8000:localhost:80 server -N
[Strg-C]

Killed by signal 2.

Dasselbe, aber es wird nicht nur vom lokalen Host weitergeleitet, sondern von allen Schnittstellen:

ssh -L *:8000:localhost:80 server -N -4 &

[1] 10906
$ netstat -anp --inet | egrep '(^Proto|8000)'
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name

tcp 0 0 0.0.0.0:8000 0.0.0.0:* LISTEN 10906/ssh

Umgekehrte Richtung. Benutzern auf server wird ermöglicht, über localhost:3306 auf den MySQL-Server auf client zuzugreifen:

ssh -R 3306:localhost:3306 server

Last login: Sat Mar 11 23:24:20 2006 from 192.168.4.56
user@server:~$ netstat -an --inet | egrep '(^Proto|3306)'
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN
$ exit
logout

Connection to server closed.

Zur Veranschaulichung folgt hier noch einmal eine grafische Darstellung dieser Beispiele:

Doppelter SSH-Tunnel über zwei Konsolen:	Datei:Grafik5.png
Datei:Grafik6.png

supportpc$ ssh -L 54321:localhost:54321 zwischennutzer@zwischen $ zwischen$ ssh -L 54321:localhost:8080 zielnutzer@ziel

SSH-Tunnel über Zwischenrechner mit Zielrechner verbinden:

Datei:Grafik9.png

supportpc$ ssh -L 54322:ziel:22 zwischennutzer@zwischen

Pipes

Wenn man ssh einen Befehl übergibt und nicht den -t-Parameter setzt, leitet ssh stdin/stdout/stderr des Befehls unverändert an die aufrufende Shell weiter. Auf diese Weise kann man ssh in Pipes einbauen: * Die folgende Befehlsfolge zeigt den Füllstand der Rootpartition des Rechners gate an:

ssh gate df | awk '/\/$/ {print $5}' 64%

* Die folgende Befehlsfolge kopiert das Verzeichnis mydir in das /tmp-Verzeichnis des Rechners gate

tar cf - mydir/ | ssh gate 'cd /tmp && tar xpvf -'

imap (fetchmail, mutt)

Imap ist ein Protokoll zum Übertragen von Mails. Leider sendet es die Mails dabei unverschlüsselt über's Netz. Wer Shellzugriff auf seinen Mailserver hat, sollte es über ssh tunneln, was die Übertragung wesentlich sicherer (Verschlüsselung, Publickey-Authentifikation) und schneller (Kompression) macht. Am einfachsten geht das, indem der Mailuseragent auf dem Mailserver einen imapd im PreAuth-Modus aufruft und sich über stdin/stdout der ssh mit diesem unterhält:

ssh gate imapd * PREAUTH [231.36.30.64] IMAP4rev1 v12.264 server ready

Beispiele zur Konfiguration einiger Mailuseragents: * fetchmail: Alle Mail an die Domain user.de landet bei meinem Provider (our-isp.org), von wo fetchmail sie regelmäßig über imap auf meinen lokalen Mailserver (gate.user.de) abholt. Mit der folgenden ~/.fetchmailrc tunnelt fetchmail die imap-Kommunikation über ssh:

poll johannes.our-isp.org

        with options proto imap,
        preauth ssh,
        plugin "ssh -x -C user@%h /usr/local/bin/imapd Maildir 2>/dev/null",
        smtphost gate,

fetchall

* mutt: Meine Mail liegt also auf gate, und ich greife normalerweise lokal mit mutt über imap darauf zu. Falls ich dies von einem anderen Rechner versuche (z.B. mit dem Notebook über's Internet), tunnelt mutt die imap-Kommunikation zu gate über ssh. Folgende Zeilen in der ~/.muttrc ermöglichen das:

set tunnel="imapd || ssh -qC user@gateway.user.de imapd" set folder="{gate}~/Mail"

smtp (exim)

Einige Domains nehmen keine Mails von Dialin-Systemen entgegen. Die folgende /etc/exim/exim.conf bringt exim (Version 3.35) dazu, die Mails an diese Domains über eine ssh-verbindung zu johannes.our-isp.org zu leiten, der über eine feste IP-Adresse verfügt:

ssh:

  driver = pipe

  bsmtp = all
  bsmtp_helo = true
  use_crlf = true
  prefix = ""
  suffix = ""

  command = ssh johannes.our-isp.org netcat -w 1 localhost smtp
  user = user

  timeout = 300s
  temp_errors = 1
  return_fail_output = true

t_online:
  driver = domainlist

transport = ssh

rsync

rsync ist ein geniales Tool zum inkrementellen Spiegeln von Verzeichnissen, z.B. über verschiedene lokale Festplatten, nfs oder smbfs. Wenn man es mit dem Parameter -e ssh aufruft, tunnelt es sämtliche Kommunikation über eine ssh-Pipe, gerne auch über's Internet. Mit folgendem Aufruf übertrage ich die Webseiten auf meinen Webserver:

rsync --delete -a -e ssh ./ user@www.user.de:public_html/

Weitere Informationenhttp://rsync.samba.org/

cvs

cvs ist ein Programm zur Versionsverwaltung beliebiger Dateien. Zusätzlich löst es die Konflikte, die dadurch entstehen, dass mehrere User gleichzeitig an den selben Dateien Änderungen vornehmen.

Zum Abgleich greift cvs entweder über das Filesystem (also lokal, nfs, samba etc.) auf ein gemeinsames Verzeichnis zu, oder kommuniziert mit einem CVS-Server, den man beispielsweise über ssh ansprechen kann.

Zur Einrichtung eines CVS-Servers empfehle ich, auf dem Repository-Rechner einen User cvs anzulegen, in dessen Homedir das Repository liegt und ihm in seiner ~/.ssh/authorized_keys für jeden Benutzer eine Zeile anzulegen, die einen CVS-Server-Prozess startet:

no-port-forwarding,no-X11-forwarding,command="/usr/bin/cvs server" ssh-rsa AAAAB3NzaC1yc2...

Um den CVS-Server über ssh anzusprechen, geben Benutzer zuerst folgende Befehle ein:

export CVS_RSH=ssh export CVSROOT=:ext:cvs@host:/export/home/cvs

und können dann wie gewohnt mit cvs arbeiten:

cvs co module

Port forwarding

Local port forwarding

Datei:Grafik77.png

Wenn ich auf localhost ssh -g -L 4321:www.ibm.com:80 gate aufrufe, baut ssh eine Verbindung zu gate auf, lauscht währenddessen auf Port 4321 und reicht alle dort ankommenden TCP-Verbindungen an den sshd an gate weiter, der sie an Port 80 von www.ibm.com weiterleitet. Der Rückweg funktioniert entsprechend. Ich habe einen Tunnel von localhost:4321 auf www.ibm.com:80 gelegt.

Im Browser würde http://localhost:4321 also genauso aussehen wie die Webseite von IBM. Man muss auf localhost Rootrechte haben, wenn man einen lokalen Port <1024 öffnen möchte.

Wenn man den -g Parameter weglässt, können Clients den Port nur über die IP-Adresse 127.0.0.1 oder entsprechende Aliase (z.B. localhost) erreichen, müssen also auf dem selben Rechner wie der ssh-Client laufen, oder aus einem anderen Tunnel dort umsteigen.

Sollen die Benutzer auf dem sshd-Rechner keinen Shellzugriff, sondern nur Portforwarding können, kann man zunächst in der /etc/ssh/sshd_config die Option PasswordAuthentication=no setzen und dann für jeden betreffenden Publickey in der ~/.ssh/authorized_keys am Zeilenanfang einen Aufruf wie command="/bin/cat" oder command="sleep 2000d" einfügen.

Wer zusätzlich einen keepalive einbauen möchte, damit die Natting-Tabelle der Firewall im Leerlauf die Tunnels nicht kappt, schreibt an den Beginn der Publickeyzeilen jeweils:

command="while :;do date;sleep 10;done"

Um die möglichen Portforwoarding-Ziele zu beschränken, kann man eine Liste von permitopen-Optionen vor den jeweiligen Publickeys einfügen, z.B.:

permitopen="192.168.42.5:80",permitopen="127.0.0.1:8080"

Remote port forwarding

Datei:Grafik78.png

Wenn ich auf localhost ssh -R 9030:intranet:80 gate eingebe, nimmt der sshd auf gate die Verbindung entgegen, lauscht auf Port 9030 und reicht alle dort ankommenden Verbindungen an den ssh-Client auf localhost weiter, der sie auf den Port 80 von intranet weiterleitet. Der Rückweg funktioniert entsprechend. Ich habe einen Tunnel von gate:9030 nach intranet:80 gelegt.

Wer im Browser http://gate:9030 aufruft, landet auf dem Intranetserver.

Man muss auf gate Rootrechte haben, wenn man remote Port <1024 öffnen möchte. Wer den Rootzugriff per ssh nicht erlauben möchte, kann den ssh-Tunnel auf einen hohen Port (z.B. 9030) legen und mit xinetd, netcat oder Firewallregeln auf Port 80 umleiten.

Dies leisten folgende /etc/inetd.conf:

80 stream tcp nowait nobody /bin/nc /bin/nc -w 3 localhost 9030

oder /etc/xinetd.d/intranet:

service intranet

{
 type            = UNLISTED
        flags           = REUSE
        socket_type     = stream
        protocol        = tcp
        user            = root
        wait            = no
        instances       = UNLIMITED
        port            = 80
        redirect        = localhost 9030
        disable         = no

}

oder ein Firewallscript:

echo 1 > /proc/sys/net/ipv4/ip_forward # turns on forwarding

iptables -F -t nat # Flush existing translation tables
iptables -t nat -A PREROUTING -p tcp --dport 9030 -j DNAT --to localhost:80
iptables -t nat -A POSTROUTING -j MASQUERADE

Der sshd bindet die remote Tunnels in seiner Standardkonfiguration an das loopback-Interface; er nimmt also nur Verbindungen von localhost entgegen. Wer möchte, dass seine Tunnels auf allen Netzinterfaces erreichbar sind, trage in der /etc/ssh/sshd_config auf gate die Zeile GatewayPorts yes ein oder leite den Port wie oben beschrieben mit ssh oder xinetd um.

Tunnels ineinander stecken

Mit dem -p Parameter weise ich den ssh-Client an, den sshd auf einem anderen Zielport als 22 anzusprechen. Das ist z.B. sinnvoll, wenn ich eine ssh-Verbindung über einen bereits bestehenden Tunnel aufbauen möchte.

Mit jedem weiteren Tunnel erhöhe ich die Reichweite um bis zu zwei Hosts:

Zahl der Tunnels	Max. hops
0	1
1	3
2	5
3	7

Die folgende Abbildung zeigt, wie man mit zwei ineinander gesteckten Tunnels bereits fünf hosts beteiligen kann, etwa um eine VNC-Verbindung durch drei Firewalls zu tunneln, die VNC sonst nicht durchließen:

Datei:Grafik79.png

Verwenden der Portweiterleitung

Wenn sshd(8) auf dem Server auf der Gegenseite läuft, kann es möglich sein, bestimmte Dienste durch ssh zu ,tunneln'. Das kann wünschenswert sein, um beispielsweise POP- und SMTP-Verbindungen zu verschlüsseln, selbst wenn die Software keine eigene Unterstützung für verschlüsselte Verbindungen hat. Das Tunneln verwendet Portweiterleitung, um eine Verbindung zwischen dem Client und dem Server herzustellen. Die Client-Software muss hierfür in der Lage sein, auf einen nicht standardisierten Port verbinden zu können.

Die Idee dahinter ist, dass der Client sich mit dem entfernten System über ssh verbindet und angibt, welcher Port auf der Maschine des Clients dazu verwendet werden soll, Verbindungen zum Server weiterzuleiten. Danach ist es möglich, die Dienste, die verschlüsselt werden sollen (z. B. fetchmail, irc), auf dem Client mit der Angabe des gleichen Ports, der an ssh übergeben wurde, zu starten, und die Verbindung wird durch ssh getunnelt. Standardmäßig wird das System, das das Weiterleiten durchführt, nur eigene Verbindungen zulassen.

Die wichtigsten Optionen zum Tunneln sind die Optionen -L und -R, welche dem Benutzer das Portweiterleiten erlauben, die Option -D, welche das dynamische Portweiterleiten erlaubt, die Option -g, die es anderen Hosts erlaubt, Portweiterleitung zu benutzen, und die Option -f, welche ssh zuweist, nach der Authentifizierung im Hintergrund weiterzuarbeiten. Lies die ssh(1)-Handbuchseite, um weitere Details zu erfahren.

Dies ist ein Beispiel für eine getunnelte IRC-Sitzung von der Clientmaschine ,127.0.0.1' (localhost) zum entfernten Server ,server.example.com':

ssh -f -L 1234:server.example.com:6667 server.example.com sleep 10

irc -c '#users' -p 1234 pinky 127.0.0.1

Dies tunnelt eine Verbindung zum IRC-Server server.example.com und tritt mit dem Nick ,pinky' dem Channel ,#users' bei. Der lokale Port, der in diesem Beispiel verwendet wurde, ist 1234. Es tut nichts zur Sache, welcher Port benutzt wird, so lange er größer ist als 1023 (bedenke, nur root kann Sockets auf privilegierten Ports öffnen) und keine Störung mit bereits verwendeten Ports auftritt. Die Verbindung wird zum Port 6667 auf dem entfernten Server weitergeleitet, da das der Standardport für IRC-Dienste ist.

Der Remote-Befehl ,sleep 10' wurde angegeben, um dem Dienst, der getunnelt werden soll, eine gewisse Zeit (10 Sekunden in diesem Beispiel) zu geben, um zu starten. Wenn in der angegebenen Zeit keine Verbindung aufgebaut wurde, wird ssh sich beenden. Falls mehr Zeit benötigt wird, kann der sleep(1)-Wert entsprechend erhöht werden oder alternativ könnte das oben aufgelistete Beispiel als eine Funktion in die Benutzershell eingefügt werden. Siehe ksh(1) und csh(1) für weitere Details über benutzerdefinierte Funktionen.

ssh besitzt des Weiteren die Option -N, welche praktisch für das Portweiterleiten ist: Wenn -N übergeben wurde, ist es nicht notwendig, einen Remote-Befehl (»sleep 10« in dem Beispiel oben) anzugeben. Allerdings führt die Benutzung dieser Option dazu, dass ssh für immer wartet (anstatt zu beenden, wenn ein Remote-Befehl ausgeführt wurde), sodass der Benutzer darauf achten muss, den Prozess hinterher manuell mit kill(1) zu beenden.

Reverse SSH-Tunnel

Um einen Wartungszugang zu einem Rechner, der hinter einer Firewall steht, zu erhalten, kann ein SSH-Tunnel aufgebaut werden. Dieser Tunnel ist nun in beide Richtungen zu benutzen. Dadurch ist es möglich, aus der Entfernung auf einen Rechner zuzugreifen, ohne daß die Firewall, die ihn beschützt, zu öffnen.

Der hinter der Firewall stehende Rechner wird hier als „Client“ bezeichnet, der Rechner, zu dem die Verbindung aufgebaut wird, ist der „Server“. Dies ist nur zur Verdeutlichung, tatsächlich sind natürlich beide Rechner sowohl Cient als auch Server.

Aufbauen des Tunnels

Verbinden Sie sich vom Client aus mit dem Befehl

ssh -R 21361:localhost:22 meinserver.meinedomain

Es steht nun ein Tunnel und Sie können sich mit dem Befehl

ssh -p 21361 localhost

auf den Rechner verbinden. Hier müssen Sie natürlich das Passwort noch eingeben.

Hinweise

Es müssen auf beiden Rechnern die SSH-Server laufen.
Nutzen Sie beim Aufbauen des Tunnels wo immer möglich den FQDN, auch und gerade bei wechselden IP-Adressen (dyndns.org). Der Kunde wird sonst jedes Mal, wenn er die Verbindung aufbaut, die Sicherheitsabfrage vom SSH-Client bekommen.
Der oben angegebene Port 21361 ist nur ein Beispielport. Sie können jeden Highport benutzen, privilegierte Ports nur als root.
Unter Umständen ist es sinnvoll, für jeden Kunden einen anderen Port zu benutzen, falls zwei Ihrer Kunden gleichzeitig Support benötigen.

Remote Control via VNC

Datei:Grafik90.png

Fernwartung ist gerade für Administratoren oder Helpdesk-Mitarbeiter in der Firmenzentrale ein hilfreiches Mittel, um entfernte Benutzer bei Problemen zu unterstützen, ohne sich erst auf den Weg machen zu müssen.

Und das ist ohnehin nicht immer möglich, weil der Nutzer unter Umständen zu weit entfernt ist. Programme wie VNC oder PC Anywhere bieten die entsprechenden Funktionen.

VNC ist zwar Freeware, dafür bietet es jedoch keine Verschlüsselung. Mit OpenSSH lässt sich dieses Manko beheben.

Der VNC-Server wartet im Allgemeinen auf Port 5900 auf eingehende Verbindungen.

Es müsste also eigentlich reichen, irgendeinen lokalen Port auf diesen Port am entfernten Rechner umzuleiten.

Die Client-Anwendung VNCviewer nimmt allerdings keine Portnummer als Parameter an, sondern erlaubt lediglich eine so genannte Display-Nummer, zum Beispiel:

zielrechner:0. Display-Nummern größer 0 verweisen auf die Ports nach 5900, also Display 2 auf Port 5902. Der Trick ist also, den lokalen Port 5902 auf den entfernten Port 5900 umzuleiten

ssh benutzer@sshrechner -L 5902:sshrechner:5900

und dann den VNCviewer mit localhost:2 zu starten. Dieser versucht nun, über den Port 5902 eine Verbindung zu einem lokalen Server aufzubauen, der allerdings von SSH auf den entfernten Rechner umgeleitet wird.

VNC is a very useful program for accessing a computer remotely. These are instructions for accessing a remote machine using OS X, Chicken of the VNC, and Vine Server when there is a firewall in the way.

Normally it is a fairly straightforward process to connect from a VNC client to a VNC server running on a remote machine. A firewall in the middle can complicate the process a bit.

Normal

MY MACHINE -> VNC CLIENT < - -> VNC SERVER < - REMOTE MACHINE

Behind firewall:

REMOTE MACHINE -> VNC SERVER -> SSH TUNNEL < - -> VNC CLIENT < - MY MACHINE# On MY MACHINE, create a local SSH user account and password – call it vnc_user

On MY MACHINE, determine my public IP address – go to whatismyip.com (MY_IP_ADDRESS)
On REMOTE MACHINE, turn on the Vine Server and set the password
On REMOTE MACHINE, open up Terminal and enter the following command:
ssh vnc_user@MY_IP_ADDRESS -R 5900:127.0.0.1:5900
where MY_IP_ADDRESS is the IP address of MY MACHINE.
Enter the password for the vnc_user. You should now be connected to MY MACHINE over SSH.
On MY MACHINE, open up Chicken of the VNC. Connect to localhost and enter the password for the REMOTE MACHINE.
You should now be connected to REMOTE MACHINE’s VNC server and be seeing their screen.

Notes:*

- - - Make sure that you are not running a VNC server on MY MACHINE, or that it is turned off
    - If you are running a firewall on your own network, you may need to enable port forwarding for SSH to ensure that SSH requests on port 22 are connected to MY MACHINE and not blocked by your own firewall.

Thanks to this article that describes how to do this and also includes an Applescript that makes the connection.

ppp over ssh

Das Point-to-point-Protokoll beschreibt Verbindungsaufbau und IP-Kommunikation zwischen zwei virtuellen Netzinterfaces. Mit etwas Aufwand kann man es auch über ssh tunneln, und so beliebige IP-Pakete über eine ssh-Verbindung routen.

Datei:Grafik80.png

Konfiguration des Servers:# Installation ppp (z.B. Version 2.4.1.uus-4 aus Debian GNU/Linux 3.0)

Dateirechte prüfen:
ls -l /usr/sbin/pppd

-rwsr-xr-- 1 root  dip   230604 10. Dez 2001  /usr/sbin/pppd*

Einen Benutzer anlegen, der zum Aufruf des pppd berechtigt ist:
adduser --group dip pppuser
PAP-Passwort und IP-Adressbereich vergeben:
echo 'pppuser * geheim *' >> /etc/ppp/pap-secrets
In der ~pppuser/.ssh/authorized_keys den RSA-keys IP-Adressen zuordnen (Eine Zeile pro Publickey):
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/usr/sbin/pppd remotename pppuser refuse-chap refuse-mschap refuse-mschap-v2 refuse-eap require-pap 192.168.45.1:192.168.45.2 notty debug linkname pppoverssh" ssh-rsa AAAAB3NzaC1...
Die /etc/ppp/ip-up.d/*-Scripts von allen störenden Routing- und Firewall-Initialisierungen bereinigen, welche die Distribution für die Interneteinwahl vorgesehen hatte. Wenn auf dem Rechner weitere PPP-Verbindungen (z.B. DSL-Einwahl ins Internet) erforderlich sind, können sich die Scripts an der $LINKNAME-Variablen orientieren, die den Wert "pppoverssh" hat.

Konfiguration des Clients

Installation ppp (z.B. Version 2.4.1.uus-4 aus Debian GNU/Linux 3.0)
Sicherstellen, dass der User den pppd setsuid aufrufen kann:
ls -l /usr/sbin/pppd

-rwsr-xr-- 1 root  dip   230604 10. Dez 2001  /usr/sbin/pppd*
usermod -G dip user

Einen neuen Provider anlegen:
cat >/etc/ppp/peers/ssh <<EOF

pty 'ssh -e none pppuser@SERVER-HOSTNAME false'
user pppuser
nodetach
linkname pppoverssh
# debug
EOF

Das PAP-Passwort des Serves eintragen:
echo 'pppuser * geheim' >> /etc/ppp/pap-secrets
/etc/ip-up.d/* ggf. anpassen (z.B. defaultroute auf $PPP_IFACE umsetzen)

So sieht der Verbindungsaufbau aus, wenn alles geklappt hat:

user@localhost:~ $ /usr/sbin/pppd call ssh

Using interface ppp0
Connect: ppp0 <--> /dev/ttyp4
Remote message: Login ok
kernel does not support PPP filtering
Deflate (15) compression enabled
Cannot determine ethernet address for proxy ARP
local  IP address 192.168.45.2

remote IP address 192.168.45.1

Mehr zum Thema pppd-Optionen:pppd(8)

Umgang mit Netz-Timeouts

Keepalives

Man kann konfigurieren, ob und wie ssh und sshd Verbindungsabbrüche feststellen sollen:

Seite	Option	Auswirkung
ssh	`ProtocolKeepAlives=`n	ssh sendet nach der Authentifizierung alle n Sekunden ein 32 Byte langes Leerpaket an den sshd. Das interessiert den sshd nicht weiter, aber der TCP-Stack des Servers muss ja TCP-Pakete regelmäßig mit ACKs beantworten. Wenn der TCP-Stack des Clients kein ACK auf dieses oder ein späteres Paket erhält, retransmitted er eine Zeit lang und signalisiert dann dem ssh ein Connection-Timeout, worauf dieser sich beendet.Linux 2.4 sendet 15 Retransmits und benötigt dafür etwa 14 Minuten. Die Zahl der Retransmits ist in `/proc/sys/net/ipv4/tcp_retries2` und `/etc/sysctl.conf` konfigurierbar. TCP wartet zwischen den Retransmits 3,6,12,24,48,60,60,60,... Sekunden auf Antwort.
ssh,sshd	`KeepAlive=`(yes\|no)	Der Prozess setzt beim Öffnen der TCP-Verbindung die Keepalive-Socketoption. Wenn der TCP-Stack darauf länger (z.B. 2 Stunden) nichts empfängt, sendet er nochmal ein altes Segment, zu dem er bereits ein ACK erhalten hat. Wenn die Gegenseite dadurch zum Wiederholen ihres letzten ACKs provoziert wird und dieses (z.B. innerhalb von 75 Sekunden) eintrifft, ist die Verbindung OK. Sonst wiederholt der TCP-Stack den Test einige (z.B. 9) mal und signaliert dann dem Prozess ein Connection-Timeout. Die genannten Werte sind bei Linux 2.4 in `/proc/sys/net/ipv4/tcp_keepalive_intvl`, `/proc/sys/net/ipv4/tcp_keepalive_probes` und `/proc/sys/net/ipv4/tcp_keepalive_time` bzw. in `/etc/sysctl.conf` konfigurierbar. Mit den o.g. Standardwerten dauert die Diagnose der verlorenen Verbindung insg. 2h11'15"!
sshd	`ClientAliveInterval=`s`ClientAliveCountMax=`n	Wenn sshd s Sekunden nichts empfangen hat, bittet er den ssh-Client im Abstand von s Sekunden um ein Lebenszeichen und beendet die Verbindung nach n erfolglosen Versuchen.

Feststellungen* Da es keinen ServerAliveInterval-Parameter für den Client gibt, bleibt der Client bei einigen Netzproblemen (z.B. NAT-Timeouts) mindestens eine Viertelstunde hängen, was für die getunnelten Verbindungen besonders lästig ist.

Wenn man ProtocolKeepAlives=0, KeepAlive=no und ClientAliveInterval=0 setzt und nach der Authentifizierung nichts mehr sendet, kann man die Netzverbindung trennen und beliebig (z.B. Jahre) später fortsetzen.

autossh

autossh ist ein C-Programm von Carson Harding <harding@motd.ca> (siehe http://www.harding.motd.ca/autossh/). Es löst das Problem hängender Tunnels, indem es # den ssh-Client startet ,

sich dabei mit zwei Portforwardings eine Testschleife einrichtet ,
regelmäßig die Verbindung über die Testschleife prüft und
den ssh-Client bei Problemen stoppt und erneut aufruft .

Datei:Grafik81.png

Mit dem folgenden Aufruf stelle ich meinen IMAP-Server lokal zur Verfügung. autossh prüft ssh-Verbindung nach den ersten 30 Sekunden alle 15 Sekunden:

export AUTOSSH_GATETIME=30

export AUTOSSH_POLL=15

autossh -M 20000 -g -N -C -L 143:localhost:143 gate.user.de

Wer häufig ssh-Tunnels errichtet, kann sich ein bash-Alias auf ssh legen:

alias ssh=':& a=$! ; port=$(( $a%45536 +20000 ))

  AUTOSSH_GATETIME=30 AUTOSSH_POLL=15 autossh -M $port'
ssh -g -N -C -L 143:localhost:143 gate.user.de

[1] 6418

Hierbei wird die nächste PID in $a geschrieben, durch Addieren von 20000 oder -25536 daraus ein Wert zwischen 20000 und 65535 ermittelt und dieser als Monitoringport an autossh übergeben.

Firewalls durchdringen

Achtung:Das Umgehen fremder Sicherheitssysteme ist verboten. Hier soll ein Verständnis für Sicherheitslücken vermitteln werden, damit sie abgesichert werden können.

Motivation

ssh-Verbindungen stellen für Firmen ein enormes Risiko dar, schließlich können darüber Tunnels an Virenscannern und Logfiles vorbei gelegt und Dateien übertragen werden.

Viele Firmen haben daher auf ihren Routern oder Firewalls den Zugriff auf Port 22 aller Internetteilnehmer verboten. Da heute jedoch praktisch kein Unternehmen auf einen Internetanschluß verzichten kann, bestehen meist doch gewisse Löcher in der Firewall.

Mit den Kenntnissen aus Kapitel 14.3.9 SSH-Tunnel (S. 84) (insb. ppp-over-ssh) ist es damit trivial, beliebige IP-Verbindungen durch nahezu jede Firewall zu betreiben.

Offene Ports benutzen

Zunächst soll geprüft, welche Ports die Firewall immer durchlässt. Dazu kann der nmap-Portscanner genutzt werden:

root@localhost$ nmap -sA -p 1-65535 www.user.de

Starting nmap V. 2.54BETA22 ( www.insecure.org/nmap/ )
Interesting ports on www.user.de (195.88.176.20):
(The 21 ports scanned but not shown below are in state: filtered)
Port       State       Service
25/tcp     UNfiltered  smtp
80/tcp     UNfiltered  http
443/tcp    UNfiltered  https

Nmap run completed -- 1 IP address (1 host up) scanned in 5138 seconds

Sobald auch nur ein Port unfiltered ist (hier z.B. 80), kann ich auf meinem Server für diesen Port einen sshd starten: oder den Port auf dem Server mit ssh, inetd/nc, xinetd oder Firewallregeln auf Port 22 umleiten:

Beispiel: siehe Kapitel 14.3.9 SSH-Tunnel (S. 84)

Dem Client gibt man entweder bei jedem Aufruf den Parameter -p 80 oder trägt den Port dauerhaft in die ~/.ssh/config ein:

Host www.user.de

        Port 80

User user

Vorhandene Proxyserver benutzen

Wenn der eigene Rechner (laut nmap) keinen einzigen Port im Internet erreichen, aber auf einen Proxyserver zugreifen kann, liegt doch nichts näher, als die ssh-Verbindungen über diesen Proxyserver ins Internet zu leiten.

ssh over http

httptunnel

httptunnel stellt einen tcp Port eines entfernten Servers lokal zur Verfügung. Für die Verbindung sorgen zwei kleine Programme (hts und htc), die im Netz wie Browser und Webserver über http kommunizieren.

Datei:Grafik85.png

Setup:* auf dem Server (als root, weil port 80 < 1024):

hts --no-daemon --forward-port localhost:22 80

* auf dem Client:

htc --no-daemon --forward-port 8888 --proxy proxy:8080 --proxy-authorization user:geheim localhost:80 & ssh -p 8888 -o NoHostAuthenticationForLocalhost=yes localhost

Problematisch ist zurzeit (httptunnel Version 3.3) , dass* nur eine Verbindung gleichzeitig über den Tunnel möglich ist

ein Bug dafür sorgt, dass bei Verwendung eines Proxyservers der hts das Ende der Verbindung nicht mitbekommt. Man muß ihn nach jeder Verbindung stoppen und starten.

Aus dem Alltag eines Sysadmin: Httptunnel

Aus dieser Zeit stammt Httptunnel. Obwohl Admins das Tool heute durch ein paar IPtables-Zeilen ersetzen könnten, bleibt es benutzerfreundlich und gehört zur Serienausstattung der meisten Distributionen.

Ich werde Httptunnel im Urlaub verwenden, der mich in zwölf Stunden nach Okzitanien bringt, einer Gegend mit netten Menschen, herrlicher Landschaft und Internetcafés, deren Betreiber unter einem Netzzugang ausschließlich HTTP verstehen.

Ich dagegen will im IRC die Ergebnisse des in Okzitanien ausgetragenen internationalen Quallenweitwurfs vermelden, also brauche ich SSH.

Datei:Grafik87.png

[1]Abbildung 1: Charly legt im Frankreichurlaub einen Tunnel quer durch Firewalls, um im IRC über Quallenweitwurf berichten zu können.

HTC, die Clientkomponente von Httptunnel, lauscht auf einem Port, (der über 1024 liegen muss, wenn ich nur als User arbeite).

Dort eingehende Verbindungen verpackt der Client in HTTP und schickt sie auf einem Firewall-Piercing-fähigen Port zum Ziel. Ich versuche Port 443:

htc -w -F 4711 kintyre.kuehnast.com:443

Beim Ausprobieren hilft mir der Parameter »-w«, der verhindert, dass der Prozess sich als Daemon im Hintergrund abduckt.

Später werde ich ihn weglassen. Das »-F« steht für Forward, dahinter folgen Quelle und Ziel der Weiterleitung.

Da die Quelle ein Port auf dem Localhost ist, gebe ich keinen Hostnamen an, sondern nur den Port. Beim Ziel darf ich nicht nur IP-Adressen, sondern wie im Beispiel auch Hostnamen verwenden.

Im Krebsgang

Auf dem Ziel läuft das Ganze rückwärts. Die Serverkomponente HTS nimmt auf dem Port 443 eingehende Verbindungen entgegen, schält sie aus dem HTTP heraus und leitet sie an den konfigurierten Zielport weiter. In dem Beispiel ist das 22, denn ich möchte ja einen SSH-Login haben: »hts -w -F localhost:22 443«.

Unlogischerweise muss ich den Zielport 22 zuerst angeben, danach den Port, auf dem HTS auf Verbindungen lauscht. Aber egal, es kann losgehen.

Auf dem Client öffne ich eine SSH-Verbindung gegen Localhost, Port 4711, mit

ssh -p 4711 charly@localhost

und kann mich auf dem Server einloggen.

Das mit dem Quallenweitwurf war natürlich ein Witz - aber seit das Languedoc nicht mehr Industriealkohol, sondern richtig gute Weine produziert, mache ich die Daheimgebliebenen anderweitig neidisch.

Weitere Informationenhttp://www.nocrew.org/software/httptunnel.html

ssh over https

Datei:Grafik86.png

ssh-https-tunnel

Das Perlscript ssh-https-tunnel weist einen Proxy-Server per CONNECT-Anweisung an, eine TCP-Verbindung zu einem remote Host zu öffnen und ermöglicht die Kommunikation dorthin über stdin/stdout.

Eine Erweiterung von Gerd Aschemann <gerd@aschemann.net> vereinfacht die Konfiguration dahingehend, dass man den Proxyserver nicht mehr im Sourcecode eintragen muß, sondern dass dieser aus der Environment-Variable HTTP_PROXY oder der Datei ~/.ssh/https-proxy.conf ausgelesen wird:

HTTP_PROXY=http://proxy:8080 ./ssh-https-tunnel gate.user.de 25

220 gate.user.de ESMTP Exim 3.35 #1 Fri, 13 Sep 2002 18:08:13 +0200
HELO abc
250 gate.user.de Hello proxy.user.de [192.168.42.2]
QUIT

221 gate.user.de closing connection

Das Proxy-Log zeigt nach dem Beenden der Verbindung:

proxy:~# tail -1 /var/log/squid/access.log| fmt

1031933305.366  11857 192.168.42.20 TCP_MISS/200 213 CONNECT

gate.user.de:25 - DIRECT/192.168.42.1 -

Durch so einen Tunnel kann man natürlich auch ssh fahren. Wenn der Proxyserver gut konfiguriert ist oder hinter einer Firewall steht, sind https-Verbindungen möglicherweise nur auf Port 443 möglich. In dem Fall reicht es, einen weiteren ssh-Dämon auf Port 443 zu starten, oder (z.B. per ssh -gL 443:localhost:22 localhost or xinetd) den Port auf den bereits auf Port 22 laufenden sshd zu forwarden.

Setup:* in ~/.ssh/config folgende Zeilen anfügen:

host gate.user.de

  ProxyCommand ~/.ssh/ssh-https-tunnel %h %p

Port 443

* den Proxyserver in die Datei ~/.ssh/https-proxy.conf eintragen:

host=proxy port=8080

Und schon läuft die Verbindung über den Proxyserver an den ssh-Dämon, der auf gate auf Port 443 lauscht:

ssh -v gate.user.de

OpenSSH_3.4p1 Debian 1:3.4p1-2, SSH protocols 1.5/2.0, OpenSSL 0x0090605f
debug1: Reading configuration data /export/home/user/.ssh/config
debug1: Applying options for gate.user.de
debug1: Applying options for *
[…]
debug1: Executing proxy command:  ~/.ssh/ssh-https-tunnel gate.user.de 443
[…]
debug1: Remote protocol version 1.99, remote software version OpenSSH_2.9.9p2
[…]
Last login: Fri Sep 13 18:28:31 2002 from p5080d740.dip.t-dialin.net

Have a lot of fun...

transconnect

transconnect ist eine C-Bibliothek, welche die connect-Funktion der glibc ersetzt, so dass der Verbindungsaufbau per https über einen Proxyserver läuft. Das funktioniert damit nur für dynamisch gelinkte Binaries (das kann man mit ldd prüfen). Der Vorteil gegenüber einem vorher einzurichtenden Tunnel liegt darin, dass die Anwendung flexibel in der Auswahl des Ports ist.

LD_PRELOAD=~/.tconn/tconn.so netcat localhost daytime Sat Sep 14 11:25:49 2002

transconnect Project Home Page

proxytunnel

proxytunnel ist ein C-Programm, das mit Hilfe einer https-Verbindung zu einem Proxyserver einen remote Port wahlweise als Pipe oder lokalen Port verfügbar macht. Letzteren kann man sogar entweder als Daemon oder (automatisch bei Bedarf) über inetd/tcpd bereitstellen.

Die Syntax ist einfach:

./proxytunnel-linux-i386 --help

Proxytunnel 1.1.0
Jos Visser (Muppet) <josv@osp.nl>, Mark Janssen (Maniac) <maniac@maniac.nl>

Purpose:
  Build generic tunnels trough HTTPS proxy's, supports HTTP authorization

Usage: Proxytunnel [OPTIONS]...
   -h         --help              Print help and exit
   -V         --version           Print version and exit
   -c         --config=FILE       Read config options from file (FIXME)
   -i         --inetd             Run from inetd (default=off)
   -a INT     --standalone=INT    Run as standalone daemon on specified port
   -f         --nobackground      Don't for to background in standalone mode (FIXME)
   -u STRING  --user=STRING       Username to send to HTTPS proxy for auth
   -s STRING  --pass=STRING       Password to send to HTTPS proxy for auth
   -g STRING  --proxyhost=STRING  HTTPS Proxy host to connect to
   -G INT     --proxyport=INT     HTTPS Proxy portnumber to connect to
   -d STRING  --desthost=STRING   Destination host to built the tunnel to
   -D INT     --destport=INT      Destination portnumber to built the tunnel to
   -n         --dottedquad        Convert destination hostname to dotted quad
   -v         --verbose           Turn on verbosity (default=off)
   -q         --quiet             Suppress messages  (default=off)

Examples:
Proxytunnel [ -h | -V ]
Proxytunnel -i [ -u user -s pass ] -g host -G port -d host -D port [ -n ] [ -v | -q ]

Proxytunnel -a port [ -u user -s pass ] -g host -G port -d host -D port [ -n ] [ -v | -q ]

Beispiele zur Verwendung* als pipe:

ssh -o ProxyCommand=./proxytunnel-linux-i386 -g proxy -G 8080 -d %h -D %p' gate

Connected to proxy:8080
Starting tunnel
Linux gate 2.2.19 #5 Wed May 1 20:15:01 CEST 2002 i586 unknown
You have mail.

Last login: Sat Sep 14 10:38:58 2002 from tp.user.de

* als portforwarder:

./proxytunnel-linux-i386 -a 8888 -g proxy -G 8080 -d localhost -D 22

Forked into the background with pid 1524
ssh -p 8888 -o NoHostAuthenticationForLocalhost=yes localhost

Last login: Sat Sep 14 10:54:42 2002 from gate.user.de

Das kann man natürlich auch dauerhaft in ~/.ssh/config konfigurieren:

Host gate-via-proxy

        Hostname gate.user.de

ProxyCommand "proxytunnel-linux-i386 -g proxy -G 3128 -d %h -D %p"

Weitere Informationenhttp://proxytunnel.sourceforge.net/

Empfehlungen

Der beste Schutz vor ungewollten ssh-Verbindungen ins Internet besteht darin, den Internetzugriff im LAN zu verbieten und beispielsweise den Browser aus einer DMZ über X11, Citrix Metaframe, VNC o.ä. auf dem Client darzustellen.

SSH per Socket beschleunigen

If you connect twice or more to the same server and you don’t want to reauthenticate again, you can use a socket to bypass it. You need OpenSSH 4.x or higher.

Normale Situation

Erste Sitzung

$ ssh ruben@pc-rgonzalez ruben@pc-rgonzalez’s password:

Zweite Sitzung

ssh user@pc user@pc password:

This is the normal behavior, so you need the put credentials twice. Using ssh socket feature bypass it, so on the CLIENT side you need to add these lines.

/etc/ssh/ssh_config

# socket speed up
Host *
ControlMaster auto

ControlPath ~/.ssh/socket-%r@%h:%p

Verbesserte Situation

Erste Sitzung

$ ssh user@pc user@pc password:

Zweite Sitzung

$ ssh user@pc $ (no password needed!)

It’s also create a socket in your home like this:

file /home/user/.ssh/socket-user\@pc\:22 /home/user/.ssh/socket-user@pc-user:22: socket

If you close your ssh session , socket will be deleted until you create a new one using another ssh session. It works nice if you need to exec a command behind a firewall like:

(create a session in background, it also creates the socket)

$ ssh -N -f user@firewall

then

ssh user@firewall “ssh -t user@anothermachine”

ssh user@firewall “ssh -t user@anothermachine2″

etc ...

Konfiguration

Überblick

Datei:Grafik39.png

Client-Konfiguration

Der ssh-Client liest seine Konfiguration aus * Kommandozeilenparametern

~/.ssh/config
/etc/ssh/ssh_config

Der erste Treffer zählt. Die config-Dateien erlauben die Definition von Host-Bereichen. z.B.:

Host stunnel.our-isp.org

 ProxyCommand ~/.ssh/ssh-https-tunnel %h %p
 Port 443

Host hera 141.*
 User franken
 Protocol 1

Host 192.* gate mausi localhost tp
 Compression no
 Cipher blowfish
 Protocol 2

Host *
  ForwardAgent yes
  ForwardX11 yes
  Compression yes
  Protocol 2,1
  Cipher 3des

EscapeChar ~

Wenn man sich auf der Konsole mit einem anderen Server verbinden möchte, muss man evtl. z.B. Port und Benutzernamen angeben. Um das Ganze zu vereinfachen, kann man Voreinstellungen für ssh in der config-Datei $HOME/.ssh/config hinterlegen. Hier ein Beispiel:

# ssh (secure shell) configuration file

Host test1
    HostName 123.456.789.0
    Port 980
    User MeinBenutzerName
Host test2
    HostName test.mynet.local
    User test
    CheckHostIP no

Cipher blowfish

Nun reicht ein kurzer Befehl für den Verbindungsaufbau:

ssh test1 # statt

ssh MeinBenutzerName@123.456.789.0 -p980

Die Manpage von ssh_config(5) enthält eine vollständige Übersicht aller Direktiven.

Server-Konfiguration

Der ssh-Server liest seine Konfiguration aus* Kommandozeilenparametern und

/etc/ssh/sshd_config

Der erste Treffer zählt.

Konfiguration des Servers in sshd_config

Die zentrale Konfigurationsdatei des SSH-Servers sshd liegt in /etc/ssh/sshd_config (in älteren Versionen auch direkt in /etc/sshd_config).

Diese Datei enthält alle nötigen Einstellungen des Servers. Jede Zeile (die nicht leer oder Kommentar ist) besteht aus einem Schlüsselwort (Gross/Kleinschreibung wird nicht unterschieden) und einem Wert (Gross/Kleinschreibung wird unterschieden).

Die wichtigsten Konfigurationsbefehle

Allgemeine Einstellungen

Port Portnummer

Gibt die Portnummer an, auf der sshd lauschen soll. Voreingestellt ist Port 22. Es können mehrere dieser Anweisungen angegeben sein, wenn sshd auf mehreren Ports arbeiten soll.

Protocol Protokollnummer(n)

Gibt das SSH-Protokoll an, mit dem gearbeitet werden soll. Mögliche Werte sind 1 oder 2. Wenn mehrere Protokolle verwendet werden sollen, dann müssen sie durch Kommas getrennt angegeben werden. Voreingestellt ist 2,1.

HostKey Dateiname

Gibt den Dateinamen mit Pfad des Private-Host-Keys an. Voreingestellt sind die oben genannten Dateinamen. Es können mehrere dieser Anweisungen in der Datei enthalten sein, etwa um die drei verschiedenen Schlüsseltypen für rsa1, rsa und dsa zu spezifizieren. sshd weigert sich die angegebenen Dateien zu benutzen, wenn sie Dateien für Gruppen oder Rest lesbar sind. Sie sollten also ein Zugriffsrecht von 600 besitzen.

KeepAlive yes|no

Gibt an, ob der Server TCP-KeepAlive Meldungen an den Client schicken soll. Wenn solche Meldungen geschickt werden, so kann erkannt werden, ob eine Verbindung physikalisch abgebrochen wurde oder einer der Kommunikationspartner abgestürzt ist.

Allerdings heisst das auch, dass eine Verbindung abbricht, wenn kurzzeitig eine Route ausfällt. Auf der anderen Seite wird so vermieden, dass sich Sessions aufhängen und trotzdem Reste im System hängenbleiben. Voreingestellt ist yes (KeepAlive Meldungen werden geschickt).

Authentifizierungsbefehle

LoginGraceTime Sekunden

Der Server trennt die Verbindung nach der angegebenen Anzahl von Sekunden, wenn ein User sich bis dahin nicht erfolgreich eingeloggt hat. Voreingestellt sind 600 (Sekunden). Steht hier eine 0, dann gibt es kein Zeilimit.

PermitRootLogin yes|no|without-password|forced-commands-only

Gibt an, ob und wie sich der Systemverwalter über ssh einloggen darf. Voreingestellt ist yes. Steht diese Einstellung auf without-password, so wird die Passwortabfrage für root abgeschalten. Das bedeutet, er kann sich nur einloggen, wenn er über ein entsprechend anderes Authentifizierungsverfahren verfügt. Steht der Wert auf forced-commands-only, so darf root nur Befehle ausführen (die an den ssh-Befehl angehängt werden), sich aber nicht regulär einloggen.

RhostsAuthentication yes|no

Gibt an, ob Authentifizierung über .rhosts oder /etc/hosts.equiv erlaubt sein soll. Voreingestellt ist no. Diese Option gilt nur für Protokollversion 1.

RhostsRSAAuthentication yes|no

Gibt an, ob Authentifizierung über .rhosts oder /etc/hosts.equiv zusammen mit RSA Host-Authentifizierung erlaubt sein soll. Voreingestellt ist no. Diese Option gilt nur für Protokollversion 1.

RSAAuthentication yes|no

Gibt an, ob reine RSA Authentifizierung erlaubt sein soll. Voreingestellt ist yes. Diese Option gilt nur für Protokollversion 1.

HostbasedAuthentication yes|no

Gibt an, ob Authentifizierung über .rhosts oder /etc/hosts.equiv zusammen mit RSA Host-Authentifizierung erlaubt sein soll. Voreingestellt ist no. Diese Option gilt nur für Protokollversion 2 und entspricht der Einstellung von RhostsRSAAuthentication für Version 1.

PubkeyAuthentication yes|no

Gibt an, ob Authentifizierung über Public-Keys erlaubt sein soll. Voreingestellt ist yes. Diese Option gilt nur für Protokollversion 2.

IgnoreRhosts yes|no

Gibt an, dass die Dateien .rhosts und .shosts nicht verwendet werden dürfen, wenn RhostsAuthentication, RhostsRSAAuthentication oder HostbasedAuthentication verwendet werden. Die Dateien /etc/hosts.equiv und /etc/shosts.equiv werden weiterhin abgearbeitet.

PasswordAuthentication yes|no

Gibt an, ob Authentifizierung über Passwörter erlaubt ist. Voreingestellt ist yes.

PermitEmptyPasswords yes|no

Gibt an, ob es bei erlaubtem PasswordAuthentication auch erlaubt sein soll, wenn User leere Passwörter haben. Voreingestellt ist no.

AllowUsers Muster|Liste

Hier kann eine durch Leerzeichen getrennte Liste von Usernamen/Mustern angegeben werden. Nur die hier angegebenen User dürfen sich einloggen. Für die Musterbildung stehen * und ? zur Verfügung wie auf der Shell. Es werden nur Namen, keine UserIDs interpretiert. Möglich ist auch, Einträge in der Form Username@Hostname zu machen, um nur User von bestimmten Rechnern aus zuzulassen. Voreingestellt ist, dass alle User sich einloggen dürfen.

AllowGroups Muster|Liste

Hier kann eine durch Leerzeichen getrennte Liste von Gruppennamen/Mustern angegeben werden. Nur User, die Mitglied der hier angegebenen Gruppen sind, dürfen sich einloggen. Für die Musterbildung stehen * und ? zur Verfügung wie auf der Shell. Es werden nur Namen, keine GroupIDs interpretiert. Voreingestellt ist keine Einschränkung auf bestimmte Gruppen.

Tunneling Optionen

AllowTcpForwarding yes|no

Gibt an, ob TCP-Forwarding erlaubt sein soll. Voreingestellt ist yes. Nachdem sich jeder User mit Shellzugriff seine eigenen Forwarder installieren kann, macht eine Einschränkung dieser Einstellung nur dann Sinn, wenn der User keinen Shellzugriff hat.

X11Forwarding yes|no

Gibt an, ob X11-Forwarding erlaubt sein soll. Voreingestellt ist no.

X11UseLocalhost yes|no

Gibt an, ob sshd den (virtuellen) X11-Forwarding Server an die Loopback-Adresse binden soll, oder an die Wildcard-Adresse. Voreingestellt ist yes (Loopback-Adresse). Damit wird der Hostnamenteil der DISPLAY-Variable auf localhost gesetzt. Damit wird verhindert, dass fremde Clients auf den virtuellen X-Server zugreifen können. Allerdings können ein paar ältere X11-Clients mit dieser Einstellung Schwierigkeiten haben. In diesem Fall kan diese Einstellung auf no gesetzt werden.

X11DisplayOffset Zahl

Gibt die Servernummer für den virtuellen X-Server an, um Verwechslungen mit echten X-Servern zu vermeiden. Voreingestellt ist 10.

XAuthLocation Pfad

Gibt den Pfad zum xauth Programm an. Voreingestellt ist /usr/bin/X11/xauth.

Natürlich muss der SSH-Daemon sshd nach einer Veränderung der Konfigurationsdatei entweder neu gestartet werden, oder es wird ihm ein HUP-Signal geschickt, das den Server zwingt, die Konfigurationsdatei neu zu laden.

Weitere Informationen

sshd(8), sshd_config(5)

Start des Servers

Um auf einen Rechner mit SSH zugreifen zu können, muss auf diesem ein SSH-Server gestartet, konfiguriert und und erreichbar sein. Die Konfiguration des SSH-Servers sshd findet über die Datei /etc/ssh/sshd_config statt. Die Voreinstellungen sind aber durchweg akzeptabel.

Wer den sshd auf einem Gateway oder Router betreibt oder aus einem anderen Grund mehrere Netzwerkschnittstellen verwendet (bspw. WLAN), der möchte dort vielleicht die ListenAddress-Direktive benutzen, um den Server nur an bestimmten Netzwerk-Schnittstellen laufen zu lassen.

Außerdem kann es sinnvoll sein, PermitRootLogin auf no zu setzen. Dann kann sich niemand direkt als root einloggen, sondern man meldet sich unter seinem Benutzernamen an und ruft dann su oder sudo -s auf.

Mit den Direktiven AllowUsers und AllowGroups bzw. DenyUsers und DenyGroups lässt sich noch genauer festlegen, welche Benutzer sich anmelden dürfen und welche nicht.

Dies empfiehlt sich besonders bei Servern. AllowGroups admin verbietet bspw. allen Benutzern, die keine Mitglieder der Gruppe admin sind, den Zugriff. Wer sich ausschließlich über das noch sicherere Public-Key-Verfahren anmelden will, der sollte die Benutzung von Passwörtern mit PasswordAuthentication no abschalten.

Falls lange Wartezeiten bei der Anmeldung am SSH-Server auftreten, könnte das an einer fehlgeschlagenen Namensauflösung liegen. Da man SSH normalerweise sowieso über die IP benutzt, können diese DNS-Anfragen in der sshd_config deaktiviert werden. Der dafür nötige Eintrag wäre UseDNS no.

Nach erfolgter Änderung der Datei sshd_config muss der Server mit dem Befehl:

# /etc/init.d/sshd restart

neugestartet werden, damit die Änderungen wirksam werden.

Opensuse

Da Linux ein Netzwerkbetriebssystem ist, ist der ssh-Server auf jeder Distribution bereits vorinstalliert, aber bei SUSE per default ausgeschaltet.

Bei Suse startet man den ssh-Daemon unter Yast -> System -> Systemdienste (Runlevel); hierzu sshd starten. Den SSH-Server konfiguriert man am besten mit Yast. Dazu installieren wir uns das Paket: yast2-sshd

Unter Yast -> Netzwerkdienste -> SSHD-Einrichtung können wir ssh einrichten.* Im Register Allgemein lassen wir die Standardeinstellungen und aktivieren den Haken bei Firewall freigeben.

Im Register Anmeldeeinstellungen entfernen wir als erstes aus Sicherheitsgründen den Root-Zugriff.
Zusätzlich aktivieren wir für einen ersten Test RSA Authentication; dies bewirkt, dass wir uns auf dem entfernten Rechner mit unseren normalen Benutzerdaten dort einloggen können.
Später sichern wir unseren SSH-Server ab und lassen nur noch das PublikKey Authentication zu, was dann ein Hacken von ausserhalb unmöglich machen wird.

Troubleshooting

Sitzung friert ein oder wird beendet

Dies kann durch NAT-Router (beendet die TCP-Verbindung wegen Inaktivität) oder restriktive Serverkonfiguration (Abbau inaktiver Sitzungen) verursacht werden.

Mit ClientAliveInterval in sshd_config am Server oder ServerAliveInterval in ssh_config am Client kann dieses Problem gelöst werden. Die Einstellung sollte kleiner sein, als die Zeit bis zum Abbruch der Sitzung.

usermapping

-o idmap=user

Verbindung kann nicht aufgebaut werden

Server ist nicht gestartet
Port an der Firewall ist nicht freigeschaltet
SSHGuard (o.ä.) ist aktiv und es gab zu viele fehlerhafte Login-Versuche

SSH bleibt beim Logout hängen

Bei dem Befehl

ssh host command

muss ssh abwarten bis sicher ist, * dass command keine Eingaben mehr erfordert

dass command keine Ausgabe mehr produziert
bis command beendet wird, denn sshd muss den Rückgabewert von command ssh melden

Public-Key Authentifizierung funktioniert nicht

Eine typische Ursache sind zu großzügige Zugriffsrechte auf $HOME, $HOME/.ssh oder $HOME/.ssh/authorized_keys. In diesem Fall kann das Problem wie folgt gelöst werden:

chmod go-w $HOME $HOME/.ssh

$ chmod 600 $HOME/.ssh/authorized_keys

$ chown $(whoami) $HOME/.ssh/authorized_keys

Alternativ kann StrictModes no in sshd_config gesetzt werden. Dies wird jedoch nicht empfohlen.

Probleme bei verschlüsseltem Home-Verzeichnis

Bei verschlüsselten Home-Verzeichnissen (ecryptfs) ist die Datei authorized_keys verschlüsselt. Somit kann sie zur Authentifizierung verwendet werden, solange das Home-Verzeichnis nicht entschlüsselt ist (durch parallele Anmeldung mit dem gleichen Benutzernamen).

Abhilfe ist z.B. die Datei authorized_keys in ein nicht-verschlüsseltes Verzeichnis zu legen (z.B. /etc/ssh/username/) und die Einstellung AuthorizedKeysFile in der /etc/ssh/sshd_config auf /etc/ssh/%u/authorized_keys zu ändern (Root-Rechte und Neustart des SSH-Daemons erforderlich).

# mkdir /etc/ssh/$USER

# mv $HOME/.ssh/authorized_keys /etc/ssh/$USER/
$ ln -s /etc/ssh/$USER/authorized_keys $HOME/.ssh/

Probleme von SSH 2.3 mit OpenSSH 2.1.1

SSH 2.3 und frühere Versionen haben einen Fehler in ihrer HMAC-Implementation. Ihr Code hat nicht die komplette Ausgabe des Datenblocks von der Auswahl bereitgestellt, sondern stattdessen eben nur 128 Bits. Bei längeren Anfragen konnte dann SSH 2.3 eben nicht mit OpenSSH zusammenarbeiten.

OpenSSH 2.2.0 erkennt, dass SSH 2.3 diesen Fehler hat. In zukünftigen Versionen von SSH wird dieser Fehler behoben sein. Alternativ kannst du das folgende in deine /etc/sshd2_config von SSH 2.3 einfügen.

Mac hmac-md5

setuid root de ssh-Clients

In Verbindung mit der vorhergehenden Frage (2.1) braucht OpenSSH root-Autorität, um sich an die unteren und privilegierten Ports binden zu können, um dann eine rhosts-Authentifikation durchzuführen. Genauso notwendig ist dieser privilegierte Port für rhosts-rsa-Authentifikation zu älteren SSH-Versionen.

Zusätzlich gilt sowohl für rhosts-rsa-Authentifikation (in Protokollversion 1) als auch für hostbasierte Authentifikation (in Protokollversion 2), dass der ssh-Client Zugang zum ,private host key' braucht, um die Clientmaschine am Server anzumelden. OpenSSH-Versionen vor 3.3 benötigten ein gesetztes setuid-Bit für die Binärdatei von ssh, um das zu erreichen, aber du kannst das Bit löschen, wenn du diese Authentifizierungsmethoden nicht benutzen willst.

Beginnend mit OpenSSH 3.3 ist ssh standardmäßig nicht setuid. ssh-keysign wird benutzt, um die privaten Hostschlüssel auszulesen, und ssh benutzt standardmäßig keine privilegierten Quellports. Wenn du doch einen benutzen willst, musst du das setuid-Bit von ssh per Hand setzen.

Dispatch protocol error: type 20

Probleme bei der Zusammenarbeit treten auf, weil ältere Versionen von OpenSSH noch keine Unterstützung für ,session rekeying' hatten. Das kommerzielle SSH 2.3 versucht diese Funktionalität abzulehnen, und es kann zum Einfrieren der Verbindung kommen, oder die Fehlermeldung ,Dispatch protocol error: type 20 ' kann zu lesen sein. Das Problem wird entweder durch ein Upgrade auf eine aktuelle OpenSSH-Version oder Abschalten des ,rekeying' durch Hinzufügen des folgenden in die ssh2_config oder sshd2_config vom kommerziellen SSH 2.3 behoben.

RekeyIntervalSeconds 0

IDEA verschlüsselte Hostkeys

Die alten Versionen von SSH haben einen patentierten Algorithmus benutzt, um ihren /etc/ssh/ssh_host_key zu verschlüsseln. Das Problem manifestiert sich darin, dass der sshd(8) seinen Hostschlüssel nicht lesen kann. Um das Problem zu lösen, benutze das Kommando weiter unten, um deinen ssh_host_key zu 3DES zu konvertieren. HINWEIS: Benutze das ssh-keygen(1)-Programm von dem kommerziellen SSH-Produkt und *NICHT* OpenSSH für das Beispiel weiter unten.

# ssh-keygen -u -f /etc/ssh/ssh_host_key

Warnungen über Schlüssellängen?

Das ssh-keygen(1) des kommerziellen SSH-Programms hat einen Fehler beinhaltet, der dazu führte, dass es von Zeit zu Zeit ,Pubkey'-Authentifikationsschlüssel (RSA oder DSA) generiert hat, deren ,Most Significant'-Bit (MSB) nicht gesetzt war. Solche Schlüssel wurden zwar als ,mit voller Länge' angekündigt, waren aber die Hälfte der Zeit über kleiner als angekündigt.

OpenSSH wird Warnungen ausgeben, wenn es solchen Schlüsseln begegnet. Um diese Warnungen loszuwerden, passe deine known_hosts-Datei an und ersetze die falsche Schlüssellänge (normalerweise ,1024') mit der richtigen (normalerweise ,1023').

X11/Agent-Weiterleitung funktioniert nicht

Prüfe deine ssh_config und sshd_config. Die voreingestellten Konfigurationsdateien schalten den Authentifikationsagenten und X11-Weiterleitung ab. Füge die Zeilen unten in die sshd_config ein, um sie zu aktivieren:

X11Forwarding yes

und füge die folgenden Zeilen in die ssh_config ein:

ForwardAgent yes

ForwardX11 yes

X11-Weiterleitung setzt eine funktionierende xauth(1)-Binary voraus. Unter OpenBSD befindet sie sich im xbase-Dateiset, was auf anderen Plattformen jedoch nicht der Fall sein muss. Für die portable OpenSSH muss xauth entweder während dem configure-Aufruf gefunden werden oder später mittels XauthLocation in der sshd_config(5) und ssh_config(5) angegeben werden.

Hinweis zur Agenten-Interoperabilität: Es gibt zwei unterschiedliche und inkompatible Agentweiterleitung-Mechanismen innerhalb des SSH2-Protokolls. OpenSSH hat immer eine Erweiterung der originalen SSH1-Agent-Anfragen genutzt, jedoch verwenden einige kommerzielle Produkte ein anderes, nicht freies Agentweiterleitungsprotokoll. Dies bedeutet, dass Agentweiterleitung nicht zwischen OpenSSH und diesen kommerziellen Produkten genutzt werden kann.

HINWEIS: Benutzer von Linux Mandrake 7.2: Mandrake modifiziert die XAUTHORITY-Umgebungsvariable in /etc/skel/.bashrc und damit das Heimatverzeichnis jedes Bash-Benutzers. Diese Variable wird von OpenSSH gesetzt und daher muss für die oben genannten Optionen die folgende Zeile auskommentiert werden:

# export XAUTHORITY=$HOME/.Xauthority

Keine SSH2-Unterstützung

Die Dateien sshd_config oder ssh_config können von Version zu Version verändert werden. Du solltest immer nach solchen Änderungen Ausschau halten, wenn du auf eine neue Version von OpenSSH upgradest. Nach OpenSSH 2.3.0 musst du das folgende in deine sshd_config einfügen:

HostKey /etc/ssh_host_dsa_key

HostKey /etc/ssh_host_rsa_key

sftp/scp kann keine Verbindung aufbauen

obwohl ssh funktioniert

sftp und/oder scp können beim Aufbauen der Verbindung Probleme haben, wenn du eine Shellinitialisierung (.profile, .bashrc, .chsrc etc.) hast, die Ausgaben für nicht interaktive Sitzungen produziert. Diese Ausgabe verwirrt den sftp/scp-Client. Hiermit kannst du prüfen, ob deine Shell das tut:

ssh yourhost /usr/bin/true

Wenn das Kommando oben irgendeine Art von Ausgabe produziert, musst du deine Shellinitialisierung modifizieren.

ssh-Verbindung friert ein oder steigt aus

ssh-Verbindung friert ein oder steigt nach N Minuten Inaktivität aus

Das ist üblicherweise das Resultat eines Paketfilters oder einem NAT-Gerät, das die TCP-Verbindung wegen Inaktivität auslaufen lässt. Du kannst ClientAliveInterval in der sshd_config des Servers aktivieren oder ServerAliveInterval in der ssh_config des Clients ermöglichen (die letzte Option ist in OpenSSH 3.8 und neuer verfügbar).

Das Aktivieren einer der beiden Optionen und das Setzen des Intervalls, das kürzer als die benötigte Zeit ist, um die Verbindung auslaufen zu lassen, sorgen dafür, dass die Verbindung in der Verbindungstabelle des Gerätes ,frisch' gehalten wird.

scp - Datei mit Doppelpunkt

scp interpretiert den Teil vor dem Doppelpunkt als Namen des entfernten Servers und versucht, eine Verbindung zu diesem aufzubauen. Um das zu verhindern, greife auf die Datei mit relativer oder absoluter Pfadangabe zu, z. B.:

$ scp ./source:file sshserver:

OpenSSH teilt Clients seine Version mit

OpenSSH, wie die meisten SSH-Implementationen, teilt seinen Namen und seine Version den Clients mit, wenn sie eine Verbindung aufbauen, z. B.

SSH-2.0-OpenSSH_3.9

Diese Information wird von den Clients und Servern verwendet, um Protokollkompatibilitätskniffe zu aktiveren, die veränderte, fehlerhafte oder fehlende Funktionen in der Implementation, mit der sie reden, zu umgehen. Dieser Protokollfunktionstest ist weiterhin nötig, weil noch immer Versionen mit Inkompatibilitäten im Umlauf sind.

Unechte PAM-Authentifikationsmeldungen in den Logdateien

Die portable Version von OpenSSH generiert unechte misslungene Authentifikationsmeldungen bei jedem Login, etwa wie:

"authentication failure; (uid=0) -> root for sshd service"

Diese werden erzeugt, weil OpenSSH zuerst versucht herauszufinden, ob der Anwender eine Authentifikation zum Login benötigt (z. B. leeres Passwort). Dummerweise logt PAM alle Authentifikationversuche, inklusive diesem hier.

Wenn es dich zu sehr stört, setze »PermitEmptyPasswords no« in sshd_config. Das wird die Meldung stilllegen, allerdings auf Kosten dessen, dass es nicht mehr möglich ist, sich in Accounts mit leeren Passwörtern einzuloggen. Das ist im übrigen bereits der Standard, wenn du die mitgelieferte sshd_config-Datei benutzt.

Leere Passwörter sind bei der PAM-Authentifikation nicht erlaubt

Um leere Passwörter in einer OpenSSH-Version zu erlauben, die mit PAM erzeugt wurde, musst du das ,nullok'-Flag an das Ende des Password-Checking-Moduls in der /etc/pam.d/sshd-Datei setzen. Zum Beispiel:

auth required/lib/security/pam_unix.so shadow nodelay nullok

Das muss zusätzlich zum Setzen von »PermitEmptyPasswords yes« in der sshd_config-Datei geschehen.

Es gibt einen Fallstrick beim Benutzen leerer Passwörter mit PAM-Authentifikation: PAM wird jegliches Passwort erlauben, wenn ein Account mit einem leeren Passwort authentifiziert wird. Das macht den Check, den sshd(8) benutzt, um zu prüfen, ob der Account ein Passwort gesetzt hat, wirkungslos und umgeht ebenso die Richtlinie, die von PermitEmptyPasswords gesetzt wurde. Aus diesem Grund raten wir davon ab, die nullok-Direktive in deiner PAM-Konfigurationsdatei zu setzen, es sei denn, du willst leere Passwörter explizit erlauben.

ssh(1) benötigt sehr lange zum Verbinden oder zum Einloggen

Große Verzögerungen (mehr als 10 Sekunden) werden normalerweise durch Probleme mit der Namensauflösung verursacht: * Einige Versionen der glibc (insbesondere glibc 2.1, die mit Red Hat 6.1 ausgeliefert wurde) können einen langen Zeitraum benötigen, um ,IPv6 zu IPv4'-Adressen von Domänennamen aufzulösen. Das kann umgangen werden, indem die Option AddressFamily inet in der ssh_config eingetragen wird.

Es könnte ein DNS-Auflösungsproblem vorliegen, entweder beim Client oder beim Server. Du kannst den nslookup-Befehl auf dem Client und dem Server verwenden, um den Namen und die IP-Adresse der Gegenseite auflösen zu lassen. Lass zusätzlich den Namen auf dem Server auflösen, den der Client beim Auflösen der IP-Adresse des Servers zurückgegeben hat. Du kannst die meisten Lookups serverseitig durch das Hinzufügen von UseDNS no in sshd_config deaktivieren.

Verzögerungen unter 10 Sekunden können andere Ursachen haben. * OpenSSH-Versionen vor 3.8 hatten eine moduli-Datei mit moduli, die kleiner waren als die, nach denen OpenSSH Ausschau hielt, und als Resultat würde sshd am Ende moduli verwenden, die beachtlich größer wären als die, die angefragt wurden, was auf Kosten der Geschwindigkeit geschah. Das Ersetzen der moduli-Datei wird das Problem lösen (bedenke, dass diese Datei bei einem Upgrade in den meisten Fällen nicht ausgetauscht wird und daher manuell ersetzt werden muss).

OpenSSH-Versionen vor 3.8 hatten einen Fehler in ssh, der dazu führte, dass es größere moduli anforderte als erwartet (was dann, in Kombination mit dem oben genannten Problem, in erheblichen Geschwindigkeitseinbußen endete). Ein Upgrade des Clients auf Version 3.8 oder höher wird das Problem beheben.
Falls entweder der Server oder der Client keinen kernelbasierten Zufallszahlengenerator besitzen (z. B. Solaris < 9, AIX < 5.2, HP-UX < 11.11) und kein Ersatz verfügbar ist (z. B. prngd), ist es möglich, dass ein Programm, das von ssh-rand-helper zum Generieren vom Entropy aufgerufen wird, hängt. Das kann ermittelt werden, indem es im Debug-Modus ausgeführt wird:

/usr/local/libexec/ssh-rand-helper -vvv

* Alle beachtlichen Verzögerungen sollten untersucht und behoben, oder aber die entsprechenden Befehle aus ssh_prng_cmds entfernt werden.

Wie langsam ist ,langsam'?

Unter normalen Umständen ist die Geschwindigkeit des SSH-Logins abhängig von der CPU-Leistung des Clients und Servers. Zum Vergleich folgen typische Verbindungszeiten für time ssh localhost true mit einem 1024-Bit-RSA-Schlüssel auf einem ansonsten ungenutzten System. OpenSSH und OpenSSL wurden mit gcc 3.3.x compiliert.

CPU	Zeit (SSHv1)[1]	Zeit (SSHv2)
170MHz SPARC/sun4m	0.74 Sek	1.25 Sek
236MHz HPPA/8200[2]	0.44 Sek	0.79 Sek
375MHz PowerPC/604e	0.38 Sek	0.51 Sek
933MHz VIA Ezra	0.34 Sek	0.44 Sek
2.1GHz Athlon 2600+	0.14 Sek	0.22 Sek

[1] Das SSHv1 Protokoll ist zwar schneller, aber kryptographisch schwächer als SSHv2.[2] Zu dem Zeitpunkt des Schreibens generiert gcc relativ langsamen Code auf HPPA für RSA- und Diffie-Hellman-Operationen (siehe gcc bug #7625 und Diskussion auf openssh-unix-dev).

Can't locate module net-pf-10

Der Linux-Kernel sucht (via modprobe) nach der Protokollfamilie 10 (IPv6). Lade entweder das passende Kernelmodul, gib den korrekten Alias in /etc/modules.conf an oder schalte IPv6 in /etc/modules.conf ab.

Aus irgendeinem blödsinnigen Grund kann /etc/modules.conf auch /etc/conf.modules heißen.

Passwortauthentifikation funktioniert nicht

Falls das Passwort das korrekte Passwort ist, und der Login weiterhin verwehrt bleibt, liegt die Ursache normalerweise darin, dass das System zwar mit MD5-Typ-Passwörtern arbeitet, aber die crypt(3)-Funktion, die von sshd verwendet wird, diese nicht verstehen kann.

Betroffene Passwörter haben eine Passwortzeichenkette in /etc/passwd oder /etc/shadow, die mit $1$ beginnt. Falls die Passwortauthentifikation für neue Accounts oder Accounts mit Passwörtern, die kürzlich aktualisiert wurden, fehlschlägt, aber mit alten Accounts funktioniert, dann ist dies wahrscheinlich das Problem.

Der Grund hierfür ist, dass einige Versionen von OpenSSL eine crypt(3)-Funktion haben, die keine MD5-Passwörter versteht, und die ,link'-Reihenfolge von sshd führt dazu, dass OpenSSLs crypt(3) und nicht das vom System genutzt wird. OpenSSHs configure versucht dies zu korrigieren aber ist damit nicht immer erfolgreich.

Es gibt einige mögliche Lösungen: * Aktiviere sshds eingebaute Unterstützung für MD5-Passwörter während der Erzeugungsphase.

./configure --with-md5-passwords [Optionen] Dies ist sogar dann sicher, wenn du beide Verschlüsselungstypen verwendest, da sshd den korrekten Algorithmus für jeden Account automatisch auswählt. * Wenn dein System eine separate libcrypt-Bibliothek hat (z. B. Slackware 7), dann kannst du manuell -lcrypt zur LIBS-Liste einfügen, sodass es statt OpenSSLs verwendet wird:

LIBS=-lcrypt ./configure [Optionen] * Wenn deine Plattform PAM unterstützt, könntest du sshd so konfigurieren, dass es dieses verwendet (siehe Sektion 3.15). Das bedeutet, dass sshd Passwörter nicht selbst überprüfen wird, sondern es an die konfigurierten PAM-Module übergibt.

fehlende RSA- oder DSA-Unterstützung

Configure oder sshd(8) beschweren sich über fehlende RSA- oder DSA-Unterstützung

Stelle sicher, dass deine OpenSSL-Bibliotheken mit eingebauter RSA- oder DSA-Unterstützung erzeugt wurden, entweder intern oder durch RSAref.

»scp: command not found«-Fehler

scp(1) muss sich im Standard-PATH sowohl auf dem Client als auch auf dem Server befinden. Möglicherweise musst du die Option --with-default-path angeben, um einen angepassten Pfad für die Suche auf dem Server angeben zu können. Diese Option ersetzt den Standardpfad, sodass du sowohl alle bisherigen Verzeichnisse in deinem Pfad angeben musst als auch das Verzeichnis, in dem scp installiert ist. Zum Beispiel:

$ ./configure --with-default-path=/bin:/usr/bin:/usr/local/bin:/path/to/scp

Bedenke, dass die Konfiguration des Administrators des Servers Vorrang gegenüber der Option --with-default-path hat. Das beinhaltet das Rücksetzen von PATH in /etc/profile, PATH in /etc/environment unter AIX oder (für 3.7p1 und höher) das Setzen von PATH oder SUPATH in /etc/default/login unter Solaris oder Reliant Unix.

Kann die Passphrase nicht lesen

Einige Betriebssysteme setzen /dev/tty mit falschen Modi, was zum Fehler beim Lesen von Passwörtern mit folgender Fehlermeldung führt:

You have no controlling tty. Cannot read passphrase.

Die Lösung hierzu ist, die Berechtigungen von /dev/tty auf 0666 zu setzen und dann das ganze deinem Betriebssystem-Hersteller als Fehler zu melden.

configure fehlt oder make versagt

Wenn es keine configure-Datei in deiner tar.gz-Datei gibt, die du heruntergeladen hast, oder make mit einem ,missing seperator'-Fehler versagt, hast du vermutlich die OpenBSD-Distribution heruntergeladen und versuchst, sie auf einer anderen Plattform zu kompilieren. Bitte verwende die portable Version.

Hängt beim Verlassen von ssh

OpenSSH kann beim Beenden hängen bleiben. Das kann passieren, wenn es einen aktiven Hintergrundprozess gibt. Linux und HP-UX sind hierfür bekannt. Das Problem kann hiermit verifiziert werden:

$ sleep 20 & exit

Versuche stattdessen das hier zu benutzen:

$ sleep 20 < /dev/null > /dev/null 2>&1 &

Ein Umgehen des Problems für bash-Anwender ist mittels eines Einfügens von "shopt -s huponexit" in entweder /etc/bashrc oder ~/.bashrc möglich. Ansonsten konsultiere die Handbuchseite deiner Shell um eine Option zu finden, mit der man aktiven Jobs ein HUP-Signal senden kann, wenn man sie verlässt. Siehe bug #52 für andere Möglichkeiten, das Problem umgehen zu können.

Wieso hängt ssh beim Beenden?

Beim Ausführen von

$ ssh host command

muss ssh hängen bleiben, da es zu warten hat * bis es sicherstellen kann, dass command keine weiteren Eingaben benötigt.

bis es sicherstellen kann, dass command keine weitere Ausgaben zurückgibt.
bis command beendet ist, da der sshd den Exitstatus von command an ssh weitergeben muss.

X11-Weiterleitung funktioniert nicht mehr

Ich habe ein Upgrade auf OpenSSH 3.1 durchgeführt und dann ging die X11-Weiterleitung nicht mehr.

Beginnend mit OpenSSH 3.1 lauscht der sshd-X11-Weiterleitungsserver standardmäßig auf localhost; siehe auch die Option X11UseLocalhost von sshd, um zum vorherigen Verhalten zurückzukehren, wenn deine älteren X11-Clients nicht mit dieser Konfiguration funktionieren.

Im Allgemeinen sollten X11-Clients, die X11 R6 benutzen, mit dieser Einstellung funktionieren. Einige Hersteller, einschließlich HP, setzen X11-Clients mit R6- und R5-Bibliotheken ein, sodass einige Clients funktionieren und andere nicht. Das gilt z. B. für HP-UX 11.X.

X11-Programme funktionieren nicht mehr

Ich habe ein Upgrade auf OpenSSH 3.8 durchgeführt und dann gingen einige X11-Programme nicht mehr.

Wie in den 3.8 release notes dokumentiert worden ist, wird ssh standardmäßig ,untrusted X11 cookies' benutzen. Das vorherige Verhalten kann durch das Setzen von ForwardX11Trusted yes in sshd_config wiederhergestellt werden.

Mögliche Symptome beinhalten:

BadWindow (invalid Window parameter)
BadAccess (attempt to access private resource denied)
X Error of failed request: BadAtom (invalid Atom parameter)
Major opcode of failed request: 20 (X_GetProperty)

Publickey-Authentifizierung funktioniert nicht

Ich habe meinen öffentlichen Schlüssel in authorized_keys kopiert, aber Publickey-Authentifizierung funktioniert immer noch nicht.

Typischerweise wird das durch die Dateirechte von $HOME, $HOME/.ssh oder $HOME/.ssh/authorized_keys hervorgerufen, die mehr erlauben als sshd standardmäßig zulässt.

In diesem Falle kann es behoben werden, indem Folgendes auf dem Server ausgeführt wird.

$ chmod go-w $HOME $HOME/.ssh

$ chmod 600 $HOME/.ssh/authorized_keys
$ chown `whoami` $HOME/.ssh/authorized_keys

Falls das aus irgendeinem Grund nicht möglich sein sollte, besteht die Alternative darin, StrictModes no in sshd_config zu setzen, jedoch wird das nicht empfohlen.

OpenSSH-Versionen und das Verhalten von PAM.

Das portable OpenSSH hat eine Option, die während der Konfigurationsphase gesetzt werden kann, um sshds Nutzung des PAM- (Pluggable Authentication Modules) Interfaces zu aktivieren.

./configure --with-pam [Optionen]

Um PAM auf irgendeine Weise nutzen zu können, muss diese Option während der Erzeugungsphase gesetzt sein. Das Laufzeit-Verhalten, wenn PAM erzeugt wurde, variiert mit der Version des portablen OpenSSH, und spätere Versionen müssen es ebenfalls mit dem Setzen von UsePAM auf yes in sshd_config aktivieren.

Das Verhalten der relevanten Authentifikations-Optionen, wenn PAM-Unterstützung integriert wurde, ist in der folgenden Tabelle zusammengefasst.

Version	UsePAM	PasswordAuthentication	ChallengeResponseAuthentication
<=3.6.1p2	Nicht nutzbar	Verwendet PAM	Verwendet PAM, wenn PAMAuthenticationViaKbdInt aktiv ist
3.7p1 - 3.7.1p1	Standard ist yes	Verwendet nicht PAM	Verwendet PAM, wenn UsePAM aktiv ist
3.7.1p2 - 3.8.1p1	Standard ist no	Verwendet nicht PAM [1]	Verwendet PAM, wenn UsePAM aktiv ist
3.9p1	Standard ist no	Verwendet PAM, wenn UsePAM aktiv ist	Verwendet PAM, wenn UsePAM aktiv ist

[1] Einige Verkäufer, insbesondere Redhat/Fedora, haben die Passwortauthentifikation von 3.9p1 auf ihre 3.8x-basierten Pakete zurückportiert. Wenn du ein Paket nutzt, das von einem Verkäufer bereitgestellt wurde, konsultiere bitte dessen Dokumentation.

,OpenSSH Portable's PAM-Interface hat immer noch Probleme mit ein paar Modulen, jedoch hoffen wir, dass wir diese Anzahl in Zukunft verringern können. Zum Zeitpunkt der Veröffentlichung von 3.9p1 sind folgende Probleme bekannt: * Module, die sich auf ,module-private' Daten verlassen (z. B. pam_dhkeys, pam_krb5, AFS) können darin fehlschlagen, korrekte ,Credentials' zu erzeugen (Fehler #688) wenn über ChallengeResponseAuthentication authentifiziert wird. PasswordAuthentication mit 3.9p1 und neuer sollten funktionieren.

Du kannst außerdem bugzilla für aktuelle PAM-Probleme durchsehen.

»w« noch »who« unter AIX 5.x

Warum zeigen weder »w« noch »who« unter AIX 5.x Benutzer an, die über ssh eingeloggt sind?

Zwischen AIX 4.3.3 und AIX 5.x wurde das Format vom »wtmp struct« geändert. Das bedeutet, dass sshd-Binarys, die unter AIX 4.x erzeugt wurden, keine korrekten wtmp-Einträge schreiben, wenn sie unter AIX 5.x ausgeführt werden. Dies kann behoben werden, indem einfach sshd auf einem AIX-5.x-System neukompiliert und dieser dann eingesetzt wird.

Tools und Erweiterungen

Sicherheit

fail2ban

Bans IP addresses that make too many authentication failures

Fail2ban scans log files like /var/log/messages and bans IP addresses that makes too many password failures. It updates firewall rules to reject the IP address, can send e-mails, or set host.deny entries. These rules can be defined by the user. Fail2Ban can read multiple log files such as sshd or Apache web server ones.

sshguard

Protect hosts from brute force attacks against ssh

Sshguard protects networked hosts from brute force attacks against ssh servers. It detects such attacks and blocks the attacker's address with a firewall rule.

denyhosts

Utility to help system administrators thwart brute-force ssh hackers

DenyHosts is a python program that automatically blocks ssh attacks by adding entries to /etc/hosts.deny. DenyHosts will also inform Linux administrators about offending hosts, attacked users and suspicious logins.

ScanSSH

ScanSSH supports scanning a list of addresses and networks for open proxies, SSH protocol servers, Web and SMTP servers. Where possible ScanSSH, displays the version number of the running services. ScanSSH protocol scanner supports random selection of IP addresses from large network ranges and is useful for gathering statistics on the deployment of SSH protocol servers in a company or the Internet as whole.

http://www.monkey.org/~provos/scanssh/

SSH-Serverversionen scannen

Um die Überwachung der verwendeten SSH-Server zu erleichtern (z. B. in einem Firmennetzwerk) hat Niels Provos das scanssh-Tool geschrieben. scanssh prüft eine Liste von Adressen und Netzwerken auf die Verwendung von SSH-Servern und ihrer Versionsnummern hin. Es unterstützt die zufällige Auswahl von IP-Adressen innerhalb großer Netzwerkbereiche und ist einfach nützlich, um Statistiken über die Verwendung von SSH-Servern in einer Firma oder dem Internet an sich zu erhalten. Die Statistiken enthalten sowohl die unterstützten SSH-Protokolle als auch die benutzten Softwareversionen.

scanssh wird benutzt, um die Statistiken über die Verbreitung und Benutzung der SSH-Protokolle im Internet zu erhalten. Die Messungen erlauben Einblicke in die Verbreitung der verschiedenen SSH-Protokolle und der Marktdurchdringung bestimmter Serverversionen.

Authentifizierung

pam_ssh

PAM Module for SSH Authentication

This module provides single sign-on behavior. The user types a passphrase when logging in and is allowed in if it decrypts the user s SSH private key. An ssh-agent is started and keys are added. For the entire session, the user types no more passwords.

Automatisierung

clusterssh

Multiplex SSH sessions onto many hosts using multiple terminals

Cluster SSH opens terminal windows with connections to specified hosts and an administration console. Any text typed into the administration console is replicated to all other connected and active windows.

This tool is intended for, but not limited to, cluster administration where the same configuration or commands must be run on each node within the cluster. Performing these commands all at once via this tool ensures all nodes are kept in sync.

Datei:Grafik68.png

pssh

Parallel SSH to control large numbers of Machines simultaneously

pssh provides parallel versions of the OpenSSH tools that are useful for controlling large numbers of machines simultaneously. It includes parallel versions of ssh, scp, and rsync, as well as a parallel kill command.

sshfp

RFC4255 DNS SSHFP record generator

sshfp generates DNS SSHFP records from SSH public keys. sshfp can take public keys from a knownhosts file or from scanning the host's sshd daemon. The ssh client can use these SSHFP records if you set "VerifyHostKeyDNS yes" in the file /etc/ssh/ssh_config.

Tunnel

autossh

Automatically restart SSH sessions and tunnels

Autossh is a program to start a copy of ssh and monitor it, restarting it as necessary should it die or stop passing traffic. The idea and the mechanism are from rstunnel (Reliable SSH Tunnel), but implemented in C. The author's view is that it is not as fiddly as rstunnel to get to work. Connection monitoring using a loop of port forwardings. Backs off on rate of connection attempts when experiencing rapid failures such as connection refused.

httptunnel-la

Tunnel Arbitrary TCP Connections over HTTP

HTTPTunnel is a simple client/server application for creating an HTTP tunnel between two machines, optionally via a Web proxy. This tunnel can then be used to wrap arbitrary TCP socket traffic in HTTP, thus allowing communications even through a restrictive firewall that only allows outgoing HTTP connections.

sslh

SSL/SSH multiplexer

sslh lets one accept both HTTPS and SSH connections on the same port. It makes it possible to connect to an SSH server on port 443 (e.g. from inside a corporate firewall) while still serving HTTPS on that port.

sshuttle

Transparent Proxy VPN

Transparent proxy server that works as a poor man's VPN. Forwards over ssh. Doesn't require admin. Works with Linux and MacOS. Supports DNS tunneling.

Quellen und Informationen

Weblinks

de.wikipedia.org/wiki/Ssh
wiki.ubuntuusers.de/ssh
de.wikipedia.org/wiki/Transport_Layer_Security
www.openssh.org
www.openssl.org

Wo sollte ich um Hilfe fragen?

Es gibt mehrere Stellen, die du um Hilfe bitten kannst. Zusätzlich zur OpenSSH-Webseite gibt es mehrere Mailinglisten, in denen du dein Glück versuchen kannst. Bevor du das tust, durchsuche bitte alle Mailinglisten-Archive um zu sehen, ob deine Frage vielleicht schon beantwortet wurde. Die OpenSSH-Mailingliste wurde archiviert und steht in durchsuchbarer Form unter marc.info. zur Verfügung.

Mehr Informationen über das Abonnieren von OpenSSH-bezogenen Mailinglisten gibt es unter OpenSSH-Mailinglisten.

Ich habe einen Fehler gefunden. Wo melde ich ihn?

Informationen zum Senden von Fehlermeldungen können auf der OpenSSH ,Fehler melden'-Seite gefunden werden.

Wenn du eine Sicherheitslücke melden möchtest, kontaktiere bitte die private Liste »openssh@openssh.com«.

Handbuchseiten

Web-Handbuchseiten sind von OpenBSD für die folgenden Kommandos verfügbar. Diese Handbuchseiten reflektieren die letzte Entwicklungsversion von OpenSSH.

ssh(1)	Das rlogin/rsh-ähnliche Basis-Clientprogramm.
sshd(8)	Der Daemon, der dir erlaubt, dich einzuloggen.
ssh_config(5)	Die Konfigurationsdatei des Clients.
sshd_config(5)	Die Konfigurationsdatei des Daemons.
ssh-agent(1)	Ein Authentifikationsagent, der private Schlüssel verwalten kann.
ssh-add(1)	Werkzeug, das zum obigen Agenten neue Schlüssel hinzufügt.
sftp(1)	FTP-ähnliches Programm, das sowohl unter dem SSH1- als auch dem SSH2-Protokoll läuft.
scp(1)	Dateikopierprogramm, das sich wie rcp(1) verhält.
ssh-keygen(1)	Schlüsselerzeugungs-Werkzeug.
sftp-server(8)	SFTP-Server-Subsystem (wird automatisch von sshd gestartet).
ssh-keyscan(1)	Werkzeug, um öffentliche Hostschlüssel von verschiedenen anderen Hosts zu holen.
ssh-keysign(8)	Hilfsprogramm für hostbasierte Authentifikation.

Die Arbeitsweisen des SSH2-Protokolls, das in OpenSSH implementiert ist, wurde von der IETF-secsh-Arbeitsgruppe standardisiert und ist in verschiedenen Entwürfen definiert. Die umfassende Struktur von SSH2 ist im architecture-RFC beschrieben. Es besteht aus drei aufeinander aufbauenden Komponenten: * Die Transportschicht stellt die Algorithmusvereinbarung und den Schlüsselaustausch zur Verfügung. Der Schlüsselaustausch schließt die Serverauthentifikation und die Resultate in einer kryptographisch gesicherten Verbindung mit ein: Er enthält Integrität, Vertraulichkeit und optionale Kompression.

Die Benutzer-Authentifikationsschicht benutzt die hergestellte Verbindung und benötigt die Dienste, die von der Transportschicht bereitgestellt werden. Er bietet verschiedene Mechanismen zur Benutzerauthentifikation. Das beinhaltet traditionelle Passwortauthentifikation genauso wie ,public-key'- oder hostbasierte Authentifikationsmechanismen.

Die Verbindungsschicht multiplext viele verschiedene gleichzeitige Kanäle über die authentifizierte Verbindung und erlaubt das Tunneln von ,login sessions' und TCP-Weiterleitung. Sie stellt einen ,flow control service' für diese Kanäle bereit. Zusätzlich können verschiedene kanalspezifische Optionen verhandelt werden.

Zusätzliche Dokumente

Der RFC für interaktive Authentifikation bietet Unterstützung für neue Authentifikationsschemata wie etwa S/Key oder TIS.
Das SFTP-Dateitransferprotokoll wird im filexfer-Dokument spezifiziert. OpenSSH implementiert einen SFTP-client und -server.
Ein Dateiformat für öffentliche Schlüssel wird im publickeyfile-Dokument spezifiziert. Der Befehl ssh-keygen(1) kann benutzt werden, um einen OpenSSH-,public key' in dieses Dateiformat zu überführen.
Die Diffie-Hellman Group Exchange erlaubt es Clients, nach sichereren Gruppen für den Diffie-Hellman-Schlüsselaustausch zu fragen.
OpenSSH hat eine Kompressionsmethode namens »zlib@openssh.com« implementiert, die erst nach der Benutzerauthentifikation mit der Kompression beginnt, um jegliche Angriffe vor der Authentifikation zu unterbinden. Es wird in draft-miller-secsh-compression-delayed-00.txt beschrieben.
OpenSSH implementiert einen zusätzlichen MAC (Message Authentication CODE) namens »umac-64@openssh.com«, der eine bessere Performance hat als jene, die im RFC 4253 beschrieben werden. Er wird in draft-miller-secsh-umac-01.txt beschrieben.
Das Authentifikationagentenprotokoll, das von ssh-agent verwendet wird, wird in der Datei PROTOCOL.agent beschrieben.
OpenSSH macht weitere kleine Erweiterungen oder weicht von den Standard-SSH-Protokollen ab. Diese werden in der Datei PROTOCOL beschrieben.
Es gibt auch eine Mailingliste für generelle Diskussionen über das SSH2-Protokoll (ietf-ssh@netbsd.org).

Spezifikationen (OpenSSH)

OpenSSH implementiert die folgenden Spezifikationen.

SSH Protokollversion 1

ssh-rfc-v1.3.txt	SSH Protokollversion 1.3
ssh-rfc-v1.5.txt	SSH Protokollversion 1.5

SSH Protokollversion 2 Kern-RFCs

Quelle: secsh working group

rfc4250.txt		Dem SSH-Protokoll zugewiesene Nummern und Werte
rfc4251.txt		SSH Protokollarchitektur
rfc4252.txt		SSH Authentifizierungs-Protokoll
rfc4253.txt	(e)	SSH Transportschicht-Protokoll
rfc4254.txt		SSH Verbindungs-Protokoll

SSH Protokollversion 2, Erweiterungs-RFCs

rfc4255.txt	(e)	Die Nutzung von DNS zur sicheren Veröffentlichung von Fingerabdrücken von SSH-Schlüsseln (SSHFP)
rfc4256.txt	(e)	Generische Authentifizierung über den Austausch von Botschaften (»keyboard-interactive«)
rfc4335.txt	(e)	»BREAK«-Erweiterung des SSH-Sitzungskanals
rfc4344.txt		Verschlüsselungsmethoden für die SSH Transportschicht
rfc4345.txt		Verbesserte Arcfour-Methoden für das SSH Transportschicht-Protokoll
rfc4419.txt		Diffie-Hellman Methode zum Austausch von Gruppen
rfc4462.txt	(e)	GSS-API Authentifizierung und Schlüsselaustausch (einzig Authentifizierung ist im Moment implementiert)
rfc4462.txt		Dateiformat des öffentlichen SSH-Schlüssels
rfc5656.txt	(e)	Integration des »Elliptic Curve Algorithm« in SSH
rfc6594.txt	(e)	SHA-256 SSHFP Ressourceneinträge (neu in OpenSSH 6.1).
rfc6668.txt		SHA-2 Datenintegritätsalgorithmus (neu in OpenSSH 5.9)

SSH Protokollversion 2 - Spezifikationsentwürfe

draft-ietf-secsh-filexfer-02.txt

SSH Dateiübertragungs-Protokoll, Version 3

SSH Protokollversion 2 - Anbietererweiterungen.

usr/bin/ssh/PROTOCOL	Ein Überblick über alle unten aufgeführten Anbietererweiterungen sowie der Spezifikationen der SSH2-Erweiterungen `eow@openssh.com`, `no-more-sessions@openssh.com`, `tun@openssh.com` und der SFTP-Erweiterungen `posix-rename@openssh.com`, `statvfs@openssh.com`, `fstatvfs@openssh.com`
draft-miller-secsh-umac-01.txt	`umac-64@openssh.com`: ein neuer MAC für die Transportschicht.
draft-miller-secsh-compression-delayed-00.txt	`zlib@openssh.com`: Verzögerung der Kompression bis nach erfolgter Authentifierung.
usr/bin/ssh/PROTOCOL.certkeys	`ssh-rsa-cert-v00@openssh.com`, `ssh-dsa-cert-v00@openssh.com`, `ecdsa-sha2-nistp256-cert-v01@openssh.com`, `ecdsa-sha2-nistp384-cert-v01@openssh.com`, `ecdsa-sha2-nistp521-cert-v01@openssh.com`: neue Algorithmen für öffentliche Schlüssel, die Zertifikate unterstützen.
curve25519-sha256@libssh.org.txt	`curve25519-sha256@libssh.org` Schlüsselaustauschmethode.

Andere Spezifikationen

socks4.protocol	SOCKS Protokollversion 4. Genutzt für `ssh -D`.
socks4a.protocol	SOCKS Protokollversion 4a. Genutzt für `ssh -D`.
rfc1928.txt	SOCKS Protokollversion 5. Genutzt für `ssh -D`.
rfc1349.txt rfc2597.txt rfc2598.txt	»IP Type of Service« (ToS) und »Differentiated Services«. ssh und sshd setzen automatisch den ToS, wie es von RFC 1349 verlangt wird, es sei denn es wird durch Nutzung des Schlüsselworts `IPQoS` in den Dateien ssh_config und sshd_config eine Rekonfiguration vorgenommen.

OpenSSH

Ein aktualisiertes Paket wurde mit DSA-1576 herausgegeben, das die Schlüsseltransformation vereinfacht.

1. Installieren Sie die Sicherheitsaktualisierungen aus DSA-1576

Sobald die Aktualisierung eingespielt wurde, werden schwache Benutzerschlüssel, wenn möglich, automatisch zurückgewiesen (diese können aber nicht in allen Fällen erkannt werden). Falls Sie solche Schlüssel für die Benutzerauthentifizierung verwenden, werden sie ab sofort nicht mehr funktionieren und müssen ersetzt werden (siehe Schritt 3).

OpenSSH-Rechner-Schlüssel können automatisch neu erzeugt werden, wenn die OpenSSH-Sicherheitsaktualisierung eingespielt wurde. Die Aktualisierung wird nach Bestätigung fragen, bevor dieser Schritt durchgeführt wird.

2. Aktualisierung der OpenSSH-Dateien known_hosts

Die Neuerzeugung der Rechnerschlüssel wird eine Warnung ausgeben, wenn auf das System mit SSH zugegriffen wird, bis der Rechnerschlüssel in der Datei known_hosts auf dem Klient aktualisiert wurde. Die Warnung wird wie folgt aussehen:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed.

Auf Deutsch lautet diese Meldung in etwa wie folgt:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: IDENTIFIZIERUNG DES ENTFERNTES RECHNERS HAT SICH GEÄNDERT @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ ES IST MÖGLICH, DASS JEMAND ETWAS BÖSES TUT! Jemand könnte Sie zurzeit abhören (man-in-the-middle-(Mann in der Mitte)-Angriff)! Es ist auch möglich, dass der RSA-Rechnerschlüssel vor kurzem geändert wurde.

In diesem Fall wurde der Rechnerschlüssel einfach geändert und Sie sollten die entsprechende Datei known_hosts, wie in der Meldung beschrieben, aktualisieren. Es wird empfohlen, dass Sie einen vertrauenswürdigen Kanal zum Austausch des Server-Schlüssels verwenden. Er befindet sich in der Datei /etc/ssh/ssh_host_rsa_key.pub auf dem Server; sein Fingerabdruck kann mit dem folgenden Kommando gedruckt werden:

ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub

Zusätzlich zu benutzerspezifischen known_hosts-Dateien, kann eine systemweite Datei /etc/ssh/ssh_known_hosts existieren. Diese Datei wird sowohl vom ssh-Klient als auch von sshd für die hosts.equiv-Funktionalität verwendet. Diese Datei muss auch aktualisiert werden.

3. Überprüfen aller OpenSSH-Benutzerschlüssel

Der sicherste Weg ist es, alle OpenSSH-Benutzerschlüssel neu zu erzeugen, es sei denn, es kann mit ausreichender Bestimmtheit sichergestellt werden, dass der Schlüssel auf einem nicht betroffenen System erstellt wurde.

Um zu testen, ob Ihr Schlüssel betroffen ist, können Sie ssh-vulnkey starten, was in der Sicherheitsaktualisierung enthalten ist. Standardmäßig wird ssh-vulnkey den Standardort für Benutzerschlüssel (~/.ssh/id_rsa, ~/.ssh/id_dsa und ~/.ssh/identity), Ihre Datei authorized_keys (~/.ssh/authorized_keys und ~/.ssh/authorized_keys2) und die Rechnerschlüssel des Systems (/etc/ssh/ssh_host_dsa_key und /etc/ssh/ssh_host_rsa_key) überprüfen.

Sie können alle Ihre eigenen Schlüssel wie folgt testen, unter der Voraussetzung, dass sie sich an den Standardorten (~/.ssh/id_rsa, ~/.ssh/id_dsa oder ~/.ssh/identity) befinden:

ssh-vulnkey

Um alle Schlüssel auf Ihrem System zu überprüfen:

sudo ssh-vulnkey -a

Um einen Schlüssel an einem nicht standardmäßigem Ort zu testen:

ssh-vulnkey /Pfad/zum/Schlüssel

Falls ssh-vulnkey die Meldung Unknown (no blacklist information) ausgibt, hat es keine Informationen darüber, ob der Schlüssel betroffen ist. Im Zweifelsfall sollte der Schlüssel zerstört und ein neuer erzeugt werden.

4. Neuerzeugen beliebiger betroffener Benutzerschlüssel

Für die Benutzerauthentifizierung verwendete OpenSSH-Schlüssel müssen manuell neu erzeugt werden, inklusive derjenigen, die nach der Erzeugung auf ein anderes System übertragen wurden.

Neue Schlüssel können mit ssh-keygen erzeugt werden, z.B.:

$ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/user/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/id_rsa. Your public key has been saved in /home/user/.ssh/id_rsa.pub. The key fingerprint is: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 user@host

5. Aktualisierung der authorized_keys-Dateien (falls nötig)

Sobald die Benutzerschlüssel neu erzeugt wurden, müssen die relevanten öffentlichen Schlüssel in authorized_keys-Dateien (und eventuell authorized_keys2-Dateien) auf entfernten Systemen übertragen werden. Stellen Sie sicher, dass die betroffenen Schlüssel gelöscht werden.

SSH Hostkeys generieren

rm /etc/ssh/ssh_host_*

/usr/bin/ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_key -N ""

/usr/bin/ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ""

/usr/bin/ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ""

ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key

Secure Secure Shell

2015-01-04 crypto, nsa, and ssh

You may have heard that the NSA can decrypt SSH at least some of the time. If you have not, then read the latest batch of Snowden documents now. All of it. This post will still be here when you finish. My goal with this post here is to make NSA analysts sad.

TL;DR: Scan this post for fixed width fonts, these will be the config file snippets and commands you have to use.

Warning: You will need a recent OpenSSH version. It should work with 6.5 but I have only tested 6.7 and connections to Github. Here is a good compatibility matrix.

The crypto

Reading the documents, I have the feeling that the NSA can 1) decrypt weak crypto and 2) steal keys. Let’s focus on the crypto first. SSH supports different key exchange algorithms, ciphers and message authentication codes. The server and the client choose a set of algorithms supported by both, then proceed with the key exchange. Some of the supported algorithms are not so great and should be disabled completely. This hurts interoperability but everyone uses OpenSSH anyway. Fortunately, downgrade attacks are not possible because the supported algorithm lists are included in the key derivation. If a man in the middle were to change the lists, then the server and the client would calculate different keys.

Key exchange

There are basically two ways to do key exchange: Diffie-Hellman and Elliptic Curve Diffie-Hellman. Both provide forward secrecy which the NSA hates because they can’t use passive collection and key recovery later. The server and the client will end up with a shared secret number at the end without a passive eavesdropper learning anything about this number. After we have a shared secret we have to derive a cryptographic key from this using a key derivation function. In case of SSH, this is a hash function.

DH works with a multiplicative group of integers modulo a prime. Its security is based on the hardness of the discrete logarithm problem.

Alice Bob --------------------------- Sa = random Pa = g^Sa --> Pa

               Sb = random

Pb <-- Pb = g^Sb s = Pb^Sa s = Pa^Sb k = KDF(s) k = KDF(s)

ECDH works with elliptic curves over finite fields. Its security is based on the hardness of the elliptic curve discrete logarithm problem.

Alice Bob --------------------------- Sa = random Pa = Sa * G --> Pa

               Sb = random

Pb <-- Pb = Sb * G s = Sa * Pb s = Sb * Pa k = KDF(s) k = KDF(s)

OpenSSH supports 8 key exchange protocols:# curve25519-sha256: ECDH over Curve25519 with SHA2

diffie-hellman-group1-sha1: 1024 bit DH with SHA1
diffie-hellman-group14-sha1: 2048 bit DH with SHA1
diffie-hellman-group-exchange-sha1: Custom DH with SHA1
diffie-hellman-group-exchange-sha256: Custom DH with SHA2
ecdh-sha2-nistp256: ECDH over NIST P-256 with SHA2
ecdh-sha2-nistp384: ECDH over NIST P-384 with SHA2
ecdh-sha2-nistp521: ECDH over NIST P-521 with SHA2

We have to look at 3 things here:* ECDH curve choice: This eliminates 6-8 because NIST curves suck. They leak secrets through timing side channels and off-curve inputs. Also, NIST is considered harmful and cannot be trusted.

Bit size of the DH modulus: This eliminates 2 because the NSA has supercomputers and possibly unknown attacks. 1024 bits simply don’t offer sufficient security margin.
Security of the hash function: This eliminates 2-4 because SHA1 is broken. We don’t have to wait for a second preimage attack that takes 10 minutes on a cellphone to disable it right now.

We are left with 1 and 5. 1 is better and it’s perfectly OK to only support that but for interoperability (with Eclipse, WinSCP), 5 can be included.

Recommended /etc/ssh/sshd_config snippet:

KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

Recommended /etc/ssh/ssh_config snippet:

# Github needs diffie-hellman-group-exchange-sha1 some of the time but not always. #Host github.com # KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1

Host *

   KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

If you chose to enable 5, open /etc/ssh/moduli if exists, and delete lines where the 5th column is less than 2000.

awk '$5 > 2000' /etc/ssh/moduli > "${HOME}/moduli" wc -l "${HOME}/moduli" # make sure there is something left mv "${HOME}/moduli" /etc/ssh/moduli

If it does not exist, create it:

ssh-keygen -G /etc/ssh/moduli.all -b 4096 ssh-keygen -T /etc/ssh/moduli.safe -f /etc/ssh/moduli.all mv /etc/ssh/moduli.safe /etc/ssh/moduli rm /etc/ssh/moduli.all

This will take a while so continue while it’s running.

Authentication

The key exchange ensures that the server and the client shares a secret no one else knows. We also have to make sure that they share this secret with each other and not an NSA analyst.

Server authentication

The server proves its identity to the client by signing the key resulting from the key exchange. There are 4 public key algorithms for authentication:# DSA with SHA1

ECDSA with SHA256, SHA384 or SHA512 depending on key size
Ed25519 with SHA512
RSA with SHA1

DSA keys must be exactly 1024 bits so let’s disable that. Number 2 here involves NIST suckage and should be disabled as well. Another important disadvantage of DSA and ECDSA is that it uses randomness for each signature. If the random numbers are not the best quality, then it is possible to recover the secret key. Fortunately, RSA using SHA1 is not a problem here because the value being signed is actually a SHA2 hash. The hash function SHA1(SHA2(x)) is just as secure as SHA2 (it has less bits of course but no better attacks).

Protocol 2 HostKey /etc/ssh/ssh_host_ed25519_key HostKey /etc/ssh/ssh_host_rsa_key

The first time you connect to your server, you will be asked to accept the new fingerprint.

This will also disable the horribly broken v1 protocol that you should not have enabled in the first place. We should remove the unused keys and only generate a large RSA key and an Ed25519 key. Your init scripts may recreate the unused keys. If you don’t want that, remove any ssh-keygen commands from the init script.

cd /etc/ssh rm ssh_host_*key* ssh-keygen -t ed25519 -f ssh_host_ed25519_key < /dev/null ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key < /dev/null

Client authentication

The client must prove its identity to the server as well. There are various methods to do that.

The simplest is password authentication. This should be disabled immediately after setting up a more secure method because it allows compromised servers to steal passwords. Password authentication is also more vulnerable to online bruteforce attacks.

Recommended /etc/ssh/sshd_config snippet:

PasswordAuthentication no ChallengeResponseAuthentication no

Recommended /etc/ssh/ssh_config snippet:

Host *

   PasswordAuthentication no
   ChallengeResponseAuthentication no

The most common and secure method is public key authentication, basically the same process as the server authentication.

Recommended /etc/ssh/sshd_config snippet:

PubkeyAuthentication yes

Recommended /etc/ssh/ssh_config snippet:

Host *

   PubkeyAuthentication yes
   HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa

Generate client keys using the following commands:

ssh-keygen -t ed25519 -o -a 100 ssh-keygen -t rsa -b 4096 -o -a 100

You can deploy your new client public keys using ssh-copy-id.

It is also possible to use OTP authentication to reduce the consequences of lost passwords. Google Authenticator is a nice implementation of TOTP, or Timebased One Time Password. You can also use a printed list of one time passwords or any other PAM module, really, if you enable ChallengeResponseAuthentication.

User Authentication

Even with Public Key authentication, you should only allow incoming connections from expected users. The AllowUsers setting in sshd_config lets you specify users who are allowed to connect, but this can get complicated with a large number of ssh users. Additionally, when deleting a user from the system, the username is not removed from sshd_config, which adds to maintenance requirements. The solution is to use the AllowGroups setting instead, and add users to an ssh-user group.

Recommended /etc/ssh/sshd_config snippet:

AllowGroups ssh-user

Create the ssh-user group with sudo groupadd ssh-user, then add each ssh user to the group with sudo usermod -a -G ssh-user <username>.

Symmetric ciphers

Symmetric ciphers are used to encrypt the data after the initial key exchange and authentication is complete.

Here we have quite a few algorithms:# 3des-cbc

aes128-cbc
aes192-cbc
aes256-cbc
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com
arcfour
arcfour128
arcfour256
blowfish-cbc
cast128-cbc
chacha20-poly1305@openssh.com

We have to consider the following:* Security of the cipher algorithm: This eliminates 1 and 10-12 - both DES and RC4 are broken. Again, no need to wait for them to become even weaker, disable them now.

Key size: At least 128 bits, the more the better.
Block size: Does not apply to stream ciphers. At least 128 bits. This eliminates 13 and 14 because those have a 64 bit block size.
Cipher mode: The recommended approach here is to prefer AE modes and optionally allow CTR for compatibility. CTR with Encrypt-then-MAC is provably secure.

Chacha20-poly1305 is preferred over AES-GCM because the SSH protocol does not encrypt message sizes when GCM (or EtM) is in use. This allows some traffic analysis even without decrypting the data. We will deal with that soon.

Recommended /etc/ssh/sshd_config snippet:

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

Recommended /etc/ssh/ssh_config snippet:

Host *

   Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

Message authentication codes

Encryption provides confidentiality, message authentication code provides integrity. We need both. If an AE cipher mode is selected, then extra MACs are not used, the integrity is already given. If CTR is selected, then we need a MAC to calculate and attach a tag to every message.

There are multiple ways to combine ciphers and MACs - not all of these are useful. The 3 most common:* Encrypt-then-MAC: encrypt the message, then attach the MAC of the ciphertext.

MAC-then-encrypt: attach the MAC of the plaintext, then encrypt everything.
Encrypt-and-MAC: encrypt the message, then attach the MAC of the plaintext.

Only Encrypt-then-MAC should be used, period. Using MAC-then-encrypt have lead to many attacks on TLS while Encrypt-and-MAC have lead to not quite that many attacks on SSH. The reason for this is that the more you fiddle with an attacker provided message, the more chance the attacker has to gain information through side channels. In case of Encrypt-then-MAC, the MAC is verified and if incorrect, discarded. Boom, one step, no timing channels. In case of MAC-then-encrypt, first the attacker provided message has to be decrypted and only then can you verify it. Decryption failure (due to invalid CBC padding for example) may take less time than verification failure. Encrypt-and-MAC also has to be decrypted first, leading to the same kind of potential side channels. It’s even worse because no one said that a MAC’s output can’t leak what its input was. SSH by default, uses this method.

Here are the available MAC choices:# hmac-md5

hmac-md5-96
hmac-ripemd160
hmac-sha1
hmac-sha1-96
hmac-sha2-256
hmac-sha2-512
umac-64
umac-128
hmac-md5-etm@openssh.com
hmac-md5-96-etm@openssh.com
hmac-ripemd160-etm@openssh.com
hmac-sha1-etm@openssh.com
hmac-sha1-96-etm@openssh.com
hmac-sha2-256-etm@openssh.com
hmac-sha2-512-etm@openssh.com
umac-64-etm@openssh.com
umac-128-etm@openssh.com

The selection considerations:* Security of the hash algorithm: No MD5 and SHA1. Yes, I know that HMAC-SHA1 does not need collision resistance but why wait? Disable weak crypto today.

Encrypt-then-MAC: I am not aware of a security proof for CTR-and-HMAC but I also don’t think CTR decryption can fail. Since there are no downgrade attacks, you can add them to the end of the list. You can also do this on a host by host basis so you know which ones are less safe.
Tag size: At least 128 bits. This eliminates umac-64-etm.
Key size: At least 128 bits. This doesn’t eliminate anything at this point.

Recommended /etc/ssh/sshd_config snippet:

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com

Recommended /etc/ssh/ssh_config snippet:

Host *

   MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com

Preventing key theft

Even with forward secrecy the secret keys must be kept secret. The NSA has a database of stolen keys - you do not want your key there.

System hardening

This post is not intended to be a comprehensive system security guide. Very briefly:* Don’t install what you don’t need: Every single line of code has a chance of containing a bug. Some of these bugs are security holes. Fewer lines, fewer holes.

Use free software: As in speech. You want to use code that’s actually reviewed or that you can review yourself. There is no way to achieve that without source code. Someone may have reviewed proprietary crap but who knows.
Keep your software up to date: New versions often fix critical security holes.
Exploit mitigation: Sad but true - there will always be security holes in your software. There are things you can do to prevent their exploitation, such as GCC’s -fstack-protector. One of the best security projects out there is Grsecurity. Use it or use OpenBSD.

Traffic analysis resistance

Set up Tor hidden services for your SSH servers. This has multiple advantages. It provides an additional layer of encryption and server authentication. People looking at your traffic will not know your IP, so they will be unable to scan and target other services running on the same server and client. Attackers can still attack these services but don’t know if it has anything to do with the observed traffic until they actually break in.

Now this is only true if you don’t disclose your SSH server’s fingerprint in any other way. You should only accept connections from the hidden service or from LAN, if required.

If you don’t need LAN access, you can add the following line to /etc/ssh/sshd_config:

ListenAddress 127.0.0.1:22

Add this to /etc/tor/torrc:

HiddenServiceDir /var/lib/tor/hidden_service/ssh HiddenServicePort 22 127.0.0.1:22

You will find the hostname you have to use in /var/lib/tor/hidden_service/ssh/hostname. You also have to configure the client to use Tor. For this, socat will be needed. Add the following line to /etc/ssh/ssh_config:

Host *.onion

   ProxyCommand socat - SOCKS4A:localhost:%h:%p,socksport=9050

Host *

...

If you want to allow connections from LAN, don’t use the ListenAddress line, configure your firewall instead.

Key storage

You should encrypt your client key files using a strong password. Additionally, you can use ssh-keygen -o -a $number to slow down cracking attempts by iterating the hash function many times. You may want to store them on a pendrive and only plug it in when you want to use SSH. Are you more likely to lose your pendrive or have your system compromised? I don’t know.

Unfortunately, you can’t encrypt your server key and it must be always available, or else sshd won’t start. The only thing protecting it is OS access controls.

The end

It’s probably a good idea to test the changes. ssh -v will print the selected algorithms and also makes problems easier to spot. Be extremely careful when configuring SSH on a remote host. Always keep an active session, never restart sshd. Instead you can send the SIGHUP signal to reload the configuration without killing your session. You can be even more careful by starting a new sshd instance on a different port and testing that.

Can you make these changes? If the answer is yes, then…

If the answer is no, it’s probably due to compatibility problems. You can try to convince the other side to upgrade their security and turn it into a yes. I have created a wiki page where anyone can add config files for preserving compatibility with various SSH implementations and SSH based services.

If you work for a big company and change management doesn’t let you do it, I’m sorry. I’ve seen the v1 protocol enabled in such places. There is no chance of improvement. Give up to preseve your sanity.

Special thanks to the people of Twitter for the improvements.

OpenSSH server

Configuration

Different versions of OpenSSH support different options which are not always compatible. This guide shows settings for the most commonly deployed OpenSSH versions at Mozilla - however, using the latest version of OpenSSH is recommended.

Modern (OpenSSH 6.7+)

File: /etc/ssh/sshd_config

# Supported HostKey algorithms by order of preference. HostKey /etc/ssh/ssh_host_ed25519_key HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_ecdsa_key

KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

# Password based logins are disabled - only public key based logins are allowed. AuthenticationMethods publickey

# LogLevel VERBOSE logs user's key fingerprint on login. Needed to have a clear audit track of which key was using to log in. LogLevel VERBOSE

# Log sftp level file access (read/write/etc.) that would not be easily logged otherwise. Subsystem sftp /usr/lib/ssh/sftp-server -f AUTHPRIV -l INFO

# Root login is not allowed for auditing reasons. This is because it's difficult to track which process belongs to which root user: # # On Linux, user sessions are tracking using a kernel-side session id, however, this session id is not recorded by OpenSSH. # Additionally, only tools such as systemd and auditd record the process session id. # On other OSes, the user session id is not necessarily recorded at all kernel-side. # Using regular users in combination with /bin/su or /usr/bin/sudo ensure a clear audit track. PermitRootLogin No

# Use kernel sandbox mechanisms where possible in unprivileged processes # Systrace on OpenBSD, Seccomp on Linux, seatbelt on MacOSX/Darwin, rlimit elsewhere. UsePrivilegeSeparation sandbox

File: /etc/ssh/moduli

All Diffie-Hellman moduli in use should be at least 3072-bit-long (they are used for diffie-hellman-group-exchange-sha256) as per our Security/Guidelines/Key_Management recommendations. See also man moduli.

To deactivate short moduli in two commands: awk '$5 >= 3071' /etc/ssh/moduli > /etc/ssh/moduli.tmp && mv /etc/ssh/moduli.tmp /etc/ssh/moduli

Intermediate (OpenSSH 5.3)

This is mainly for use by RHEL6, CentOS6, etc. which run older versions of OpenSSH.

File: /etc/ssh/sshd_config

# Supported HostKey algorithms by order of preference. HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_ecdsa_key

KexAlgorithms diffie-hellman-group-exchange-sha256 MACs hmac-sha2-512,hmac-sha2-256 Ciphers aes256-ctr,aes192-ctr,aes128-ctr

# Password based logins are disabled - only public key based logins are allowed. RequiredAuthentications2 publickey

# RequiredAuthentications2 not work on official OpenSSH 5.3 portable. # In this is your case, use this instead: #PubkeyAuthentication yes #PasswordAuthentication no

# LogLevel VERBOSE logs user's key fingerprint on login. Needed to have a clear audit track of which key was using to log in. LogLevel VERBOSE

# Log sftp level file access (read/write/etc.) that would not be easily logged otherwise. Subsystem sftp /usr/lib/ssh/sftp-server -f AUTHPRIV -l INFO

# Root login is not allowed for auditing reasons. This is because it's difficult to track which process belongs to which root user: # # On Linux, user sessions are tracking using a kernel-side session id, however, this session id is not recorded by OpenSSH. # Additionally, only tools such as systemd and auditd record the process session id. # On other OSes, the user session id is not necessarily recorded at all kernel-side. # Using regular users in combination with /bin/su or /usr/bin/sudo ensure a clear audit track. PermitRootLogin No

File: /etc/ssh/moduli

All Diffie-Hellman moduli in use should be at least 2048-bit-long. From the structure of moduli files, this means the fifth field of all lines in this file should be greater than or equal to 2047.

To deactivate weak moduli in two commands: awk '$5 >= 2047' /etc/ssh/moduli > /etc/ssh/moduli.tmp && mv /etc/ssh/moduli.tmp /etc/ssh/moduli

Multi-Factor Authentication (OpenSSH 6.3+)

Recent versions of OpenSSH support MFA (Multi-Factor Authentication). Using MFA is recommended where possible.

It requires additional setup, such as using the OATH Toolkit or DuoSecurity.

ATTENTION

In order to allow using one time passwords (OTPs) and any other text input, Keyboard-interactive is enabled in OpenSSH. This MAY allow for password authentication to work. It is therefore very important to check your PAM configuration so that PAM disallow password authentication for OpenSSH.

OpenSSH 6.3+ (default)

File: /etc/ssh/sshd_config

# IMPORTANT: you will have to ensure OpenSSH cannot authenticate with passwords with PAM in /etc/pam.d/sshd # "PasswordAuthentication no" is not sufficient! PubkeyAuthentication yes PasswordAuthentication no AuthenticationMethods publickey,keyboard-interactive:pam KbdInteractiveAuthentication yes UsePAM yes # Ensure /bin/login is not used so that it cannot bypass PAM settings for sshd. UseLogin no

OpenSSH 5.3+ w/ RedHat/CentOS patch (old)

File: /etc/ssh/sshd_config

# Allow keyboard-interactive. # IMPORTANT: you will have to ensure OpenSSH cannot authenticate with passwords with PAM in /etc/pam.d/sshd # "PasswordAuthentication no" is not sufficient! RequiredAuthentications2 publickey,keyboard-interactive:skey PasswordAuthentication no ChallengeResponseAuthentication yes UsePAM yes # Ensure /bin/login is not used so that it cannot bypass PAM settings for sshd. UseLogin no

PAM configuration for use with the OATH Toolkit or DuoSecurity as second authentication factor.

File: /etc/pam.d/sshd

#%PAM-1.0 auth required pam_sepermit.so

# WARNING: make sure any password authentication module is disabled. # Example: pam_unix.so, or "password-auth", "system-auth", etc. #auth include password-auth

# Options to enable when using OATH toolkit #auth requisite pam_oath.so usersfile=/etc/users.oath digits=6 window=20

# Options to enable when using DuoSecurity #auth sufficient /lib64/security/pam_duo.so

account required pam_nologin.so

Ciphers and algorithms choice

When CHACHA20 (OpenSSH 6.5+) is not available, AES-GCM (OpenSSH 6.1+) and any other algorithm using EtM (Encrypt then MAC) disclose the packet length - giving some information to the attacker. Only recent OpenSSH servers and client support CHACHA20.

NIST curves (ecdh-sha2-nistp512,ecdh-sha2-nistp384,ecdh-sha2-nistp256) are listed for compatibility, but the use of curve25519 is generally preferred.

SSH protocol 2 supports DH and ECDH key-exchange as well as forward secrecy. Regarding group sizes, please refer to Security/Guidelines/Key_Management.

The various algorithms supported by a particular OpenSSH version can be listed with the following commands:

$ ssh -Q cipher $ ssh -Q cipher-auth $ ssh -Q mac $ ssh -Q kex $ ssh -Q key

OpenSSH client

Configuration

If you have a file containing known_hosts using RSA or ECDSA host key algorithm and the server now supports ed25519 for example, you will get a warning that the host key has changed and will be unable to connect. This means you will have to verify the new host key.

The following configurations expect a recent OpenSSH client, as updating OpenSSH on the client side is generally not an issue.

Modern

This configuration is less compatible and you may not be able to connect to some servers which use insecure, deprecated algorithms. Nevertheless, modern servers will work just fine.

File: ~/.ssh/config

# Ensure KnownHosts are unreadable if leaked - it is otherwise easier to know which hosts your keys have access to. HashKnownHosts yes # Host keys the client accepts - order here is honored by OpenSSH HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256

KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256 MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

Intermediate (connects to older servers)

This configuration can connect to older OpenSSH servers which run old or intermediate configurations.

File: ~/.ssh/config

# Ensure KnownHosts are unreadable if leaked - it is otherwise easier to know which hosts your keys have access to. HashKnownHosts yes # Host keys the client accepts - order here is honored by OpenSSH HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256

Key generation

Large key sizes are used as SSH keys are not renewed very often (see also Security/Key_Management).

Note:

DSA and RSA 1024 bit (or lower) keys are considered weak and should be replaced as soon as possible.

Don't hesitate to create multiple different keys for different usages. In particular, never mix your personal and Mozilla keys.

# RSA keys are favored over ECDSA keys when backward compatibility ''is required'', # thus, newly generated keys are always either ED25519 or RSA (NOT ECDSA or DSA). $ ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_mozilla_$(date +%Y-%m-%d) -C "Mozilla key for xyz"

# ED25519 keys are favored over RSA keys when backward compatibility ''is not required''. # This is only compatible with OpenSSH 6.5+ and fixed-size (256 bytes). $ ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_mozilla_$(date +%Y-%m-%d) -C "Mozilla key for xyz"

You may then want to add the new key to your SSH agent or your configuration file (or both).

# Add key to ssh-agent $ ssh-add ~/.ssh/id_..._mozilla... # <= replace by your key's path # Add configuration to ~/.ssh/config host *.mozilla.com IdentityFile ~/.ssh/id_...mozilla... # <= replace by your key's path

Protection of user keys

Protected by strong passphrase.
Never copied to another system than your own workstation/personal physical disks/tokens.
Use SSH forwarding or SSH tunneling if you need to jump between hosts. DO NOT maintain unnecessary agent forwarding when unused.

Protection of machine keys

When SSH keys are necessary for automation between systems, it is reasonable to use passphrase-less keys. * The recommended settings are identical to the user keys.

The keys must be accessible only by the admin user (root) and/or the system user requiring access.
Usage of machine keys should be registered in an inventory (a wiki page, ldap, an inventory database), to allow for rapid auditing of key usage across an infrastructure.
The machine keys should be unique per usage. Each new usage (different service, different script called, etc.) should use a new, different key.
Only used when strictly necessary.
Restrict privileges of the account (i.e. no root or "sudoer" machine account).
Using a ForceCommand returning only the needed results, or only allowing the machine to perform SSH-related tasks such as tunneling is prefered.
Disable sftp if not needed as it exposes more surface and different logging mechanisms than SSH (and thus scp) itself.

Note:

You may want to use the group "users" instead of "sftpusers" in the example below as this may already exist and include all regular users by default.

   # groupadd sftpusers
   # usermod -a -g sftpusers <userthat_needs_ftp>
   # chgrp sftpusers /usr/lib/ssh/sftp-server
   # chmod 0750 /usr/lib/ssh/sftp-server

Multi-factor bypass setup for machine keys

Machine keys do not play well with multi-factor authentication as there is no human interaction. * All logins from machine accounts should be protected by an additional authentication layer (VPN, another machine, etc.).

All logins from machine accounts are only allowed within the private IP-space, and if possible, only the relevant machine source IPs should be accessible.

File: /etc/ssh/sshd_config (OpenSSH 6.3+)

Match User machine_user Address 10.0.0.0/8,192.168.0.0/16,172.16.0.0/12

   PubkeyAuthentication yes
   KbdInteractiveAuthentication no
   AuthenticationMethods publickey

File: /etc/ssh/sshd_config (OpenSSH 5.3+ w/ RedHat/CentOS patch)

Match User machine_user Address 10.0.0.0/8,192.168.0.0/16,172.16.0.0/12

   RequiredAuthentications2 publickey

Auditing your existing SSH keys

Existing keys are generally stored in ~/.ssh/ (Linux/OSX) or %APPDATA% (Windows). Look for id_{rsa,ed25519,ecdsa,dsa}, identity, IdentityFile, *.pem, and other identity files.

Display SSH keys information

# You may run this for any key file that you have. $ ssh-keygen -lf id_rsa 2048 bc:4f:46:2b:3d:f1:e2:0f:ac:40:99:49:ed:c9:81:a2 Mozilla key for xyz (RSA) ^^ ^^^^^^^^^ ^^^^ ^^^ |__ Size |__ Fingerprint |__ Comment |__ Type

SSH agent forwarding

ATTENTION

SSH Agent forwarding exposes your authentication to the server you're connecting to. By default, an attacker with control of the server (i.e. root access) can communicate with your agent and use your key to authenticate to other servers without any notification (i.e. impersonate you).For this reason, one must be careful when using SSH agent forwarding. Defaulting to always forwarding the agent is strongly discouraged.Note also that while the attacker can use your key as long as the agent is running and forwarded, he cannot steal/download the key for offline/later use.

SSH forwarding allows you to jump between hosts while keeping your private key on your local computer. This is accomplished by telling SSH to forward the authentication requests back to the ssh-agent of your local computer. SSH forwarding works between as many hosts as needed, each host forwarding new authentication request to the previous host, until the ssh-agent that holds the private key is reached.

"Ssh forwarding.png"

On each host, two environment variables are declared for the user enabling ssh-agent: * $SSH_AUTH_SOCK declares the location of the unix socket that can be used to forward an authentication request back to the previous host.(ex: /tmp/ssh-NjPxtt8779/agent.8779). Only present if using SSH agent forwarding.

$SSH_CONNECTION shows the source IP and port of the previous host, as well as the local IP and port. (ex: 10.22.248.74 44727 10.8.75.110 22).

To use ssh-agent, add the flag -A to your ssh commands:

$ ssh -A user@ssh.mozilla.com

You can set the following configuration parameter in your local ssh configuration at ~/.ssh/config.

Host ssh.mozilla.com

   ForwardAgent yes

Hardening the Agent forwarder

It is possible to require confirmation every time the agent is used (i.e. when you connect to a server through the SSH agent) by using the -c flag:

# First, remove the key from the agent if it's already loaded: $ ssh-add -d ~/.ssh/id_ed25519 # And re-add it with the -c flag: $ ssh-add -c ~/.ssh/id_ed25519

It is also possible to lock the key in the agent after a configurable amount of time, this can be done either for all keys when starting the agent, or per key when adding the keys to the agent with the -t flag:

# Keep all keys decrypted/useable in memory for 30 minutes (1800 seconds) $ ssh-agent -t 1800 # First, remove the key from the agent if it's already loaded: $ ssh-add -d ~/.ssh/id_ed25519 # Re-add it, with the -t flag to keep this specific key decrypted/useable in memory for 30 minutes (1800 seconds) $ ssh-add -t 1800 ~/.ssh/id_ed25519

For MacOSX in particular it's possible to save the passphrase in the Keychain. If you do so it is strongly recommended to also change the keychain setting to lock itself when the computer is locked, and/or to timeout and lock the keychain. These settings are not controlled by OpenSSH.

# MacOSX only - save the passphrase in the Keychain $ ssh-add -K ~/.ssh/id_ed25519

Note:

There are also some third-party patches for various OpenSSH clients that will notify you visually when the agent is being used.

These are not officially supported and may require you to recompile OpenSSH.

* OpenSSH Linux

PuTTY/Pageant
GnuPG Agent Linux
OpenSSH MacOS X (see also http://devinteske.com/)

Recommended, safer alternatives to SSH agent forwarding

OpenSSH >=7.3

OpenSSH 7.3 onwards allow users to jump through several hosts in a rather automated fashion. It has full support for scp and sftp commands as well as regular ssh.

For example to reach a host behind a bastion/jumphost:

# Single jump $ ssh -J ssh.mozilla.com myhost.private.scl3.mozilla.com

# Jump through 2 hops $ ssh -J ssh.mozilla.com,ec2-instance.aws.net 10.0.0.3

# Copy data from a host $ scp -oProxyJump=ssh.mozilla.com myhost.private.scl3.mozilla.com:/home/kang/testfile ./

You can also add these lines to your ~/.ssh/config

Host *.mozilla.com !ssh.mozilla.com ProxyJump ssh.mozilla.com

Older versions of OpenSSH

It is possible to directly forward ports for single jumps instead of forwarding the agent. This has the advantage of never exposing your agent to the servers you're connecting to.

For example, you can add these lines to your ~/.ssh/config

Host *.mozilla.com !ssh.mozilla.com ProxyCommand ssh ssh.mozilla.com -W %h:%p

This will automatically forward the SSH connection over ssh.mozilla.com when you connect to a mozilla.com SSH server.

Appendixes

Key material handling

Key material identifies the cryptographic secrets that compose a key. All key material must be treated as RESTRICTED data, meaning that: * Only individual with specific training and need-to-know should have access to key material.

Key material must be encrypted on transmission.
Key material can be stored in clear text, but only with proper access control (limited access).

This includes: * OpenSSH server keys (/etc/ssh/ssh_host_*key)

Client keys (~/.ssh/id_{rsa,dsa,ecdsa,ed25519} and ~/.ssh/identity).

Client key size and login latency

In order to figure out the impact on performance of using larger keys - such as RSA 4096 bytes keys - on the client side, we have run a few tests:

On an idle, i7 4500 intel CPU using OpenSSH_6.7p1, OpenSSL 1.0.1l and ed25519 server keys the following command is ran 10 times:

time ssh localhost -i .ssh/id_thekey exit

Results:

Client key	Minimum	Maximum	Average
RSA 4096	120ms	145ms	127ms
RSA 2048	120ms	129ms	127ms
ed25519	117ms	138ms	120ms

Keep in mind that these numbers may differ on a slower machine, and that this contains the complete login sequence and therefore is subject to variations. However, it seems safe to say that the latency differences are not significant and do not impact performance sufficiently to cause any concern regardless of the type of key used.

Reference documents