linux-l: Wer hat SSH richtig verstanden...,

Mi Sep 12 11:47:50 CEST 2001

* Mike Fehla wrote on Tue, Sep 11, 2001 at 23:57 +0200:
> OpenSSH unterstützt nun wohl beide SSH-Standards, 

Du meinst hier Protokoll-Versionen, ja?

> Am Anfang erzeugt der Server (auf den man sich remote einlogen will) ein
> Schlüsselpaar (öffentlicher und privater Schlüssel) für die asymetrische
> Kryptographie. 

Das macht der Admin einmalig bei einem neuen System. Dies ist
sicherheitsrelevant, deshalb macht man ein Backup :).

> Wenn sich dann der Client an dem bestimmten Port beim
> Serveranmeldet, sendet der Server seinen öffentlichen Schlüssel zum
> Client. 

Ja, aber soweit ich weiß ist das nicht der "Host"-Key sondern ein
neuer, nur ein paar Stunden gültiger RSA-Key. Vermutlich wird der
mit dem Hostkey signiert und dann dies (ne Art Zertifikat) mit
versendet. Der Client prüft, ob das Zertifikat mit dem richtigen
(lokal gespeicherten pub) (sec-)key signiert ist. [Bin mit den
Namen durcheinander gekommen, aber ist ja klar, was gemeint ist
:)]

> Auf dem Client wird nun ein Schlüssel zur symmetrischen
> Kryptographie ( 3DES) erzeugt (Session Key), welcher nun nur mit dem
> öffentlichen Schlüssel verschlüsselt wird, um diesen wieder an den
> Server zurücksendet.

Weiß ich auch nicht genau, aber irgentwie fehlt hier ne
Zufallszahl. Die brauch man, damit man keine playback-attacken
machen kann. Man könnte (ist üblich, weiß aber nicht, ob hier):

- Server schickt 8 byte Zufallszahl
- Client fügt 8 byte Zufallszahl hinzu
- das ergibt dann 16 byte 3DES key
- dieser wird mit dem Server-Pubkey verschlüsselt und versendet

Damit liegt dann der in Sessionkey nicht in der Hand einer Seite,
sowas ist immer schön. 

> Dieser ist im Besitz des privaten Keys, und kommt somit
> exklusiv an den den symmetrischen Schlüssel. Nun können Server
> und Client mit einem symmetrischen Kryptoverfahren sicher
> kommunizieren.

Noch nicht, denn der Client weiß ja noch nicht, ob der Server
echt ist, d.h., ob dieser "seinen" sec key wirklich hat. Soweit
bekommt man das ja auch mit playback hin (Zufallszahl Server ist
dann immer die gleiche, aber der Client würde das nicht
"merken"). Hier kann man dann ein weiteren Handshake(-Teil)
machen:

- Client schickt zusätzlich ne weitere Zufallszahl im "Klartext"
  mit
- Der server verschlüsselt diese mit dem entschlüsselten
  Sessionkey (das kann er nur machen, wenn er wirklich den Seckey
  hat) und sendet die nun verschlüsselte Zufallszahl zum Client
- der Client entschlüsselt die Zahl und vergleicht sie mit (der
  zuvor gespeicherten, orginalen) Zufallszahl

> Aber wie sieht das eigentlich mit der Authentifikation aus? Läuft dann
> der normale Loginprozess ab, oder ist das dann anders (ich selbst habe
> mich schon öfters via ssh remote eingelogt, und mußte mich
> authentifizieren).

Jetzt gibt es einen gesicherte Verbindung. Die hat folgende
Eigenschaften:
- Die Verbindung zwischen Client und Server ist verschlüsselt
- Der Client weiß, daß er wirklich den richtigen Server hat (da
  dessen Host-Pub-Key lokal gespeichert ist)
- Der Server sieht aber nur "irgenteinen" Clienten.

Letzeres ist doof. Jetzt hat ja jeder Zugang. Also muß sich jetzt
noch der Client authentifizieren, z.B. eben mit einem Password
gegenüber /bin/login, d.h., jeder darf login starten, aber nur
einer mit Passwort darf es "benutzen". Damit kann man natürlich
Passwörter raten!

> Nur kann man ja beim Schlüsselerzeugen ein Passwort
> angeben, oder es auch sein lassen, welche Bedeutung hat denn dieses
> Passwort?

Das ist ein weiterer (asymmetrischer) Key. Dieser gehört einem
Client und kann (bzw. muß) beim Server registriert sein (in
authorized_keys). Nun kann der Client nach obrigem Handshake
diesen pubkey mitschicken. Damit nun der Server weiß, das der
Client auch wirklich den passenden Sec-Key hat, muß
beispielsweise wieder eine Zufallszahl im Klartext an den Client
übertragen werden, der diese mit seinem Seckey signiert (also ein
Zertifikat über diese Zahl erzeugt). Dieses Zertfikat kann vom
Server geprüft werden (der die Zufallszahl gepeichert hat und mit
der durch die RSA Entschlüsselung gewonnenen vergleicht). Damit
ist bewiesen, daß der Client den sec key hat.

Wenn man das nicht machen würde (den Zufallszahlenkram), könnte
man eine "Man in the middle" Attacke konstruieren. Ein Angreifer
"klemmt" sich in die Leitung. Er kennt (durch sniffen) die pub
keys. Er kann sich gegenüber dem Server dann ja wie der richtige
Client verhalten, ohne den seckey zu haben und umgekehrt.

