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

[Steffen Dettmer]

* Mike Fehla wrote on Wed, Sep 12, 2001 at 18:44 +0200:
> > 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
> > :)]
> 
> Mit Host-Key meinst dann den pub-key, über den dann auch der Client
> verfügt, richtig?

Eigentlich Hostkey Schlüsselpaar. Der Client sieht jedoch
logischerweise immer nur den Pub key.

> > 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.
> 
> Beim ersten Verbindungsaufbau ist das aber kein notwendiges Kriterium,
> denn dann kommt folgender Kommentar:

Eben, daß ist aber auch nicht sicher. Das ist Vertrauen. Wenn da
schon ein Hacker dazwischen sitzt, speicherst Du einen falschen
Hostkey und merkst es nicht. Die Sicherheit hängt davon ab, ob
der Key echt ist, und das kannst Du so ja nicht feststellen. Wenn
Du es wirklich sicher haben möchtest, kopierst Du die keys per
Diskette. SCP ist ja blödsinn, Du kannst ja nicht die Keys, die
SCP sicher machen sollen, über das (noch unsichere,
möglicherweise getäuschte/manipulierte) SCP kopieren. Da beißt
sich der Hund in den Schwanz.

> The authenticity of host 'hyper (192.168.100.9)' can't be established.
> RSA key fingerprint is [bla bla ...]
> Are you sure you want to continue connecting (yes/no)?

Und Du kannst(!) eben nicht sicher sein! Du kannst nur raten(!),
daß kein Angreifer Dir einen falschen Key zugespielt hat, aber
nicht wissen.

> > Bitte vergiß rhost, rlogin, rsh und den Kram (außer rsync). Wenn
> > jemand danach fragt, dann "no". Gilt auch für die SSH
> > configfiles!
> 
> Keine Sorge, aber möglich scheint das wohl zu sein, so stand das
> jedenfalls in der man-Page zum Protokoll 1.

Jaja, telnet und rlogin sind auch _möglich_, aber eben Mist. Ich
sehe die Gefahr, daß ein Benutzer denkt, es wäre sicher, aber
dann passiert nachher ein rsh Fallback oder solch ein Mist. Otto
Musterman merkt das vielleicht nicht mal. Daher abschalten,
verbieten, TCP-Wrappen und Firewallen (und zwar alles
gleichzeitig, nicht alternativ).

> > 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.
> 
> Aber eigentlich könnte ich ja das DSA-Schlüsselbund löschen, wenn ich
> nur den 1. Protokollstandard benutzen will. Den Protokollstandard legt
> der Client fest??

Im Prinzip ja, solange der Server das akzeptiert. Wenn Client v1
will, kann der Server auch sagen: bei mir gibt's nur v2 und Ende.
Aber in der Praxis wohl eher selten.

> > 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.
> 
> Also muß nicht jeder Nutzer auf dem Server sein Schlüsselpaar mittels
> ssh-keygen erzeugt haben, er kann es eben optional machen, und so eben
> Einfluss auf das symmetrische Kryptoverfahren oder den Schlüssellängen
> nehmen?

Es sind verschiedene Schlüssel. Der Server hat die vom Admin
erzeugten aus etc, der User hat eigenen oder eben nicht. Wenn
nicht, muß er sich eben per Passwort authentifizieren (falls der
Serveradmin das zugelassen hat. Ich hab das auf den meisten
Servern verboten. Da gibt's einen richtigen (Benutzer, Pub-) Key
in authorized_hosts, oder es wird disconnected. Keine Frage nach
Password mehr, damit ein Angreifer keine Passwörter durch
probieren hacken kann.

Man nimmt ja SSH, um Sicherheit zu erhalten. Macht man es
richtig, erkennt man, daß ein Passwort nur ein paar bits Entropie
haben, ein RSA Key jedoch ein paar hundert (ist irgentwie
Schlüssellänge durch 3 oder 10, weiß ich nicht mehr). Ergo ist
ein Passwort viel viel leichter zu "erraten", als ein RSA Key.
Wenn man es also sicher haben will, nimmt man nur RSA (oder eben
DSA) Keys mit brauchbaren Schlüssellängen (RSA>=1024). Um sicher
zu gehen, daß die Keys echt sind, kopiert man sich per Diskette.

Nur mal zur Info: Wenn das Verfahren von der deutschen
Kreditwirtschaft zugelassen werden sollte, müßte das noch
sicherer gemacht werden. Das heißt: Schlüsselerzeugung im
Sicherheitsraum, transport von Teilen (!) über verschiedene
Medien (z.B. zwei Disketten). Die Passphrase wird auch geteilt
(zwei Leute, falls einer überfallen wird oder böse ist). 

Dazu würde man es natürlich auch kaum erlauben, die Keys dann im
Klartext auf der Platte zu lagern, wie es bei Hostkeys üblich
ist, klar. 

oki,

Steffen

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