Secure Shell (SSH) DFN-CERT: Zentrum für sichere Netzdienste GmbH Oberstraße 14b D Hamburg 2. Dezember 2002

Transkript

1 Secure Shell (SSH) DFN-CERT: Zentrum für sichere Netzdienste GmbH Oberstraße 14b D Hamburg 2. Dezember 2002 Informationsbulletin Dib-2002:01 vom letzte Änderung: Einleitung In vielen Computernetzwerken werden Daten immer noch ungesichert übertragen. Die Gefahr, dass Dritte vertrauliche Daten abfangen oder verfälschen können, ist vielen Nutzern nicht bewusst. Besonders in öffentlichen Netzen, wie z. B. dem Internet, ist dieses Risiko hoch. Dass es sich hierbei nicht nur um ein theoretisches Risiko handelt, belegen die zahlreichen Sicherheitsvorfälle der letzten Jahre. Frei verfügbare Programme, wie z. B. dsniff 1 oder sniffit, 2 zeigen sehr deutlich, wie leicht es ist, ungesicherte Übertragungen abzufangen oder zu manipulieren. Die Risiken sind vielfältig: Kundendaten und ähnlich vertrauliche Daten, die irgendwo im Internet auftauchen, enthüllte Firmengeheimnisse, Produktionsausfälle, Betrug, ein illegaler Warez-Server oder ähnlich missbräuchliche Benutzung von wertvollen Ressourcen sind mehr als nur ein Ärgernis. Der mögliche Vertrauensverlust, der finanzielle Schaden, sowie eventuelle rechtliche Folgen sind Teil des Horrorszenarios, dem viele Anwender und Firmen täglich nur knapp entgehen. Für den Bereich des sicheren remote login und der sicheren Übertragung von Dateien bietet die Secure Shell (SSH) geeignete Werkzeuge für Anwender und Systemadministratoren, um den beschriebenen Problemen zu begegnen. 2 Was ist SSH? Der Ausdruck SSH steht sowohl für das Programmpaket SSH, als auch für die eigentliche Anwendung ssh, sowie für das zugrunde liegende Protokoll. SSH ist als Ersatz für die sog. R-Tools (rsh, rlogin) und telnet gedacht, die unverschlüsselt arbeiten. In der Regel macht es für den Benutzer keinen Unterschied, ob er mit SSH oder den R-Tools arbeitet. SSH wurde 1995 von Tatu Ylönen an der Technischen Universität Helsinki als Reaktion auf einen Vorfall, bei dem Passwörter abgehört wurden, entwickelt. SSH hat sich seit dem weit verbreitet, Schätzungen gehen von mehr als zwei Millionen Benutzern 3 aus. 2.1 Definitionen Um zwischen den Programmen, Protokollen und Implementationen unterscheiden zu können verwendet dieses Bulletin folgende Definitionen analog zu [SSHTDG] SSH - The Secure Shell, Daniel J. Barett u. Richard E. Silverman, O Reilly 2001, ISBN , S.12 4 SSH - The Secure Shell, Daniel J. Barett u. Richard E. Silverman, O Reilly 2001, ISBN

2 SSH Ist ein universeller Ausdruck, der sich allgemein auf SSH bezieht und sowohl das Protokoll, als auch die Software meinen kann. SSH-1 Das SSH-Protokoll, Version 1. SSH-2 Das SSH-Protokoll, Version 2. SSH1 Die ursprüngliche SSH-Implementation von Tatu Ylönen. SSH2 Das Produkt SSH Secure Shell von SSH Inc. OpenSSH Die freie SSH-Implementation des OpenBSD-Projektes. ssh Der SSH-Klient, der in fast allen SSH-Implementationen enthalten ist. Der Klient kann im Fall von SSH1 und SSH2 auch ssh1, bzw. ssh2 heißen. sshd Der SSH-Server, der den Dienst SSH bereitstellt. lokaler Computer bezeichnet den Rechner, auf dem der SSH-Klient ausgeführt wird. entfernter Computer ist normalerweise ein weiterer Rechner, an dem man sich anmelden möchte. lokaler Benutzer wird ein Benutzer-Konto genannt das auf einem lokalen Computer existiert. entfernter Benutzer benennt ein Benutzer-Konto, das auf einem entfernten Computer angelegt ist. Server ist das SSH-Server-Programm, üblicherweise sshd. Serversystem soll der Computer genannt werden, auf dem ein SSH-Server ausgeführt wird. Klient soll das Programm heißen, mit dem die Verbindung zu einem SSH-Server aufgebaut wird. Klientensystem meint den Rechner, auf dem der SSH-Klient läuft. SSH ist eine inzwischen weit verbreitete 5 Software-Lösung, die eine verschlüsselte Kommunikation in Netzwerken ermöglicht. SSH arbeitet nach einem Client-Server -Modell. Die Verschlüsselung ist für den Benutzer transparent, d. h. er kann in ähnlicher Weise mit SSH arbeiten, wie er es von Programmen wie telnet, rcp oder ftp gewohnt ist. In der Regel wird ein SSH-Server von der Systemadministration auf einem Serversystem installiert. Anwender, die die Dienste des Serversystems nutzen wollen, melden sich mit ihrem SSH-Klienten am SSH-Server an. Die Authentifizierung kann dabei, je nach Konfiguration, z. B. per Passwort oder mit einem speziellen, kryptographischen Schlüssel erfolgen. 2.2 Was leistet SSH? Die Secure Shell bietet: Verschlüsselte remote logins. Ausführen von Kommandos auf entfernten Systemen. Verschlüsselte Dateiübertragung mit scp und sftp. Vertraulichkeit, alle übertragenen Daten werden automatisch verschlüsselt. Gewährleistung der Datenintegrität durch CRC 6 (SSH-1) oder MAC 7 (SSH-2) cyclic redundancy checking, CRC wird benutzt, um über Prüfsummen Transportfehler zu erkennen 7 message authentication code, Ein MAC wird aus einem (geheimen) Schlüssel, sowie der Eingabe berechnet. Der Hashwert kann nur mit Kenntnis des Schlüssels geprüft werden. 2