Deshalb muß der Client auch den pubHostKey speichern, ansonsten
könnte ein ManInTheMiddle einfach zwei eigene Schlüsselpaare
erzeugen. Mit dem einen spielt der Server und akzeptiert den
Client (und kann als "Server" dessen Daten lesen), mit dem
anderen spielt er Client gegenüber dem echten Server. Er sendet
einfach alle Daten des richtigen Clients "neuverschlüsselt" an
den richtigen Server weiter, kann aber dabei mitlesen.

Deshalb die Zufallszahlen und der Client-Key.

Nun kann der Client also mit seinem Key Dienste des Servers
benutzen. Aber Schade, wenn jemand den Clientkey klaut. Deshalb
verschlüsselt man den Key sicherheitshalber mit einem Key, der
aus einer Passphrase abgeleitet wird. Benötigt man den Key, kann
SSH den erstmal nicht lesen. Er fragt nach einer Passphrase,
leitet einen Key daraus ab, und versucht damit, den Key zu
entschlüsseln. Klappt das (erkennbar an diversen
syntax-Prüfungen, z.B. ob das entschlüsselte Ergebnis überhaupt
ein SSH Key darstellt), war die passphrase wohl richtig. Oder das
Ergebnis stimmt zufällig. Es ist ein "guter" SSH Key, aber der
"falsche". Das wird später durch das Zufallszahlen tauschen
bemerkt. Klappt es nicht, war die Passphrase auf jeden Fall
falsch.

> Weiterhin weiß ich, dass nach einer definierten Zeit ein neuer
> Session-Key erzeugt wird, der dann wieder über ein asymetrischen
> Verfahren übertragen wird.

Man kann nach einer Zeit (oder nach bestimmter Datenmenge)
sicherheitshalber den Sessionkey tauschen, d.h. man fängt wieder
so ein Handshake von fast ganz vorne neu an. Ein Sessionkey ist
ja schnell (im Vergleich zu RSA und so) und funktioniert für
viele Daten, aber das weiß man nie so genau. Man möchte nie mehr
also nötig Daten mit einem Schlüssel erzeugen. Deshalb wird auch
der Hostkey so wenig wie möglich benutzt. Vermutlich spielt das
jedoch in der Praxis kaum eine Rolle, denn ein 3DES zu knacken,
sollte eben nicht so möglich sein.

> Auch ist mir bekannt, dass der Client schon
> über den üffentlichen Schlüssel des betreffenden Servers verfügen kann,
> um notfalls einen veränderten öffentlichen Schlüssel zu erkennen
> (kleines Sicherheitsfeature). 

Nein. Er *muß* über den Schlüssel verfügen. Das ist ein
elementares Sicherheitsfeature. Sonst wüßte der Client ja nicht,
ob yourserver.de wirklich der echte ist, oder ob ein Attacker das
DNS manipuliert hat, und ein ManInTheMiddle konstruiert.

Wenn man es richtig macht, dürfte man eigentlich die known_hosts
nicht automatisch beim ersten connect erzeugen lassen, sondern
müßte /etc/ssh/ssh_host_key.pub per Diskette auf sicherem Weg
(d.h. vor Veränderungen geschützt, ein Geheimnis ist es nicht)
übertragen. OpenSSH zeigt deshalb auch edn Fingerprint an, jedoch
wird in der Praxis wohl kaum jemand diesen verifizieren... Ich
mache dann meistens den ersten connect sofort nach der
Installation, wenn der Host noch nicht "richtig" im Netz ist; aus
dem lokalen LAN. Damit ist eine ManInTheMiddle-Attacke
unwahrscheinlich (aber nicht unmöglich).

> Und auf dem Server selbst kann noch der
> entsprechende Client in eine Tabelle (~/.rhosts) stehen, um sich sogar
> ohne Passworteingabe sich einzuloggen.

Bitte vergiß rhost, rlogin, rsh und den Kram (außer rsync). Wenn
jemand danach fragt, dann "no". Gilt auch für die SSH
configfiles!

> Ok, hier sind Schlüsselpaare, einmal der DSA-Key, einmal der RSA-Key und
> ein Host-Key. RSA und DSA sind mir klar, hier geht es um die
> Kompatibilität zu SSH1 und SSH2. Aber was ist den mit dem Host-Key??

Vermutlich RSA :) Im Ernst: weiß ich auch nicht, vielleicht ist
das noch eine alte Datei? Die anderen beiden Schlüssel sind ja
auch Hostkeys.

> Mir scheint, dass im /etc -Verzeichnis die globalen Keys abgelegt sind,
> nun kann ja auch jeder User sein eigendes Schlüsselpaar erzeugen und ins
> ~/.ssh Verzeichnis speichern

Ja, oder auf Diskette oder sonstwo :)

> Sogar die Config-Files können lokal ins
> Home-Verzeichnis abgelegt werden.  Sind dann also die Schlüssel im /etc-
> Verzeichnis dann unbedingt notwendig?

Ja, die sind eben nicht benutzer-Abhängig. Die ~/.ssh/ keys sind
"optional" und dienen der Client Authentifizierung, die in /etc/
dienen der Server-Authentifizierung.

> Und gilt dann nicht auch der
> umgekehrte Fall, dass sshd nur mit den globalen Einstellungen (wieder
> meine ich das /etc-Verzeichnis) betreibt, so dass sich alle User
> trotzdem am Server sich anmelden können??

Das System /etc konfiguriert Optionen für ssh und sshd (also
client tool und Server daemon). Ein Benutzer darf Optionen des
client tools überschreiben oder hinzufügen, jedoch nicht für den
Daemon.

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.