SSH ist ein Programm mit dem man sich auf entfernten Rechnern anmelden kann und ist als sicherer Ersatz für die remote Shell gedacht. Es verschlüsselt die Kommunikation zwischen zwei beliebigen Rechnern. X11 Verbindungen sowie beliebige andere TCP/IP Ports können mit SSH verschlüsselt werden.
Dieses Dokument beschreibt den Umgang mit SSH. Es wird ein Schlüsselpaar erzeugt und auf den Rechnern verteilt. Weiterhin wird SSH dazu benutzt sich sicher auf einem Rechner anzumelden.
Kommentare und Ergänzungsvorschläge zu diesem Dokument bitte an support@irb.cs.uni-dortmund.de schreiben, mit dem Stichwort ssh im Subject.
Public Key Kryptographie benutzt einen öffentlichen Schlüssel (= public key) um Daten zu verschlüsseln und einen privaten (geheimen) Schlüssel um diese Daten zu entschlüsseln. Der Name öffentlicher Schlüssel rührt daher, dass es möglich ist, mit einem öffentlich bekannten Schlüssel Daten zu verschlüsseln, ohne dass die Geheimhaltung der Daten beeinträchtigt wird. Nur mit dem dazugehörigen geheimen Schlüssel ist es möglich an die Daten zu kommen.
Für SSH bedeutet das, dass es sicher ist, den öffentlichen Schlüssel (normalerweise ~/.ssh/id_rsa.pub) per email oder anderen unsicheren Wegen zu versenden. Damit ein Fremder Zugang zu einem Benutzerkonto hat, braucht er den privaten Schlüssel (~/.ssh/id_rsa). Deshalb ist es wichtig, dass dieser Schlüssel nicht bekannt gegeben wird.
Um weiteren Schutz zu erreichen, wird der private Schlüssel mit einer passphrase geschützt. Dadurch wird sichergestellt, dass der geheime Schlüssel unnütz ist, wenn die passphrase nicht bekannt ist.
Der erste Schritt besteht darin, mittels ssh-keygen ein Authentifizierungsschlüsselpaar zu erstellen. Das kann entweder ein RSA oder ein DSA Schlüsselpaar sein. Im Weiteren wird nur noch der RSA-Schlüssel behandelt; der DSA Schlüssel funktioniert entsprechend. Damit keine Missverständnisse auftreten, sollte man sich auf einen Schlüssel festlegen.
Generell ist es wichtig, eine gute passphrase zu benutzen, um den Schlüssel zu schützen. Eine passphrase besteht aus einer Kombination von Zahlen und Buchstaben und darf (soll) aus mehreren Wörtern bestehen. Leerzeichen sind auch erlaubt. Eine gute passphrase enthält eine Kombination von Zahlen und Buchstaben, und besteht aus mehreren Wörtern.
Hier folgt ein Beispielaufruf von ssh-keygen. Die Eingaben vom Benutzer sind in fetten Buchstaben dargestellt. Die passphrase wird nicht am Bildschirm ausgegeben, während man sie eintippt. Wichtig zu wissen ist, dass ssh-keygen ohne besondere Vorkehrnisse noch Schlüssel für das alte SSH 1 Protokoll erzeugt. Daher muss ssh-keygen mit der Option -t rsa aufgerufen werden.
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/franz/.ssh/id_rsa): [Return]
Created directory '/home/franz/.ssh'.
Enter passphrase (empty for no passphrase): KaTz uNd m4us
Enter same passphrase again: KaTz uNd m4us
Your identification has been saved in /home/franz/.ssh/id_rsa.
Your public key has been saved in /home/franz/.ssh/id_rsa.pub.
The key fingerprint is:
cf:b5:52:fa:bb:92:dc:6f:2b:1d:52:2a:a4:f2:45:58 franz@blume
Es ist möglich, mehrere private/öffentliche Schlüssel zu besitzen. Diese müssen dann nur in unterschiedliche Dateien gespeichert werden. Hat man mehrere Logins auf verschiedenen Rechnern kann man die Schlüssel so verteilen, dass nur von bestimmten Rechnern auf andere Rechner zugegriffen werden kann. Falls ein Schlüssel unberechtigter Weise in fremde Hände gerät, bleiben andere Verbindungen dennoch sicher.
Die passphrase kann jederzeit mit dem ssh-keygen Kommando geändert werden:
$ ssh-keygen -t rsa -p
Enter file key is in (/home/franz/.ssh/id_rsa): [Return]
Enter old passphrase: KaTz uNd m4us
Key has comment 'franz@blume'
Enter new passphrase: eNemeNe m1sTe
Enter the same passphrase again: eNemeNe m1sTe
Your identification has been saved with the new passphrase.
Damit ein entfernter Rechner SSH Verbindungen akzeptiert, muss der öffentliche Schlüssel aus ~/.ssh/id_rsa.pub vom lokalen Rechner in die Datei ~/.ssh/authorized_keys auf dem entfernten Rechner geschrieben werden. Genau die Schlüssel, die in dieser Datei stehen, werden bei einer Anmeldung überprüft. Mit einem Texteditor können weitere öffentliche Schlüssel (aus den Dateien mit der Endung .pub) in die Datei übertragen werden. Zu beachten ist, dass sich jeder Schlüssel in einer (sehr langen) Zeile in der Datei ~/.ssh/authorized_keys befindet.
Sind die Dateien und Verzeichnisse, die von SSH benötigt werden, mit falschen Datei- und Verzeichnisrechten versehen, wird ein Zugang mit SSH verweigert. Die Rechte müssen so gesetzt sein, dass keine fremden Personen in das Verzeichnis .ssh (sowie das darüberliegende Homeverzeichnis) und in die Datei ~/.ssh/authorized_keys schreiben dürfen. Die am wenigsten restriktiven Verzeichnisrechte sind folgende:
$ cd
$ ls -ld . .ssh .ssh/authorized_keys .ssh/id_rsa
drwxr-xr-x 36 franz users 3072 Feb 7 15:40 .
drwxr-xr-x 2 franz users 512 Jan 19 15:34 .ssh
-rw-r--r-- 1 franz users 331 Jan 19 14:47 .ssh/authorized_keys
-rw------- 1 franz users 963 Jan 25 15:48 .ssh/id_rsa
Um Zugang zu einem System mit SSH zu erhalten, müssen die Datei- und Verzeichnisrechte wie oben angegeben gesetzt werden. Dann ist es für niemanden ausser dem Benutzer selbst möglich, in diese Verzeichnisse und Dateien schreiben.
$ cd
$ chmod go-w . .ssh .ssh/authorized_keys
Die Voreinstellung für das ~/.ssh-Verzeichnis ist drwx------ (700), es ist empfehlenswert diese beizubehalten. Diese Rechte müssen auf allen Systemen gesetzt werden, zu denen eine Verbindung hergestellt werden soll. Der private Schlüssel (id_rsa) muss natürlich auf dem eigenen Rechner verbleiben.
Um sich auf entfernten Rechnern mit SSH anzumelden, kann man das Programm ssh oder alternativ slogin benutzen.
blume$ slogin koenig
Enter passphrase for key '/home/franz/.ssh/id_rsa': eNemeNe m1sTe
Last login: Mon Feb 7 16:22:45 2000 from bobo
(eventuell weitere Ausgaben)
koenig$
Die passphrase wird nicht auf dem Bildschirm wiedergegeben. Wenn sich der Benutzername auf dem entfernten Rechner von dem auf dem lokalen Rechner unterscheidet, so kann er mit dem Kommandozeilenparameter -l benutzer oder mit benutzer@rechnermit angegeben werden:
blume$ slogin schmid12@marvin
Enter passphrase for key '/home/franz/.ssh/id_rsa': eNemeNe m1sTe
Last login: Mon Feb 7 15:52:45 2000 from bobo
(eventuell weitere Ausgaben)
marvin$
Meldet man sich das erste Mal auf einem entfernten Rechner an, so warnt SSH den Benutzer, dass dieser Rechner unbekannt sei und fragt nach, ob dieser Rechner in die Liste der bekannten Rechner übernommen werden soll:
~ $ ssh koenig
The authenticity of host 'koenig (129.217.24.134)' can't be established.
RSA key fingerprint is 3e:70:ae:0a:1f:13:35:47:e6:d1:ca:2c:4e:78:d8:d9.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'koenig,129.217.12.176' (RSA) to the list of known hosts.
Diese Frage muss genau mit yes beantwortet werden. Ansonsten ist kein Login möglich.
Es ist möglich für jeden Rechner den einen Benutzernamen voreinzustellen. Dies wird in der Konfigurationsdatei gemacht. Siehe hierzu den Abschnitt über das Konfigurieren von SSH.
Stellt man häufig eine Verbindung zu anderen Rechnern her, so ist es oftmals nicht erwünscht, bei jeder Anmeldung die passphrase einzutippen. Mit dem ssh-agent kann die mehrfache Eingabe der passphrase entfallen. Dem Programm ssh-agent muss den Namen eines Programmes gegeben werden, welches ssh-agent ausführen soll. In der Regel ist dieses eine Shell.
$ ssh-agent $SHELL
Nun können in dieser Shell (und allen Programmen die aus dieser Shell heraus gestartet werden, also auch aus einer weiteren Shell heraus) Schlüssel gespeichert werden. Ist ein Schlüssel gespeichert, braucht dieser bei der nächsten Anmeldung nicht wieder mit der passphrase dekodiert zu werden. Wird die Shell, die von ssh-agent gestartet wurde, verlassen, dann werden auch die gespeicherten Schlüssel gelöscht.
In einer Shell, die mittels ssh-agent gestartet wurde, kann ein Schlüssel dem System bekannt gemacht werden. Dazu benutzt man ssh-add:
$ ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/franz/.ssh/id_rsa: eNemeNe m1sTe
Identity added: /home/franz/.ssh/id_rsa (/home/franz/.ssh/id_rsa)
ssh-add -d löscht einzelne Schlüssel aus dem Speicher und ssh-add -D entfernt alle gespeicherten Schlüssel aus dem Speicher.
Die am Fachbereich Informatik installierte Arbeitsumgebung CDE lässt sich leicht mit ssh-agent kombinieren. Dann gilt für alle geöffneten Shells, dass die Schlüssel von dieser Shell aus im Arbeitsspeicher abgelegt werden können und von anderen Shells darauf zugegriffen werden kann. Dazu muss in die Datei ~/.dtprofile folgende Zeile eingefügt werden:
dtstart_session[0]='/opt/local/bin/ssh-agent /usr/dt/bin/dtsession'
Startet man CDE neu (erneutes Anmelden im Login Fenster), tritt
die Änderung in Kraft.
Das ssh Kommando kann auch dazu benutzt werden, Programme auf entfernten Rechnern zu starten, ohne sich dort anmelden zu müssen. Die Ausgabe des Kommandos wird im Terminalfenster angezeigt. Nach Beendigung des Kommandos wird die Kontrolle wieder an das lokale System zurückgegeben. Hier ist ein Beispiel für ein ssh Kommando:
$ ssh koenig who
kaster pts/6 Feb 8 11:38 (:0.0)
Diesen Mechanismus kann man auch dazu benutzen, eine xterm Sitzung auf einem entfernten Rechner zu starten. Dazu benutzt man die -n Option von ssh. Dieses veranlasst SSH Tastaturkommandos nicht von der Shell, aus der SSH gestartet wurde, zu lesen.
$ ssh -n koenig /usr/openwin/bin/xterm &
Mit diesem Kommando wird eine xterm Sitzung auf dem Rechner koenig gestartet und in den Hintergrund geschickt, so dass mit der aktuellen Shell weitergearbeitet werden kann. SSH erkennt, dass auf dem lokalen Rechner X11 läuft und verschlüsselt auch die xterm Sitzung.
Dateien können einfach mit scp zwischen zwei Rechnern hin und her kopiert werden. Das kann der lokale Rechner und ein entfernter Rechner sowie zwei entfernte Rechner sein. Dazu muss vor dem Dateinamen der Rechnername mit einem Doppelpunkt stehen:
$ scp koenig:aliases .
Mehrere Dateien können in einem Kommando kopiert werden, wenn die letzte Angabe ein Verzeichnis ist:
$ scp 'koenig:work/status/*' marvin:.logout /tmp/
Die Anführungszeichen werden dafür benötigt, dass der Platzhalter * nicht von der Shell aufgelöst wird. scp kennt auch die Option -p, die das gleiche bewirkt wie bei dem cp Kommando:
$ scp -p 'koenig:work/status/*' marvin:.logout /tmp/
Mit der Angabe -p wird erreicht, dass die Zeitstempel, die die Dateien haben, mit übertragen werden. In vielen Fällen ist dieses erwünscht. Die Angabe von -p ist optional. Die Pfadangaben auf dem lokalen Rechner sind relativ zum aktuellen Verzeichnis, wobei die Pfadangaben auf entfernten Rechner relativ zum Homeverzeichnis auf den Rechnern liegen.
Neben der Möglichkeit, Dateien mit scp zu
übertragen, kann auch das Secure file transfer program (sftp)
benutzt werden. Das ist ähnlich dem file transfer program
(ftp). Aufgerufen wird es über Kommandozeile mit sftp
(rechnername). Genau wie bei ftp können Dateien mit
get vom entfernten Rechner zum lokalen Recher kopiert
werden und mit put vom lokalen Rechner zum entfernten
Rechner. Eine Übersicht über die möglichen Kommandos sind in der
manpage zu sftp und mit dem
Help-Kommando am sftp-Prompt zu finden (siehe Abschnitt Weitere Information).
Die benutzerspezifischen Voreinstellungen für die SSH Kommandos befinden sich in der Datei ~/.ssh/config. Es gibt eine systemweite Konfigurationsdatei, in der schon Voreinstellungen eingetragen sind. Die benutzerdefinierten Einträge überschreiben die systemweiten Einträge. Jeder Eintrag in der Konfigurationsdatei fängt mit dem Host Schlüsselwort an. Platzhalter können benutzt werden, um die Systeme zu identifizieren.
Gängige Schlüsselwörter lauten: (Voreinstellung in Klammern)
Compression yes/no (no)CompressionLevel 1-9 (6)User Benutzername (lokaler Benutzername)StrictHostKeyChecking yes/no/ask
(ask)
Hier ist ein Beispiel für eine Konfigurationsdatei:
Host marvin
User schmid12
Compression no
Host *
StrictHostKeyChecking no
Compression yes
Spezifische Optionen überschreiben allgemeine Optionen. In diesem Fall ist für alle enfernten Rechner Komprimierung eingeschaltet. Nur für den Rechner marvin ist Komprimierung ausgeschaltet. Eine genaue Auflistung der Optionen ist in der manpage zu ssh zu finden. Die am Fachbereich benutzten Voreinstellungen sind in der Datei /etc/openssh/ssh_config zu finden.
Kommt eine SSH Verbindung nicht zu stande, gibt es verschiedene Ursachen dafür. Oftmals lässt sich nicht genau erkennen, warum SSH den Dienst verweigert. Dann ist es sinnvoll, ssh mit der Option -v zu starten (verbose). Mit dieser Option erhält man wahrscheinlich einen guten Hinweis, woran der Verbindungsaufbau scheitert. Im Folgenden stehen ein paar Hinweise, die bei der Fehlersuche behilflich sein könnten.
if ($?prompt == 0 ) exitabfragen, ob man in einer nicht-interaktiven Sitzung ist und das Skript dann beenden. Werden nach dieser Zeile Ausgaben getätigt, so geschieht das nur in den interaktiven Shells. In der bash würde diese Zeile so aussehen:
if ! echo $- | /bin/grep i > /dev/null 2>&1 ; then exit ; fi
Meldung:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Es gibt mehrere Ursachen für diese Meldung: entweder wurde auf dem Zielrechner ein SSH-Schlüssel verändert, oder es versucht jemand, die Verbindung abzuhören. Es ist nun sehr wichtig, herauszufinden, warum diese Meldung erscheint. Am besten erfragt man bei dem Betreiber des entfernten Rechners nach, ob tatsächlich der SSH-Schlüssel verändert wurde. Ist dieses der Fall, dann löscht man in der Datei ~/.ssh/known_hosts den Eintrag des entsprechenden Rechners. Ab sofort erscheint die Warnung nicht mehr, und der neue SSH-Schlüssel wird gespeichert. Wurde der Schlüssel auf dem entfernten Rechner nicht verändert, so liegt vermutlich ein Angriff auf die Verbindung vor, in dem jemand vorgibt der entfernte Rechner zu sein. In diesem Fall sollte die Verbindung beendet werden und die Ursache für die Meldung gesucht werden.
Die SSH ist für fast alle Betriebssysteme verfügbar.
Auf den Solaris-Rechner, die von der IRB betreut werden, wird derzeit (Juni 2008) die OpenSSH 5.0p1 verwendet. Andere Solaris-Rechner verwenden entweder auch die OpenSSH 5.0p1 oder die Original-Solaris-Version.
Unter Linux wurden erfolgreich verschiedene Versionen der OpenSSH Implementierungen im Zusammenspiel mit der unter Solaris installierten Version getestet.
Es existieren unter anderem mehrere Versionen für Windows. Erfolgreich getestet wurde putty, zu erhalten über http://www.chiark.greenend.org.uk/~sgtatham/putty/. Ein kleiner Hinweis zum RSA-Schlüssel. Möchte man seinen öffentlichen Schlüssel auf einen anderen Rechner übertragen, so ist folgendes zu beachten: Der Schlüssel sollte genau so eingetragen werden, wie ihn puttygen (der Schlüsselgenerator von putty) anzeigt, und nicht wie er abgespeichert wird. Er fängt mit "rsa-key" an und danach kommen viele Buchstaben/Ziffern.
Die SSH FAQ (siehe Abschnitt Weitere Information) enthält auch Hinweise auf Versionen für andere Betriebssysteme.
Zu beachten ist, dass verschiedene Versionen der Secure Shell existieren. Diese unterscheiden sich in der Programmversion sowie in der Protokollversion. Die am Fachbereich Informatik installierte Software kommuniziert mit Protokoll Version 2.0. Dieses entspricht auf den Solaris Rechnern der Programmversion 5.0p1. Sollte die Secure Shell von anderen (nicht von der IRB betriebenen) Rechnern benutzt werden, so sollte auf jeden Fall die Protokollversion 2.0 benutzt werden. Informationen über die Programm- und Protokollversion erhält man in der Regel mit dem Parameter -V bei Aufruf der Secure Shell:
$ ssh -V
OpenSSH_5.0p1, OpenSSL 0.9.8g 19 Oct 2007