linux-l: Wer hat SSH richtig verstanden...,
Mike Fehla
mike.fehla at gmx.de
Mi Sep 12 18:44:24 CEST 2001
> > 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
> :)]
Mit Host-Key meinst dann den pub-key, über den dann auch der Client
verfügt, richtig?
> > 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.
Beim ersten Verbindungsaufbau ist das aber kein notwendiges Kriterium,
denn dann kommt folgender Kommentar:
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)?
> 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).
Dito.
> > 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!
Keine Sorge, aber möglich scheint das wohl zu sein, so stand das
jedenfalls in der man-Page zum Protokoll 1.
> > 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.
Stimmt! Aber es werden trotzdem 3 Keys erzeugt, welcher RSA-Key ist nun
wofür wichtig?
Hier ein Auszug aus dem Makefile von OpenSSH:
[..]
host-key-force: ssh-keygen$(EXEEXT)
./ssh-keygen -t rsa1 -f $(DESTDIR)$(sysconfdir)/ssh_host_key -N
""
./ssh-keygen -t dsa -f $(DESTDIR)$(sysconfdir)/ssh_host_dsa_key
-N ""
./ssh-keygen -t rsa -f $(DESTDIR)$(sysconfdir)/ssh_host_rsa_key
-N ""
[..]
> > 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.
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??
> > 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.
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?
Wieder viele, viele Fragen. Danke Dir trotzdem erst einmal, für Deine
ausführlichen Erläuterungen.
Gruß+Danke, Mike
Mehr Informationen über die Mailingliste linux-l