3 Die Verwendung von rechnerspezifischen, krypotografischen Schlüsseln hilft DNS- und IP- Spoofing zu erkennen. Geringer Schulungsaufwand für Benutzer, die vorher mit rsh, rlogin oder telnet gearbeitet haben. Datenkompression, z. B. für Wählleitungen. automatische Umlenkung und Verschlüsselung des X11-Datenverkehrs. TCP Port-Weiterleitung, SSH kann verschlüsselte Tunnel zu anderen Rechnern aufbauen, über die auch ungesicherte Protokolle verschlüsselt übertragen werden können. Plattformunabhängigkeit, SSH ist für fast jedes Betriebsystem (einschliesslich Linux, Mac OS, MS Windowsund Unix) und für die meisten Hardware-Plattformen verfügbar. 2.3 Was leistet es nicht? SSH ist ein mächtiges Werkzeug. Es macht ein Netzwerk aber nicht automatisch sicher. Es bietet seinen Anwendern aber eine sehr gute Hilfestellung, ihr Netzwerk sicherer zu machen. SSH schützt z.b. nicht bei einer Kompromittierung eines der beteiligten Systeme. So kann z. B. ein Nutzer mit Systemrechten ihre Passwort- oder Passphraseeingaben auf dem kompromittierten System mitschneiden. Dies ist ein allgemeines Problem, für das SSH keine Lösung anbietet. 2.4 Implementationen Es existiert eine Vielzahl unterschiedlicher SSH-Implementationen für die meisten Betriebssysteme und Hardware-Plattformen. Viele Betriebssystemhersteller liefern inzwischen SSH standardmäßig mit aus. 8 Einen Überblick bieten die folgenden Webseiten: Die beiden wichtigsten Implementationen sind: OpenSSH ist eine Weiterentwicklung der ursprünglich freien SSH-Version von Tatu Ylönen (SSH1). OpenSSH benutzt Teile von OpenSSL. 9 OpenSSH unterstützt derzeit die meisten Plattformen 10 und ist die verbreitetste 11 SSH-Implementation. SSH2 Die kommerzielle Version von SSH wird über vertrieben. Der Einsatz ist für kommerzielle Anwender kostenpflichtig. Diese SSH-Version gibt es für viele Plattformen. 12 Es unterstützt nur die SSH-Protokollversion

4 2.5 Protokolle Es existieren zwei inkompatible Versionen des SSH-Protokolls, Version 1 und Version 2. Dieses Bulletin wird sich hauptsächlich mit der Protokollversion 2 befassen, weil Version 1 einige Designschwächen 13 aufweist, weswegen die Verwendung des neueren Protokolls anzuraten ist. In Ausnahmefällen kann die Verwendung von Protokollversion 1 notwendig sein, so verwendet z. B. Cisco fuer sein Betriebssystem IOS SSH-1. SSH wird derzeit von der IETF 14 standardisiert Ablauf einer normalen SSH-Verbindung Der Klient baut eine TCP-Verbindung zum Server auf. In der Regel nimmt der Server Verbindungen auf Port 22 an. Klient und Server einigen sich auf eine Protokollversion. Der Server authentifiziert sich gegenüber dem Klienten in einem Challenge-Response -Verfahren. Jetzt werden die Verbindungs-Parameter festgelegt, hier wird z. B. das Verschlüsselungsverfahren festgelegt. Bis jetzt wurde noch unverschlüsselt gearbeitet. Jetzt schickt der Klient dem Server den geheimen Sitzungsschlüssel mit dem die Verbindung verschlüsselt wird. Der Benutzer kann sich jetzt dem Server gegenüber authentifizieren, je nach Konfiguration des Servers z. B. mit seinem Passwort, einem zuvor hinterlegtem kryptografischen Schlüssel, mit einer Smartcard, Bestandteile Die verschiedenen Funktionen des Gesamtsystems SSH (Serverdienst, Klient, Schlüsselerzeugung,... ) sind auf einzelne Programme verteilt. ssh: Der SSH-Klient, er dient zur entfernten Ausführung von Kommandos und für interaktive Logins. sshd: Der SSH-Server, an dem sich der Klient anmeldet. ssh-agent: Ein Agent, der private SSH-Schlüssel vorhalten kann. ssh-add: Ein Werkzeug, mit dem private Schlüssel an den Agenten übergeben werden. sftp: Ein FTP-ähnliches Programm zur Übertragung von Dateien. scp: Programm zum Kopieren von Dateien, das sich ähnlich wie rcp verhält. ssh-keygen: Werkzeug zum Erzeugen und Verwalten von Schlüsselpaaren. Bei der kommerziellen SSH-Version sind die Programmnamen zusätzlich mit dem Suffix 2 versehen. Es existieren aber normalerweise symbolische Links zu den Namen ohne Suffix. 3 Verwendung Dieser Abschnitt zeigt die gängigsten Anwendungen für SSH. Die Beispiele sollten mit allen Implementationen funktionieren, die über einen SSH-Kommandozeilen-Klienten verfügen. Die Beispiele sind mit SSH2 und OpenSSH getestet. Programmnamen, Bildschirmausgaben und Optionen können sich unterscheiden. Bei deutlichen Abweichungen sind die Beispiele für SSH2 und OpenSSH getrennt angegeben. Die Beispiele wurden mit OpenSSH-3.4p1 und SSH getestet. Verwendetes Betriebssystem ist SuSE- Linux 7.3, die Beispiele wurden zusätzlich mit SUN Solaris 9 überprüft

