Public Key Autorisation in SSH/Putty

[kama]

Hallo,

ich habe da mal so eine Frage bzgl. der Sicherheit der Public-Key Autorisation.

Sprich auf meinem Rechner der Private-Key und auf dem Server Public-Key.
Somit kann ich mich ohne Eingabe eines Passwort einloggen.

Mir ist durchaus klar, dass wenn einer meinen Rechner Hackt, ich selbstverständlich ein Problem habe....

Die Frage ist, gibt es noch andere Risiken?

Ich transferiere auf dem Zielrechner ja immer nur den Public-Key, der private Key bleibt bei mir....


Vielen Dank für eure Hinweise.
MfG
Karl Heinz Marbaise

[lufthansen]

was möchtest du den genau machen ?
Denn es gibt die möglichkeit die möglichen befehle einzuschränke z.B. für ein backup oder ähnliches.

[isotopp]

ich habe da mal so eine Frage bzgl. der Sicherheit der Public-Key Autorisation.

Sprich auf meinem Rechner der Private-Key und auf dem Server Public-Key.
Somit kann ich mich ohne Eingabe eines Passwort einloggen.

Mir ist durchaus klar, dass wenn einer meinen Rechner Hackt, ich selbstverständlich ein Problem habe....

Die Frage ist, gibt es noch andere Risiken?

http://kris.koehntopp.de/artikel/kryptogrundlagen/

In putty kannst Du mit puttygen ein Keypaar generieren. Dieses Keypaar ist in IEEE-Format, man kann es mit "ssh-keygen" und der Option -i ins OpenSSH Format konvertieren.

Das Private-Keyfile sollte mit Paßwort generiert werden. So kann der Private Key auch dann sicher bleiben, wenn der Rechner mit dem Private Key kompromittiert wird.

Mit Hilfe von pageant unter Windows oder ssh-agent unter Linux kann man den Private Key in den Hauptspeicher laden und dort entschlüsseln. Es ist dann möglich, sich mit putty bzw. openssh auf einem entfernten Rechner einzuloggen, ohne jedes einzelne Mal den Key von Hand durch Eingabe des Paßwortes entschlüsseln zu müssen.


Auf dem Zielrechner installierst Du Deinen Public Key in $HOME/.ssh/authorized_hosts. Weil dies ein Public Key ist, besteht kein Risiko. Das OpenSSH-Protokoll verlangt nun vom Quellrechner einen Beweis der Kenntnis des Private Key, um ein Login auf dem Zielrechner zuzulassen. Wenn Du Dich also von Deiner Windowskiste "local" auf dem Linux "remote" einloggen willst, dann wird remote einen Block Zufallszahlen (eine Challenge) erzeugen und von "local" verlangen, daß diese mit Deinem Private Key unterschrieben werden.

http://kris.koehntopp.de/artikel/krypto ... img12.html
http://kris.koehntopp.de/artikel/krypto ... img13.html

local sendet nun den Block Zufallszahlen unterschrieben an remote zurück. remote kennt Deinen Public Key und kann testen, ob die empfangenen Daten mit Hilfe dieses Public Key "aufgehen" und ob die Signatur stimmt. Wenn ja, kennt local den Private Key von Dir und damit darfst Du Dich einloggen.

[thorsten]

Wer an den public key des Linux Servers kommt, hat nichts gewonnen - dafür ist es ja der public key.

Den könntest du sogar auf deiner Homepage bekannt machen. Somit kann jeder, der Support von dir haben mag, den Key in seine authorized_keys packen und du loggst dich ein. :)

Warum aber erstellst du einen key ohne Passwort? Unter Linux gibt es den sshagent, der nur einmal beim Starten der session (z.B. KDE, Gnome) das key Passwort abfragt und dann immer im Speicher hält.
Unter Windows gibt es bei putty pagent (?) mit der gleichen Aufgabe.

Dann kann dir - bei entsprechend gutem Passwort - sogar der private key geklaut werden, ohne dass du innerhalb von Sekunden/Minuten sämtlichen von dir betreuten Maschinen einen neuen Key unterschieben und den alten löschen mußt.
Dann hast du nämlich u.U. auch Stunden/Tage bis der Angreifer den key geknackt haben wird.

Hier mal mein Wikieintrag für den sshagent unter debian/sarge bzw. Ubuntu/breezy badger

Code: Select all

chmod 755 /home/USERNAME
 chmod 700 ~/.ssh
 chmod 600 ~/.ssh/id_dsa*

nötige Software installieren
============================

 aptitude install keychain ssh-askpass ssh-agent

Konfigurationsdateien
=====================
In die ~/.bashrc folgendes eintragen

 keychain -q ~/.ssh/id_dsa
 source ~/.keychain/${HOSTNAME}-sh

in die ~/.ssh/config folgendes eintragen

host host.tld
        User admin
        Cipher blowfish
        Protocol 2
        ForwardAgent yes
        ForwardX11 yes
        IdentityFile /home/${USER}/.ssh/id_dsa
        Compression yes

Das 'User admin' bewirkt, dass man sich auch als normaler User (!=admin) mit ssh host.tld anmeldet - ssh also ein ssh admin@host.tld absetzt.
BTW: Wir brauchen ein Wiki hier ;)

EDIT: jetzt war isotopp schneller :-/

[Joe User]

<OT>

BTW: Wir brauchen ein Wiki hier ;)

Ist bereits in Vorbereitung ;)

</OT>