Es gibt anscheinend doch einen qualitativen Unterschied zwischen den beiden Schlüsseln. Den Hinweis darauf hab ich im Putty-Artikel gefunden, dort steht sinngemäß, daß man den Public Key nicht unbedingt speichern brauch, da man ihn mit Hilfe des Private Keys errechnen kann. Da SSH nicht sicher wäre, wenn dies auch umgekehrt möglich wäre, muss es einen Unterschied geben!
SSH Unterschied Public / Private Key
Anmeldungsdatum: Beiträge: 355 |
|
||
(Themenstarter)
Anmeldungsdatum: Beiträge: 29 |
Jean_Baptiste_le_Rond schrieb:
Ups, deinen Beitrag hatte ich tatsächlich übersehen, direkt zum Edit hochgescrollt, sry. Den 2. Beitrag allerdings schon, allerdings halte ich das ja für eine Implementierungsmethode von SSH. In dem Putty Artikel steht allerdings explizit errechnen, aber vielleicht häng ich mich auch zu sehr daran auf, und Putty schaut auch einfach nur nach. |
||
Anmeldungsdatum: Beiträge: 3459 |
Genau wie bei GPG muss sich auch bei SSH der public key immer aus dem private key errechnen lassen. Sonst wäre das System etwas ad absurdum geführt. |
||
Anmeldungsdatum: Beiträge: 12085 Wohnort: Berlin |
Wieso das? Nach meinem Verständnis von asynchroner Verschlüsselung können die mit einem der Schlüssel verschlüsselten Daten nur mit dem jeweils anderen Schlüssel entschlüsselt werden. Die Berechnung eines Schlüssels aus dem jeweils anderen habe ich noch nirgends erwähnt gesehen und ihre Notwendigkeit erschließt sich mir aus dem vorgenannten Prinzip auch nicht. Kannst Du das näher erläutern? |
||
Anmeldungsdatum: Beiträge: 779 Wohnort: Görlitz |
Nein. Es geht hier um SSH und nicht um PGP oder ähnliches. SSH tickt anders. D.h. Nachrichten werden in SSH verschlüsselt und nicht signiert, wie man das mit einer Mail machen kann. Dazu werden mit ssh-keygen 2 Schlüssel erzeugt, die nicht austauschbar sind. Für RSA Keys schaut das so aus. ~/.ssh/id_rsa (private Key) ~/.ssh/id_rsa.pub (public Key) Beide Schlüssel werden unverschlüsselt, aber mit den nötigen Rechten versehen, in '~/.ssh' gespeichert. Man kann auch einen anderen Speicherort und/oder Namen angeben. Das muss aber in '/etc/ssh/ssh_config' angegeben werden. Verändert man später die Rechte, kann es vorkommen, dass man sich mit dem Schlüssel nicht mehr einloggen kann. Daher die Rechte nicht ändern. Man kann aus dem private Key den public Key erzeugen.
Der private Key kann zur zusätzlichen Sicherheit ein Passwort bekommen. Damit ist aber der Key für eine automatische Anmeldung nicht mehr verwendbar. Es ist mehr ein schwacher Schutz gegen den Diebstahl des Keys. Der private Key darf nie herausgegeben werden (ausser an das Backup, das man dringend haben sollte). Mit dem private Key kann man sich dort einloggen, wo der public Key in '~./.ssh' auf der Gegenseite hinterlegt wurde. Daraus folgt, dass man den public Key auf die Maschine bringen muss, die man erreichen will. Da der public Key die Tür zum Login öffnet, liegt es in der Verantwortung des Besitzers des anderen Rechners, ob er den public Key auch installiert. Daraus folgt dann, dass der public Key, wie der Name schon sagt, kein Geheimnis ist. Wer diesen installiert, öffnet den Rechner. Selbst schuld, wenn das jemand mit einem geklauten Key macht, ohne den Besitzer zu informieren. 😉 Da der private Key die durch den korrekt installierten public Key geöffnete Tür des anderen Rechners verwenden kann, muss man auf den private Key aufpassen, weil das zum Vertrauensschutz gegenüber dem Besitzer des anderen Rechners gehört. Es spricht nichts dagegen, auf allen Rechnern, die man selbst kontrolliert, den gleichen public/private Key zu verwenden. Besteht der Verdacht, dass der private Key geklaut wurde, ist das alleine noch kein Grund zur Panik. Der Dieb braucht zum private Key noch die Information darüber, wo er sich alles damit einloggen kann. Er braucht noch die IP und den Login der Gegenseite. Bei Gefahr schaut man mal auf der Gegenseite nach, wer so alles sich dort eingeloggt hat, in /var/log/auth.log. Gibt es da einen Hinweis, dass der Key missbraucht wurde, dann sofort neue Keys erzeugen und die korrekt installieren, damit ist alles wieder zu. Man sollte sich allerdings fragen, wie der Key abhanden kommen konnte ... Ich lege zu diesem Zweck einen 2. Account auf der Gegenseite an, den ich von einem 2. PC bei mir zu Hause erreichen kann. Damit kann man die Keys auch noch tauschen, wenn der Dieb seine Keys bereits installiert und mich rausgeworfen hat. Anders schaut es bei einem Notebook aus, wenn das geklaut wurde. Dann sofort alle verteilten public Keys tauschen. Man hat ja immer noch den 2. Account. Und in '/var/log/auth.log' nachschauen, ob es Merkwürdigkeiten gibt. Ist das nicht der Fall, kann davon ausgegangen werden, dass der private Key auf dem geklauten Notebook noch nicht missbraucht wurde. Ein SSH Key kann nicht als ungültig erklärt werden, wie man das bei PGP machen kann. Mit SSH erzeugt man eine neues Keypaar, verteilt dieses, das ist alles.
Hat der Dieb meinen gesamten Traffic einer SSH Sitzung aufgezeichnet, kann er mit entsprechendem Wissen den Klartext erhalten. Es reicht nicht, wenn Teile der Session protokolliert werden. SSH verwendet zum Verschlüsseln einen symmetrischen, neuen Key, der nie sichtbar wird. Dieser neue Key wird mit Hilfe vom public/private Key am Beginn der Session ausgetauscht. Hat der Dieb, per 'social engineering', noch andere Informationen über mein SSH-Verhalten, z.B. die IP des Remote-Rechners und die Login-Namen, dann wird es gefährlich. Warum, braucht nicht weiter erklärt zu werden. Fazit: SSH ist sehr sicher, wenn man es korrekt einsetzt und nicht allzuviele Leute die gleichen Accounts verwenden. Traffic mitschneiden ist unwahrscheinlich, und wie man sich gegen 'social engineering' sichert, wird hoffentlich jeder selbst wissen. Noch ein wenig Eigenwerbung, ganz unten auf der Seite: http://www.youtube.com/watch?v=Hxsl-jj2Bq0 Es ist ein langer Text geworden, aber SSH muss man korrekt verstehen, nur dann ist es sicher und alles geht wie von selbst. 😉 Happy Computing |
||
Anmeldungsdatum: Beiträge: 355 |
Wie SSH-Authentifizierung funktioniert, weiß der Threadersteller schon, das geht doch aus den bisherigen Beiträgen klar hervor. |
||
Anmeldungsdatum: Beiträge: 12085 Wohnort: Berlin |
|||
Anmeldungsdatum: Beiträge: 3459 |
Der Public Key muss aus den Private Key mathematisch berechenbar sein, ansonsten gäbe es nie einen Zusammenhang zwischen den beiden. Das bei SSH mit RSA der öffentliche Exponent, etc. im private Key File mitgespeichert wird, ist noch ein anderer Punkt. Mathematisch aber jederzeit errechnbar. Das hat auch nichts mit der asynchronen Verschlüsselung zu tun. Das ist dann das Verfahren, wie es eben angewendet wird. Bis eben, dass Public und Private Key mathematisch zusammenhängen müssen um solch ein Verfahren zu ermöglichen |
||
Ehemalige
Anmeldungsdatum: Beiträge: 2748 Wohnort: Leipzig |
Könntest du mir das einmal vorrechnen? Laut dieser Berschreibung besteht der öffentliche Schlüssel bei RSA aus dem Zahlenpaar (e, N) und der private Schlüssel aus dem Zahlenpaar (d, N). Deine Behauptung ist, dass man e aus d und N errechnen kann. Das glaub ich nicht, lasse mich aber gerne von dir eines besseren belehren. |