5 In den folgenden Beispielen wird von einer Benutzerin Alice ausgegangen, die auf ihrem lokalen Rechner ein Benutzer-Konto mit dem Namen alice hat. Der Rechner von Alice heisst klient. Der Rechner, auf den Alice zugreifen will, heisst server. Eingegebene Passwörter werden nicht dargestellt. Benutzereingaben sind fett hervorgehoben. Lange Zeilen sind mit einem Gegenschrägstrich ( ) umgebrochen. 3.1 Erster Verbindungsaufbau Wird das erste Mal eine Verbindung zu einem Server aufgebaut und ist der öffentliche Schlüssel des Servers nicht bekannt, fordert SSH eine explizite Bestätigung des Benutzers an. Den kryptografischen Fingerabdruck sollte man dann z. B. telefonisch mit dem Administrator des Servers vergleichen. Beispiel für OpenSSH: ssh server The authenticity of host server ( ) can t be established. DSA key fingerprint is c3:07:ef:07:95:4d:c8:56:b5:0f:06:d5:a2:03:b6:a2. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added server, (DSA) to the list of known hosts. Last login: Tue Apr 30 15:32: from klient alice@server:~> Beispiel für SSH2: ssh2 server Host key not found from database. Key fingerprint: xinoh-vefes-duvyt-dorev-bocib-mybil-pogap-gyfeg-vigak-buzop-gixox You can get a public key s fingerprint by running % ssh-keygen -F publickey.pub on the keyfile. Are you sure you want to continue connecting (yes/no)? yes Host key saved to /home/alice/.ssh2/hostkeys/key_22_server.pub host key for server, accepted by alice Tue Apr :14: alice s password: Authentication successful. alice@server:~> Wichtiger Unterschied hier ist das unterschiedliche Format der Fingerabdrücke. Das Format von Open- SSH und SSH1 ist hexadezimal, das von SSH2 nennt sich Bubble Babble, es ist z. B. für den Abgleich am Telefon besser geeignet. SSH2 unterstützt nur Bubble Babble, OpenSSH zusätzlich das hexadezimale Format Geänderte Hostkeys Wenn der Hostkey nicht mit dem in /.ssh/known_hosts, bzw. /.ssh2/hostkeys/ abgelegten Schlüssel übereinstimmt, warnt SSH. Eine Änderung des Hostkeys kann technische Gründe haben oder auf einen Man-in-the-middle -Angriff hindeuten. Man sollte sich bei dem entsprechenden Systemadministrator versichern, dass er den Schlüssel geändert hat und erneut den Fingerabdruck vergleichen. SSH warnt sehr deutlich bei falschen Schlüsseln: 16 siehe Abschnitt

6 ssh WARNING: REMOTE HOST IDENTIFICATION 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 DSA host key has just been changed. The fingerprint for the DSA key sent by the remote host is 56:f2:9b:f4:78:8c:16:9d:a4:2f:01:aa:38:6b:81:9d. Please contact your system administrator. Add correct host key in /home/alice/.ssh/known_hosts to get rid of this message. Offending key in /home/alice/.ssh/known_hosts:5 DSA host key for server has changed and you have requested strict checking. Host key verification failed. 3.2 Anmeldung an fremden Systemen mit ssh Alice möchte sich auf dem Rechner server per ssh anmelden. Alternativ existiert meist ein symbolischer Link auf slogin. ssh server Last login: Tue Apr 30 13:16: from klient alice@server:~> Dies war ein einfaches Beispiel, meist wird ssh auch in dieser Form benutzt. Angenommen, Alice möchte für einen Test nicht ihr eigens Konto auf dem Server benutzen, sondern ein Test-Konto, z. B. test. ssh test@server test@server s password: Last login: Tue Apr 30 12:11: from klient test@server:~> In beiden Fällen handelt es sich um Alice. Lokal arbeitet sie mit dem Benutzer-Konto alice, entfernt einmal als alice, einmal als test. Wenn ssh kein Benutzername übergeben wird, wird die Anmeldung am entfernten System mit dem aktuellen Benutzernamen versucht Ausführen von Kommandos auf entfernten Systemen Alice möchte die Laufzeit (Uptime) des Serversystem abfragen. Sie könnte sich per SSH anmelden, uptime ausführen und sich wieder ausloggen. Oder sie macht es sich einfacher: ssh server uptime 4:13pm up 5 days, 3:17, 5 users, load average: 0.00, 0.00, 0.00 test@klient:~> 17 Statt mit vor dem Hostnamen kann der Benutzername, wie bei rsh auch mit -l bob übergeben werden. 6

