Secure Shell (SSH)

Transcrição

Secure Shell (SSH)

Secure Shell (SSH)
DFN-CERT: Zentrum für sichere Netzdienste GmbH
Oberstraße 14b
D-20144 Hamburg
2. Dezember 2002
Informationsbulletin Dib-2002:01 vom 07.10.2002
letzte Änderung: 07.10.2002
1 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 Benutzern3 aus.
2.1 Definitionen
Um zwischen den Programmen, Protokollen und Implementationen unterscheiden zu können verwendet
dieses Bulletin folgende Definitionen analog zu [SSHTDG].4
1 http://www.monkey.org/~dugsong/dsniff/
2 http://reptile.rug.ac.be/~coder/sniffit/sniffit.html
3 SSH
4 SSH
- The Secure Shell, Daniel J. Barett u. Richard E. Silverman, O’Reilly 2001, ISBN 0-596-00011-1, S.12
- The Secure Shell, Daniel J. Barett u. Richard E. Silverman, O’Reilly 2001, ISBN 0-596-00011-1
1
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 verbreitete5 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 CRC6 (SSH-1) oder MAC7 (SSH-2)
5 http://www.openssh.org/usage/index.html
6 cyclic
redundancy checking, CRC wird benutzt, um über Prüfsummen Transportfehler zu erkennen
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.
7 message
2
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:
http://www.freessh.org/windows.html,
http://www.openssh.com/windows.html,
http://www.freessh.org/unix.html,
http://www.openssh.com/unix.html,
http://www.freessh.org/java.html,
http://www.openssh.com/java.html,
http://www.freessh.org/other.html,
http://www.openssh.com/palmos.html
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 Plattformen10 und
ist die verbreitetste11 SSH-Implementation.
SSH2 Die kommerzielle Version von SSH wird über http://www.ssh.com 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 2.
8 http://www.openssh.com/users.html
9 http://www.openssl.org
10 http://www.openssh.com/portable.html
11 http://www.openssh.com/usage/graphs.html
12 http://www.ssh.com/products/ssh/portability.html
3
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 IETF14 standardisiert.15
2.6 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, . . .
2.7 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 SSH2 3.2.0 getestet. Verwendetes Betriebssystem ist SuSELinux 7.3, die Beispiele wurden zusätzlich mit SUN Solaris 9 überprüft.
13 http://www.ssh.com/products/ssh/advisories/vulnerability.cfm
14 http://www.ietf.org
15 http://www.ietf.org/ids.by.wg/secsh.html
4
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:
alice@klient:~> ssh server
The authenticity of host ’server (192.168.1.1)’ 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,192.168.1.1’ (DSA) to the list
of known hosts.
alice@server’s password:
Last login: Tue Apr 30 15:32:36 2002 from klient
alice@server:~>
Beispiel für SSH2:
alice@klient:~> 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 30 2002 17:14:02 +0200
alice’s password:
Authentication successful.
alice@server:~>
Wichtiger Unterschied hier ist das unterschiedliche Format der Fingerabdrücke. Das Format von OpenSSH 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.16
3.1.1 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 3.5.2
5
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@
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 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.
alice@klient:~>
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.
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.
alice@klient:~> ssh test@server
test@server’s password:
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. 17
3.3 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:
alice@klient:~> ssh server uptime
4:13pm up 5 days, 3:17, 5 users,
test@klient:~>
17 Statt
load average: 0.00, 0.00, 0.00
mit einem „@“vor dem Hostnamen kann der Benutzername, wie bei rsh auch mit -l bob übergeben werden.
6
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 sftpBedienung ist FTP nachempfunden und interaktiv. Eine Verwandtschaft zum FTP-Protokoll besteht nicht.
Eine Login-Shell ist nicht notwendig.
3.4.1 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.
alice@klient:~> scp kaffee.txt server:
kaffee.txt
100% |*****************************|
alice@klient:~>
795
00: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:
alice@klient:~> scp kaffee.txt alice@server:/home/alice/kaffee.txt
kaffee.txt
100% |*****************************|
795
00:00
alice@klient:~>
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:
alice@klient:~> scp kaffee.txt test@server:/tmp/kaffee.bak
test@server’s password:
kaffee.txt
100% |*****************************|
795
alice@klient:~>
00: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.
alice@klient:~> scp server:/tmp/kaffee.bak .
kaffee.bak
100% |*****************************|
alice@klient:~>
795
00: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:
alice@klient:~> scp server:/tmp/kaffee.bak /home/alice/kaffee.bak
kaffee.bak
100% |*****************************|
795
00:00
alice@klient:~>
7
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.
alice@klient:~> sftp server
Connecting to server...
sftp> put keks-verbrauch.txt
Uploading keks-verbrauch.txt to /home/alice/keks-verbrauch.txt
sftp> quit
alice@klient:~>
Später möchte Alice die Datei zurückkopiern:
alice@klient:~> sftp server
Connecting to server...
sftp> get keks-verbrauch.txt
Fetching /home/alice/keks-verbrauch.txt to keks-verbrauch.txt
sftp> quit
alice@klient:~>
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.
3.5.1 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):
alice@klient:~> 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 alice@klient
Beispiel für SSH2 (Protokoll-Version 2, DSA-Schlüssel):
alice@klient:~> ssh-keygen2
Generating 1024-bit dsa key pair
1 oOo.oOo.oOo.
8
Key generated.
1024-bit dsa, alice@klient, Tue Apr 30 2002 17:59:28 +0200
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
alice@klient:~>
3.5.2 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:
alice@klient:~> ssh-keygen2 -F ~/.ssh2/id_dsa_1024_b.pub
Fingerprint for key:
xinoh-vefes-duvyt-dorev-bocib-mybil-pogap-gyfeg-vigak-buzop-gixox
alice@klient:~>
Hexadezimaler Fingerabdrücke mit OpenSSH:
alice@klient:~> 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:
alice@klient:~> 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
alice@klient:~>
3.5.3 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
# 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.
3.5.4 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.
alice@klient:~> scp ~/.ssh/id_rsa.pub server:.ssh/authorized_keys
id_rsa.pub
100% |*****************************|
332
00:00
alice@klient:~>
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.
alice@klient:~> scp2 ~/.ssh2/id_dsa_1024_a.pub server:.ssh2/
alice@servers’s password:
id_dsa_1024_a.pub
|
0B |
0.0 kB/s | TOC: 00:00:01 | 100%
alice@klient:~>
alice@klient:~>
ssh2 server ’echo "Key id_dsa_1024_a.pub" >> ~/.ssh2/authorization’
alice’s password:
Authentication successful.
alice@klient:~>
Wird jetzt mit ssh eine Verbindung zum Server aufgebaut, so wird die Passphrase des hinterlegten
Schlüssels abgefragt.
Enter passphrase for key ’/home/alice/.ssh/id_rsa’:
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.
Enter passphrase for key ’/home/alice/.ssh/id_rsa’:
Last login: Thu May 2 14:22:10 2002 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
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:
alice@klient:~> ssh-keygen -e -f ~/.ssh/id_dsa.pub > ~/.ssh2/id_dsa.pub
Die andere Richtung ist ähnlich einfach:
alice@klient:~>
ssh-keygen -i -f ~/.ssh2/id_dsa_2048_a.pub > ~/.ssh/id_dsa_2048_a.pub
3.5.6 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.
alice@klient:~> ssh-agent $SHELL
alice@klient:~> ssh-add ~/.ssh/id_rsa
Enter passphrase for .ssh/id_rsa:
Identity added: .ssh/id_rsa (.ssh/id_rsa)
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.
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:
alice@klient:~> 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.
alice@klient:~> 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
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.
alice@server:~> xeyes &
[1] 11025
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:
http://www.cert.dfn.de/infoserv/dib/dib-9405.html,
http://www.gnupg.org/howtos/de/GPGMiniHowto-1.html#ss1.3,
http://www.gnupg.org/de/gnupg.html,
http://www.pgp.com/
4.1 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.
http://www.openssh.com/portable.html,
http://www.ssh.com/products/ssh/download.cfm
18 siehe
auch 2.3
12
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 http://www.snailbook.com/faq/ beantwortet.
4.2.1 SSH2
Die aktuellen Quellen können von http://www.ssh.com/products/ssh/download.cfm 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-3.2.0.tar.gz
alice@server:~/src> tar xf ssh-3.2.0.tar
alice@server:~/src> cd ssh-3.2.0
Anschließend sollten die Dateien README und FAQ gelesen werden. Die Optionen für das configureScript 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-Wrapper20 ein. Aber Vorsicht, ohne die richtigen
Einträge in /etc/hosts.allow lehnt der Server alle Verbindungen ab.
19 http://www.ssh.com/products/ssh/advisories/vulnerability.cfm
20 http://www.cert.dfn.de/infoserv/dib/dib-9307.html
13
--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.
alice@server:~/src/ssh-3.2.0> ./configure
--with-libwrap
--without-internal-ssh1-compat
--disable-suid-ssh-signer
alice@server:~/src/ssh-3.2.0> make
alice@server:~/src/ssh-3.2.0> su Password:
root@server:~# cd ~alice/src/ssh-3.2.0
root@server:~# make install
Die Hostkeys werden automatisch erstellt und unter /etc/ssh2/ gespeichert.
4.2.2 OpenSSH
Die aktuellen Quellen können von einem der Spiegel-Server unter http://www.openssh.com/portable.
html bezogen werden. Hier sollte ebenfalls die Signatur überprüft werden.
OpenSSH benötigt zusätzlich das OpenSSL-Paket (http://www.openssl.org). Falls das Betriebssystem nicht von sich aus eine Möglichkeit bietet Pseudozufallszahlen zu generieren, z. B. über
/dev/random, wird der EGD (http://egd.sourceforge.net/) 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.
21 http://www.citi.umich.edu/u/provos/ssh/privsep.html
14
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.
5.1.1 /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
5.1.2 ˜/.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
5.2.1 /etc/ssh/sshd_config
# Beschränkung auf Protokollversion 2
Protocol 2
# Nur Verbindungen zur angegebenen Netzwerkadresse zulassen.
ListenAddress 192.168.123.123
# Direkte Anmeldungen des Benutzers root verbieten.
15
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
5.2.2 /etc/ssh2/sshd2_config
Beispiel für SSH2:
# Nur Verbindungen zur angegebenen Netzwerkadresse annehmen.
ListenAddress 192.168.123.123
# 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
subsystem-sftp sftp-server
5.2.3 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
der Server-Konfiguration (/etc/ssh/sshd_config, bzw. /etc/ssh2/ssd2_config) das Subsystem explizit definiert werden.
Beispiel für SSH2:
subsystem-sftp sftp-server
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.
22 http://rsync.samba.org
17

Secure Shell (SSH)

Transcrição

Documentos relacionados

Peinlich, peinlich Alice

Internationaler Frauentag 2015

Titelinfo

SSH-Authentifizierung durch Schlüsseldatei

www.my-movie

Netzwerktechnik CHS Villach Mag. Rainer Swatek Dauer: 2

Leseprobe - Weltbild.ch

+ Presse +++ Presse +++ Presse +++ Presse +++ Presse +++ Presse

DAAD-Preis für ausländische Studierende an der Alice Salomon

SSH Die „Secure Shell“ „ - linux