From: Raphael H. Becker (Raphael.Becker_at_gmx.de)
Date: 14. Mar 2002
Hallo,
Also gut, ich habe mal runtergeschrieben, was mir nennenswertes zum
Thema SSH eingefallen ist. Korrekturen und Ergaenzungen ausdruecklich
erwuenscht. Weitergabe im Rahmen der BSD-Lizenz.
Der Text soll nicht als Kochrezept verstanden werden, sondern als
Anregung fuer eigene Versuche!
Andreas Fiesser wrote:
[ssh mit keys statt mit passwort]
> > Bei Bedarf schreibe ich gerne mail detailierter, wie man das macht und
> > worauf zu achten ist.
> Das wäre prima.
Es gibt bei ssh mehrere Methoden, der Authentifizierung, die bekannteste
ist ueber die interaktive Eingabe eines Passworts (oder eben mit
Wuergarounds wie expect, die das Passwort dann "tippen"). SSH ist mehr
als ein "sicheres Telnet", es bildet Grundlage fuer verschluesselten
Datenaustausch zwischen 2 Rechnern, zB TCP-Forward oder Filetransfer.
Wenn SSH nicht interaktiv benutzt werden soll, sondern zB aus Scripts
heraus, empfieht es sich, die Athentifizierung basierend auf
Schluesselpaaren vorzunehmen.
Ganz vereinfacht funktioniert das so: Wir haben einen Client ("rhb") und
einen Host ("terminal"). Es soll eine SSH-Verbindung _vom_ Client aus
zum Host hin aufgebaut(!) werden. In welcher Richtung nachher Daten
uebertragen werden sollen, ist davon erstmal unabhaengig.
Es gibt 2 Keys, einen private key (binaer) und einen public-key
(darstellbares ascii). Auf dem Client wird das Schluesselpaar mit Hilfe
von "ssh-keygen" erzeugt. Der public_key wird auf dem Host im
Verzeichnis ~/.ssh/authorized_keys ableget (angehaengt), Details unten.
Dateien:
~/.ssh/authorized_keys Sammlung aller public-Keys,
die fuer diesen User auf diesem
Host als Login erlaubt sind. RSA-
Schluessel fuer SSH1
~/.ssh/authorized_keys2 dito, fuer RSA/DSA-Publickeys
mit SSH2
~/.ssh/identity RSA1-Private Key (binaer)
~/.ssh/identity.pub RSA1-Public_key (lesbare Zahlenfolge
mit user_at_host hinten) Diese Kombination
wird verwendet, um sich per SSH1 auf
einem entfernten Host einloggen zu koennen.
Der Inhalt des Public-Keys muss auf dem
Zielhost/User-Home in der Datei
~/.ssh/authorized_keys angehaengt werden.
~/.ssh/id_rsa RSA2-Private Key
~/.ssh/id_rsa.pub RSA2-Public Key
~/.ssh/id_dsa DSA-Private Key
~/.ssh/id_dsa.pub DSA-Public Key
~/.ssh/known_hosts Gespeicherte Host-Keys verschiedener Hosts.
Aendert sich der Hostkey eines Hosts, so
wird von SSH eine Warnung angezeigt. Ist
Die Key.aenderung ok (zB Neuinstallatin), dann
mus die entsprechende Zeile aus dieser Datei
geloescht werden.
~/.ssh/known_hosts2 dito fuer SSH2
Man kann natuerlich Schluesselpaare mit abweichenden Namen erzeugen und
diese verwenden. Man muss dann allerding explizit beim Aufruf von ssh
angeben, dass man diesen Schluessel verwenden will.
Man sollte unbedingt darauf achten, dass der private key nicht in
falsche Haende geraet. So ist es zB keine gute Idee, einen key, der fuer
root auf einem entfernten Host geeignet ist auf einem System abzulegen,
auf dem man nicht alleine(!) root ist (Vertrauen und so ...)
Will man ganz sicher gehen, so kann man den root-login auf dem
entfernten host deaktivieren (wenn es das nicht standardmaessig ist).
Datei hierfuer ist /etc/ssh/sshd_config oder /etc/sshd_config
Will man seinen Private Key gegen Missbrauch schuetzen, so kann man
diesem eine "Passphrase" geben. SSH fordert bei der Verwendung des
Schluessel die Eingabe der Passphrase an. Will man non-interaktiv
arbeiten, so laesst man diese Passphrase sinnvollerweise leer.
Wie das funktioniert und was man alles mit machen kann, will ich im
Folgenden an Beispielen zeigen.
Ich beziehe mich im folgenden auf OpenSSH_3.1p1 (vgl ssh -V). Das
schreibe ich extra dazu, weil sich (zu mindest soweit ich das sehe) das
Standardverhalten mancher Tools in letzter Zeit veraendert hat.
1. Schluesselpaar auf client ("rhb") generieren.
================================================
Es gibt verschiedene Schluesseltypen (RSA, DSA, ...) und SSH-Protokolle
(SSH1, SSH2). Hier mal RSA2/SSH2:
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/beckerra/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in id_rsa.
Your public key has been saved in id_rsa.pub.
The key fingerprint is:
a0:6a:bd:33:3b:8a:67:cc:6a:b3:2e:44:f3:1c:99:d8 beckerra_at_rhb
Haben also nun folgende Dateien:
$ ls .ssh/id_rsa*
.ssh/id_rsa .ssh/id_rsa.pub
Die id_rsa.pub besteht aus einer etwas laengeren Zeile.
2. Public_key auf den Host uebertragen
======================================
Den public_key uebertragen wir hier zB per ssh. Man kann ihn auch anders
uebertragen, wichtig ist nur, dass am Ende die Zeile aus id_rsa.pub auf
dem host im Verzeichnis ~/.ssh/authorized_keys2 liegt.
$ ssh -2 host "cat >>.ssh/authorized_keys" <.ssh/id_rsa.pub
beckerra_at_host's password: <== passwort eintippen
$ <== sind wieder auf dem client ("rhb")
3. Einloggen (Test)
===================
$ ssh -2 host 'uname -n' <== auf client
host <== ausgabe des Befehls "uname -n" auf dem host
$ <== sind wieder auf client
Wenn wie hier gezeigt keine Aufforderung fuer ein Passwort kommt, war es
erfolgreich. An dieser Stelle sind wir also in der Lage, per ssh2 auf
den anderen Host einzuloggen (username auf dem host gleich Username auf
client).
Anwendungsbeispiele fuer SSH
============================
1) login auf client (rhb => terminal)
beckerra_at_rhb:~$ ssh -2 terminal
Last login: Wed Mar 13 22:05:06 2002 from rhb.localnet
Linux 2.2.19.
The Supreme Court does it with all deliberate speed.
beckerra_at_terminal:~$ logout
Connection to terminal closed.
------------------------------------------------
2) Befehl auf entfertem Rechner ausfuehren:
beckerra_at_rhb:~$ uname -a
Linux rhb 2.4.16 #5 Sun Feb 10 19:29:14 CET 2002 i586 unknown
beckerra_at_rhb:~$ ssh -2 terminal "uname -a"
Linux terminal 2.2.19 #1 Mon Apr 2 06:52:17 CEST 2001 i586 unknown
-------------------------------------------------
3) Filetransfer mit scp:
beckerra_at_rhb:~$ ls -la unix_history.ps
-rw-r--r-- 1 beckerra users 153913 Jul 5 2000 unix_history.ps
beckerra_at_rhb:~$ scp unix_history.ps beckerra_at_terminal:.
unix_history.ps 100% |*****************************| 150 KB
00:00
Datei angekommen?
beckerra_at_rhb:~$ ssh -2 terminal "uname -n && ls -la unix_history.ps"
terminal
-rw-r--r-- 1 beckerra users 153913 Mar 13 22:07 unix_history.ps
-------------------------------------------------
4) Filetransfer mit tar-over-ssh:
rhb:~/test/ nach terminal:~/test/ kopieren
beckerra_at_rhb:~$ ssh -2 terminal "ls -la test/" <== existiert?
ls: test/: No such file or directory
beckerra_at_rhb:~$ tar cf - test/ |ssh -2 terminal "tar xf -" <== per tar
kopieren
beckerra_at_rhb:~$ ssh -2 terminal "ls -la test/" <== existiert?
total 292
drwxr-xr-x 2 beckerra users 4096 Feb 17 00:25 .
drwx--x--x 20 beckerra users 4096 Mar 13 22:13 ..
-rw------- 1 beckerra users 1471 Feb 17 00:25 lnk00000000.dat
-rw------- 1 beckerra users 896 Feb 17 00:25 lnk00000001.dat
[...]
-------------------------------------------------
5) Port-Forwarding, zB(!) sicheres POP3
10110:client ==[LAN]== Shell-Server(SSH) ==[Internet]==POP3-Server:110
auf Client:
ssh -2 -f -L 10110:pop3server:110 shellserver sleep 100000
Mails holt man dann mit POP3 von localhost:10110 ab. SSH sorgt dafuer,
dass localhost:10110 genauso reagiert wie der pop3server:110, wenn man
ihn direkt anspricht. Unterschied: Die Daten (also auch Passwort) werden
zwischen client und shellserver via SSH getunnelt, Sniffer im LAN sehen
also nur ssh-Datenverkehr zwischen diesen beiden Systemen. Die
Verbindung zwischen Shellserver und pop3-Server ist ungesichert. Aus
Sicht des pop3-Servers greift man von Shellserver aus zu.
...
Der Tunnel bleibt in obigem Fall 100000 sec lang offen, man kann
innerhalb dieser Zeit mehrfach auf den Weiterleitungsport 10110
zugreifen. Laeuft diese Zeit ab, waehrend gerade eine Verbindung offen
ist, dann bleibt der Tunnel bis zum Abbau der Verbidung stehen, danach
ist kein Zugriff mehr moeglich.
Anwendungsbeispiel: Studentenwohnheime mit LAN, potentiell viele
Sniffer.
Uni-Mannheim: rumms.uni-mannheim.de unterstuetzt pop3-ssl, man braucht
daher keinen SSH-Tunnel, vgl
http://www.uni-mannheim.de/rum/kommunikation/mail/ssl/, ggf stunnel
verenden.
-------------------------------------------------
Diese Beschreibung soll als Grundlage fuer eigene Ideen dienen und
erhebt keinen Anspruch auf Richtigkeit oder Vollstaendigkeit. Alles ohne
Gewaehr, Details sind der Doku zu entnehmen. Haftung ausgeschlossen.
Have fun!
Raphael Becker
-- 10 to the 6th power Bicycles = 2 megacycles
Dieses Archiv wurde generiert von hypermail 2.1.2 : 14. Mar 2002 CET