7 3.4 Kopieren von Dateien SSH bietet zwei Möglichkeiten, Dateien von einem System auf ein anderes zu kopieren. Die einfache Variante ist das Kopieren mit scp, hierbei müssen Datei- und Pfadnamen für das Zielsystem bekannt sein. scp benötigt eine gültige Login-Shell. Die zweite Möglichkeit ist das SFTP-Subsystem. Die sftp- Bedienung ist FTP nachempfunden und interaktiv. Eine Verwandtschaft zum FTP-Protokoll besteht nicht. Eine Login-Shell ist nicht notwendig Kopieren von Dateien mit scp Alice hat lokal eine Datei erstellt, z. B. kaffee.txt, die sie jetzt auf den Server kopieren möchte. Dafür bietet sich das Programm scp an. scp kaffee.txt server: kaffee.txt 100% ***************************** :00 Das obige Kommando macht einige Annahmen zu Benutzernamen und Verzeichnissen, die für die tägliche Arbeit sehr angenehm sind, die aber auch explizit angegeben werden können: scp kaffee.txt kaffee.txt 100% ***************************** :00 Wenn die Namen der Benutzer-Konten gleich sind, kann der Name weggelassen werden. Das gilt auch für den Dateinamen, es sei denn, er soll beim Kopieren geändert werden. Im ersten Beispiel wird als Ziel server: angegeben, im zweiten server:/home/alice/. SSH impliziert bei der abkürzenden Schreibweise server: das Home-Verzeichnis des jeweiligen Benutzers. Möchte Alice die Datei kaffee.txt jetzt auf dem Server, als Benutzer test, im Verzeichnis /tmp/, als kaffee.bak ablegen, würde es so funktionieren: scp kaffee.txt s password: kaffee.txt 100% ***************************** :00 Die umgekehrte Richtung des Kopierens ist genauso einfach. Alice möchte die Datei kaffee.bak von server in ihr Home-Verzeichnis auf klient kopieren. scp server:/tmp/kaffee.bak. kaffee.bak 100% ***************************** :00 In dem Beispiel ersetzt der Punkt das aktuelle Verzeichnis. Die Annehmlichkeiten der Shell sind auch mit SSH verfügbar. Die längere Version könnte so aussehen: scp server:/tmp/kaffee.bak /home/alice/kaffee.bak kaffee.bak 100% ***************************** :00 7

8 3.4.2 Kopieren von Dateien mit sftp Der sftp-klient arbeitet interaktiv. Das folgende Beispiel zeigt, wie Alice die Datei keks-verbrauch.txt vom Klientensystem auf das Serversystem kopiert. sftp server Connecting to server... sftp> put keks-verbrauch.txt Uploading keks-verbrauch.txt to /home/alice/keks-verbrauch.txt sftp> quit Später möchte Alice die Datei zurückkopiern: sftp server Connecting to server... sftp> get keks-verbrauch.txt Fetching /home/alice/keks-verbrauch.txt to keks-verbrauch.txt sftp> quit 3.5 Beispiele mit public key -Authentifizierung Bequemer als die Authentifizierung mit einem Passwort ist es, sich mit digitalen Schlüsseln anzumelden. Dabei wird auf dem Server eine Datei hinterlegt, in der die öffentlichen Schlüssel gespeichert sind, denen die Anmeldung mit den korrespondierenden geheimen Schlüsseln für dieses Konto erlaubt sein soll. Die geheimen Schlüssel sind in der Regel verschlüsselt gespeichert und werden mit einer Passphrase entschlüsselt. Im Gegensatz zu den Systempasswörtern, gelten die Passphrasen nur für die Anmeldung mit digitalen Schlüsseln per SSH Erzeugen eines Schlüsselpaares Um ein Schlüsselpaar zu erzeugen wird das Programm ssh-keygen aufgerufen. Zuerst wird nach einer Datei gefragt, in der der Schlüssel gespeichert werden soll, normalerweise reicht es, hier zu bestätigen. Anschließend wird nach einer Passphrase gefragt, hier sollte unbedingt eine längere und zufällig gewählte Zeichenkette, die sowohl große als auch kleine Buchstaben, als auch Ziffern und Sonderzeichen enthält, eingegeben werden. Beispiel für OpenSSH (Protokoll-Version 2, RSA-Schlüssel): ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/alice/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/alice/.ssh/id_rsa. Your public key has been saved in /home/alice/.ssh/id_rsa.pub. The key fingerprint is: f6:7b:47:7f:5e:39:fb:f6:fb:24:fa:52:e3:c1:4b:e7 Beispiel für SSH2 (Protokoll-Version 2, DSA-Schlüssel): ssh-keygen2 Generating 1024-bit dsa key pair 1 ooo.ooo.ooo. 8

9 Key generated bit dsa, Tue Apr :59: Passphrase : Again : Private key saved to /home/alice/.ssh2/id_dsa_1024_c Public key saved to /home/alice/.ssh2/id_dsa_1024_c.pub Fingerprints Alle verwendeten Schlüsselpaare haben einen eindeutigen digitalen Fingerabdruck. Wenn man sich die Echtheit eines öffentlichen Schlüssels z. B. per Telefon bestätigen lassen will, ist es praktisch, nicht den ganzen Schlüssel zu vergleichen, sondern nur einen so genannten Fingerabdruck. Das ist besonders für noch unbekannte Hostkeys wichtig, gilt aber auch für die benutzerbezogenen Schlüssel. Zum Einen kommen hexadezimale Fingerabdrücke, aber auch Bubble Babble -Fingerabdrücke vor, die sich z. B. am Telefon besser vergleichen lassen. Anzeigen kann man sich den Fingerabdruck eines Schlüssels mit SSH2 folgendermaßen: ssh-keygen2 -F ~/.ssh2/id_dsa_1024_b.pub Fingerprint for key: xinoh-vefes-duvyt-dorev-bocib-mybil-pogap-gyfeg-vigak-buzop-gixox Hexadezimaler Fingerabdrücke mit OpenSSH: ssh-keygen -l Enter file in which the key is (/home/alice/.ssh/identity): 1024 f3:30:dd:f6:80:cc:73:89:da:15:0c:4f:6c:4c:56:5d alice@klient Bubble Babble -Fingerabdrücke lassen sich wie folgt mit OpenSSH anzeigen: ssh-keygen -B Enter file in which the key is (/home/alice/.ssh/identity): 1024 xolor-fuler-namud-rygas-risop-vecyn-buter-vucyt-nerym-fetoz-vyxyx alice@klient Anmelden mit Schlüssel Zuerst muss der öffentliche Schlüssel des eben generierten Schlüsselpaars auf dem Zielsystem hinterlegt werden. OpenSSH In der Datei /.ssh/authorized_keys werden auf dem SSH-Server alle gewünschten Schlüssel abgelegt. In jeder Zeile dieser Datei steht ein Schlüssel. SSH2 Bei SSH2, wird in der Datei /.ssh2/authorization, auf dem SSH-Server eine Liste von Schlüsseln angelegt, mit denen man sich auf diesem System anmelden darf. /.ssh2/authorization könnte folgenden Inhalt haben: # authorization Key id_dsa_2048_a.pub Die Schlüssel werden im Verzeichnis /.ssh2/ erwartet. In der Datei /.ssh2/identification werden auf dem Klientensystem die Schlüssel eingetragen, mit denen man sich an fremden Systemen anmelden möchte. 9

10 # identification KeyId id_dsa_2048_a SSH2 bring das Script ssh-pubkeymgr mit, dass zum Erstellen und Kopieren dieser Dateien benutzt werden kann. Jeder, der im Besitz des zugehörigen, entschlüsselten, geheimen Schlüssels ist, kann sich nun an diesem System anmelden Beispiele zur Schlüsselhinterlegung OpenSSH Die Datei /.ssh/authorized_keys enthält diejenigen öffentlichen Schlüssel, deren Eigentümer sich per ssh-key anmelden dürfen. Der erste Schlüssel kann mit scp kopiert werden. scp ~/.ssh/id_rsa.pub server:.ssh/authorized_keys id_rsa.pub 100% ***************************** :00 SSH2 Für SSH2 muss der öffentliche Schlüssel hinterlegt werden und zusätzlich muss dieser Schlüssel dann in der Datei /.ssh2/authorization eingetragen werden. scp2 ~/.ssh2/id_dsa_1024_a.pub server:.ssh2/ s password: id_dsa_1024_a.pub 0B 0.0 kb/s TOC: 00:00:01 100% ssh2 server echo "Key id_dsa_1024_a.pub" >> ~/.ssh2/authorization alice s password: Authentication successful. Wird jetzt mit ssh eine Verbindung zum Server aufgebaut, so wird die Passphrase des hinterlegten Schlüssels abgefragt. ssh server Enter passphrase for key /home/alice/.ssh/id_rsa : Last login: Tue Apr 30 16:48: from klient alice@server:~> Es wird also nicht das Passwort, sondern die Passphrase des hinterlegten Schlüssels abgefragt. Wird die Passphrase nicht oder nicht richtig eingegeben, wird das Passwort abgefragt. ssh server Enter passphrase for key /home/alice/.ssh/id_rsa : Last login: Thu May 2 14:22: from klient alice@server:~> Wo ist jetzt der entscheidende Unterschied zur Passwort-Authentifizierung? Für den Benutzer ist es in der gezeigten Form kein großer Unterschied, außer dass er einmal seinen öffentlichen Schlüssel hinterlegen muss. Die Authentifizierung ist sicherer, weil der Benutzer über den geheimen Schlüssel verfügen muss und keine Übertragung des Passwortes über das Netz erfolgt. Ausserdem braucht der Nutzer sich jetzt nur noch eine Passphrase merken, das ist besonders bei vielen verschiedenen Benutzerkonten von Vorteil. Deutlich einfacher und für den Anwender angenehmer ist die Verwendung des SSH-Agenten (s. Abschnitt 3.5.6). 10

11 3.5.5 Interoperabilität Das Zusammenspiel zwischen SSH2 und OpenSSH klappt in der Regel problemlos, wenn man mit dem ssh-keygen von OpenSSH die Schlüssel in das jeweils benötigte Format konvertiert. Konvertieren von OpenSSH zu SSH2 mit: ssh-keygen -e -f ~/.ssh/id_dsa.pub > ~/.ssh2/id_dsa.pub Die andere Richtung ist ähnlich einfach: ssh-keygen -i -f ~/.ssh2/id_dsa_2048_a.pub > ~/.ssh/id_dsa_2048_a.pub SSH-Agenten Eine sehr mächtige Anwendung sind die SSH-Agenten. Sie verbinden die Vorteile der starken Authentifizierung mit der Einfachheit einer Anmeldung, ohne dass ein Passwort angegeben werden muss. Das macht es auch für Batchjobs interessant. Der Agent entschlüsselt nach der Eingabe der Passphrase den geheimen Schlüssel und hält ihn im Speicher vor. Er übernimmt jetzt alle Schlüsselbezogenen Aktionen der SSH-Klienten. Aber ohne Fleiß kein Preis. Der SSH-Agent muss gestartet werden und es müssen die Schlüssel bei ihm angemeldet werden. ssh-agent $SHELL ssh-add ~/.ssh/id_rsa Enter passphrase for.ssh/id_rsa: Identity added:.ssh/id_rsa (.ssh/id_rsa) ssh server Last login: Thu May 2 14:25: from klient alice@server:~> Der Gewinn liegt darin, dass einmal, z. B. bei Arbeitsbeginn der SSH-Agent gestartet wird, um dann den ganzen Tag mit ihm zu arbeiten. Die folgenden Anmeldungen erfordern dann weder Passwort, noch Passphrase, denn der SSH-Agent übernimmt die Authentifizierung. ssh server Last login: Thu May 2 14:36: from klient alice@server:~> Statt ssh-agent $SHELL kann auch eval ssh-agent oder eval $(ssh-agent) verwendet werden. Die geladenen Schlüssel kann man sich mit: ssh-add -l 1024 f6:7b:47:7f:5e:39:fb:f6:fb:24:fa:52:e3:c1:4b:e7.ssh/id_rsa (RSA) anzeigen lassen. Möchte man später einen Schlüssel wieder entfernen, verwendet man die Option -d. ssh-add -d ~/.ssh/id_rsa Identity removed:.ssh/id_rsa (.ssh/id_rsa.pub) Das Starten des SSH-Agenten geschieht zweckmäßigerweise bei der Anmeldung an die eigene Arbeitsplatzmaschine. Entweder an der Konsole oder unter X11. In der Regel bietet es sich an, dies in der Datei /.xsession vorzunehmen. Viele Hersteller haben in ihren Anmelde-Scripten SSH bereits berücksichtigt, oft reicht es die Kommentarzeichen zu entfernen oder eine Option auf yes zu setzen. 11

12 3.6 X11-Weiterleitung SSH unterstützt die sicherer Weiterleitung einer X11-Verbindung. Allerdings müssen sowohl Klient als auch Server dies zulassen. Nur dann funktioniert folgendes Beispiel. Wie dieses Verhalten beeinflusst werden kann wird im Rahmen der Beispielkonfigurationen behandelt. ssh server Last login: Thu May 2 14:42: from klient alice@server:~> xeyes & [1] alice@server:~> Auf dem eigenen Monitor sollten jetzt die xeyes erscheinen. Bewegt man jetzt die Maus, folgen die Augen dem Mauszeiger. Um sich zu veranschaulichen, dass das Programm auf dem Server und nicht auf dem Klient ausgeführt wird, kann man die Prozesslisten des Serversystems und des Klientensystems prüfen. Ungläubige, aber mutige Anwender können jetzt das Netzwerkkabel ziehen. Die Augen hören sofort auf sich zu bewegen, da die Datenverbindung unterbrochen ist. Wird nun die Verbindung wieder hergestellt, rollen die Augen weiter. Obwohl SSH die übertragenen Daten verschlüsselt, ist dieses Verfahren an seinen Endpunkten, d. h. am Klienten- und Serversystem anfällig. X11-Weiterleitungen sollten nur zu Servern aufgebaut werden, die man für vertrauenswürdig hält. 18 Es ist möglich, ausgehend vom entfernten System, über die Datenverbindung, wie bei einer normalen X11-Weiterleitung, den X-Server des darstellenden Systems abzuhören, beispielsweise Tastatureingaben mitzulesen. Die Datenverbindung selbst ist sicher. 4 Installation von SSH Sofern SSH nicht bereits Teil des verwendeten Betriebssystems ist, gibt es zwei Möglichkeiten SSH zu installieren. 1. Installation der Binärdistribution des jeweiligen Herstellers, 2. Übersetzen der Quellen und anschließende Installation. In jedem Fall sollte die digitale Signatur des zu installierenden Paketes geprüft werden, um die Authentizität der Software zu garantieren. Wie das geht erklären die folgenden Webseiten: Binärdistribution Sowohl SSH2 als auch OpenSSH kann für die meisten Plattformen (Windows, Linux, Solaris,... ) in Form einer Binärdistribution, also vorkompiliert, bezogen werden siehe auch

13 4.2 Selber kompilieren Die größtmöglichen Eingriffsmöglichkeiten hat man natürlich, wenn man die Software selber übersetzt. Sowohl SSH2, als auch OpenSSH stellen die Quellen bereit. Durch die großen Eingriffsmöglichkeiten besteht hier die Gefahr, unbeabsichtigt Lücken zu öffnen. Das Vorgehen für SSH2 und OpenSSH ist im wesentlichen gleich: Download der Quellen, Prüfen der digitalen Signatur, Entpacken der Quellen,./configure..., Unterstützung für TCP-Wrapper aktivieren, um die Herkunft der eingehenden TCP-Verbindungen zu protokollieren, bzw. darauf basierend Verbindungen anzunehmen oder abzulehnen. SUID-Binaries vermeiden, um unnötige Schwachstellen zu verhindern. Protokollversion 1 deaktivieren, es soll nur die neuere Version 2 verwendet werden. 19 Unterstützung für nicht benötigte Authentifikations-Mechanismen (SmartCards, Kerberos, etc.) deaktivieren. Auf manchen Systemen kann es gewünscht sein, PAM-Unterstützung zu aktivieren. Es kann auf manchen Systemen notwendig sein, Unterstützung für MD5-Passwörter zu aktivieren. make, make install, sshd starten und dauerhaft einrichten. Das Vorgehen und die jeweiligen Optionen unterscheiden sich jedoch. Gängige Fragen werden z. B. unter beantwortet SSH2 Die aktuellen Quellen können von oder einem der Spiegel-Server (z. B. ftp://ftp.cert.dfn.de/pub/tools/net/ssh/) bezogen werden. Das Beispiel hier bezieht sich auf die Evaluations-Version. Nach dem Überprüfen der Signatur werden die Quellen ausgepackt. alice@server:~/src> gunzip ssh tar.gz alice@server:~/src> tar xf ssh tar alice@server:~/src> cd ssh Anschließend sollten die Dateien README und FAQ gelesen werden. Die Optionen für das configure- Script sind vielfältig. Die Optionen müssen den lokalen Gegebenheiten angepasst werden, wie bei jeder anderen Software auch. Um dieses Beispiel einfach zu halten, ist es auf die wichtigsten Optionen beschränkt. Die wichtigsten für dieses Beispiel sind: --with-libwrap schaltet die Unterstützung für TCP-Wrapper 20 ein. Aber Vorsicht, ohne die richtigen Einträge in /etc/hosts.allow lehnt der Server alle Verbindungen ab

14 --without-internal-ssh1-compat SSH1-Kompatibilität abschalten. --without-ssh-agent1-compat Unterstützung der SSH1-Agenten deaktivieren. --disable-suid-ssh-signer SUID-Binaries vermeiden. Die Ausgaben der folgenden Befehle fehlen. Die Ausgaben sind zwar wichtig, aber zu umfangreich um hier aufgenommen zu werden. --with-libwrap --without-internal-ssh1-compat --disable-suid-ssh-signer make su - Password: root@server:~# cd ~alice/src/ssh root@server:~# make install Die Hostkeys werden automatisch erstellt und unter /etc/ssh2/ gespeichert OpenSSH Die aktuellen Quellen können von einem der Spiegel-Server unter html bezogen werden. Hier sollte ebenfalls die Signatur überprüft werden. OpenSSH benötigt zusätzlich das OpenSSL-Paket ( Falls das Betriebssystem nicht von sich aus eine Möglichkeit bietet Pseudozufallszahlen zu generieren, z. B. über /dev/random, wird der EGD ( oder ein anderes Hilfsprogramm benoetigt (z.b. prngd). Seit Version 3.3 kennt OpenSSH privilege seperation 21. Damit ist es möglich, den Dienst auf einen privilegierten Server und einen eingeschränkten Server zu verteilen. Die meisten Funktionen werden dabei von einem unprivilegierten sshd ausgeführt. Nur noch ein kleinerer Teil läuft mit root-rechten und übernimmt die Authentifizierung. Dadurch wird der sshd zusätzlich abgesichert. Der sshd, der die Verbindungen annimmt, ist zusätzlich in eine chroot-umgebung eingesperrt. Das Auspacken der der Quellen sollte nicht schwer fallen. alice@server:~/src> gunzip openssh-3.4p1.tar.gz alice@server:~/src> tar xvf openssh-3.4p1.tar alice@server:~/src> cd openssh-3.4p1 --disable-suid-ssh Der SSH-Klient (ssh) wird nicht mit suid-flag installiert. --with-tcp-wrappers Der SSH-Server (sshd) benutzt die libwrap. Die Ausgaben der folgenden Kommandos sind aus Platzgründen z. T. nicht enthalten. alice@server:~/src/openssh-3.4p1>./configure --disable-suid-ssh --with-tcp-wrappers alice@server:~/src/openssh-3.4p1> make alice@server:~/src/openssh-3.4p1> su - Password: root@server:~# cd ~alice/src/openssh-3.4p1 root@server:~# make install Die Hostkeys werden automatisch generiert und unter /etc/ssh/ gespeichert. Das Benutzerkonto sshd, sowie das chroot-verzeichnis (/var/empty/) müssen manuell angelegt werden. Unterhalb von /var/empty/ sollten sich keine Dateien befinden. Das Verzeichnis sollte so angelegt werden, dass der Benutzer sshd dort keine Schreibrechte hat

15 5 Beispielkonfigurationen Die folgenden Beispiele sind leicht abgewandelte Versionen der jeweils mitgelieferten Beispiele. In diesen Beispielen hier wird nur Protokollversion 2 benutzt. Version 1 ist deaktiviert. Die folgenden Einstellungen sind restriktiver und bewusst kurz gehalten. Auf selten Benötigte Funktionen wird verzichtet. 5.1 Klient Es gibt drei Möglichkeiten, dem SSH-Klienten Optionen zu übergeben: 1. In der Datei /etc/ssh/ssh_config, 2. über die persönliche Konfigurationsdatei in /.ssh/config oder /.ssh2/config und 3. über die Kommandozeile, Das ist auch die Reihenfolge, in der die Optionen gesetzt werden, später ausgewertete Optionen überschreiben ihre Vorgänger /etc/ssh/ssh_config In /etc/ssh/ssh_config sind systemweit die Optionen für den SSH-Klienten gesetzt. Sowohl bei SSH2, als auch bei OpenSSH ist hier keine Option aktiviert. Sinnvoll ist es, den Klienten standardmäßig Protokoll 2 sprechen zu lassen, bei geänderten Hostkeys abzubrechen und keine X11-Umleitungen zu gestatten. Zusätzlich sollte die Unterstützung für rsh abgestellt werden. Die Funktion ForwardAgent sollte, wenn sie nicht benutzt wird, abgeschaltet sein. Host * ForwardX11 no Protocol 2 StrictHostKeyChecking yes ForwardAgent no FallBackToRsh no /.ssh/config Nach /etc/ssh/ssh_config wird /.ssh/config ausgewertet. Hier bietet es sich an, benutzerspezifische Einstellungen vorzunehmen, z. B. abweichende Benutzernamen anzugeben und X11-Umlenkungen für einzelne Rechner zu erlauben. Host server ForwardX11 yes User test 5.2 Server /etc/ssh/sshd_config Beispiel für OpenSSH: # Beschränkung auf Protokollversion 2 Protocol 2 # Nur Verbindungen zur angegebenen Netzwerkadresse zulassen. ListenAddress # Direkte Anmeldungen des Benutzers root verbieten. 15

16 PermitRootLogin no # Die unsichere Authentifizierung mit rhost-dateien wird abgeschaltet. RhostsAuthentication no # Die Authentifizierungs-Variante mit RSA-Rhosts wird deaktiviert. RhostsRSAAuthentication no #.rhosts-benutzerdateien ignorieren... IgnoreRhosts yes # Genaue Prüfung, ob die Dateiberechtigungen in ~/.ssh/ richtig sind. StrictModes yes # X11-Umleitungen verbieten. X11Forwarding no # Leere Passwörter nicht zulassen. PermitEmptyPasswords no # SFTP-Subsystem definieren. Subsystem sftp /usr/lib/ssh/sftp-server # Privilegientrennung PriviligeSeperation yes /etc/ssh2/sshd2_config Beispiel für SSH2: # Nur Verbindungen zur angegebenen Netzwerkadresse annehmen. ListenAddress # Direkte Anmeldungen des Benutzers root verbieten. PermitRootLogin no #.rhosts-benutzerdateien ignorieren... IgnoreRhosts yes # Genaue Prüfung, ob die Dateiberechtigungen in ~/.ssh/ richtig sind. StrictModes yes # X11-Umleitungen verbieten. X11Forwarding no # Leere Passwörter nicht zulassen. PermitEmptyPasswords no # SFTP-Subsystem definieren. subsystem-sftp sftp-server sftp-subsystem SFTP bietet die Möglichkeit, Dateien in einer FTP ähnlichen Weise per SSH zu kopieren. Der Klient heißt sftp, der Server ist als Subsystem, das vom sshd aufgerufen wird implementiert. Dazu muss in 16

17 der Server-Konfiguration (/etc/ssh/sshd_config, bzw. /etc/ssh2/ssd2_config) das Subsystem explizit definiert werden. Beispiel für SSH2: # SFTP-Subsystem definieren. subsystem-sftp sftp-server Beispiel für OpenSSH: # SFTP-Subsystem definieren. Subsystem sftp /usr/lib/ssh/sftp-server Der Benutzer kann in der Regel frei wählen, ob er Dateien per scp, sftp oder per rsync 22 (durch ssh getunnelt) übertragen will. Es ist aber möglich, den Benutzer auf den reinen Dateitransfer per sftp zu beschränken und interaktive Logins nicht zu gestatten. Das macht natürlich nur Sinn, wenn der Benutzer nicht auf Umwegen doch noch Programme ausführen kann, z. B. über den Webserver. Für OpenSSH kann man hierzu die Login-Shell auf /usr/local/bin/sftp-server setzen, für SSH2 auf /usr/local/bin/ssh-dummy-shell