Gedanken zur sicheren Authentifizierung bei SSH?

Grüße!

Wirklich sichere Authentifizierungsverfahren gibt es nicht, klar. Daher versucht man es immer so sicher wie möglich zu halten. Doch bringen die in Online- und Printmedien vorgeschlagenen Methoden wirklich mehr Sicherheit?

Das habe ich mich gefragt, als ich neulich einen Artikel[1] im Linux-Magazin[2] gelesen habe.
Die Rede ist da von Public-Key-Authentifizierung[3] welche „einen deutlich besseren Schutz“ bieten soll als „das beste Passwort“.
Ein Passwort habe ich im Kopf und ich gebe es direkt ein. Dabei kann man mir über die Schulter gucken oder einen Keylogger verwenden. Schreibe ich das Passwort irgendwo hin ist das natürlich risikobehaftet.

Eine Public-Key-Authentifizierung dagegen basiert auf 2 Dateien im Homeverzeichnis. Einem privaten und einem öffentlichen Schlüssel. Dem Server wird der öffentliche Schlüssel bekannt gemacht, indem er in die Datei ~/.ssh/authorized_keys geschrieben wird. Das geht sehr komfortabel über das Kommando ssh-copy-id. Mit diesem öffentlichen Schlüssel chiffriert der Server beim Loginversuch nun eine Nachricht an den Client, die dieser nur mit dem zum öffentlichen Schlüssel passenden privaten Schlüssel dechiffrieren kann. Der Client sendet die entschlüsselte Nachricht zurück und damit weiß der Server, dass der Empfänger im Besitz des privaten Schlüssels ist.

Den privaten Schlüssel kann ich zwar mit einem Passwort schützen, das lässt sich aber wesentlich einfacher und unbemerkter knacken als bei der Variante per Bruteforce oder eine Wörterbuchattacke über Loginversuche auf dem Server an das Passwort zu kommen. Und das eigentliche Problem an der Sache ist eben, dass diese beiden Dateien für mich lesbar in meinem Homeverzeichnis liegen. Kriegt jemand diese Datei, dann hat er quasi gewonnen. Und das lässt sich dann auch super zuhause beim Angreifer knacken – da gibt es nirgendwo eine Logdatei, die fehlerhafte Login-Versuche aufzeichnet, so wie es bei dem fehlerhaften Versuch an meinem SSH-Login passiert.
Jetzt mag der ein oder andere sagen, dass die /etc/shadow auch nur eine Datei ist die man, wenn man sie kopiert hat, lokal beim Angreifer bearbeiten kann, aber dazu sind eben in den allermeisten Fällen root-Rechte auf dem Rechner notwendig, auf dem die Datei liegt. Bei meinem privaten Schlüssel in /home/cisa/.ssh/ sieht das anders aus: Eine geeignete Sicherheitslücke in dem Browser meiner Wahl oder irgend einer anderen Software, die einen Zugriff auf meine Dateien via Internet bietet, reicht aus.

Noch größer schätze ich das Problem ein, dass man mit einem privaten Schlüssel meistens Zugriff auf mehrere Systeme hat, während viele (sicherheitsbewusste) Personen für verschiedene Systeme auch verschiedene Passwörter benutzen. Man kann bei einem Login via SSH und Public-Key-Authentifizierung zwar auch einen anderen privaten Schlüssel, der mit einem anderen Passwort geschützt sein kann, angeben (das geht sogar recht komfortabel über die ~/.ssh/config mit IdentityFile, damit man nicht jedes mal die Kommandozeilenoption eintippen muss), doch macht man das wenn man sich erstmal mit dieser Methode in Sicherheit wiegt?

Jetzt bin ich natürlich super gespannt auf die Meinung meiner Leser. Also husch husch einen oder mehrere Kommentare oder Blog-Einträge verfassen. E-Mails sind natürlich auch OK.

[1] Linux-Magazin, Ausgabe 08/09, S. 90 „Grundlagen: Sichere Remote-Logins“
[2] http://www.linux-magazin.de/Heft-Abo/Ausgaben/2009/08
[3] http://de.wikipedia.org/wiki/Public-Key-Authentifizierung

Aug 18th, 2009 | Posted in Linux
  1. Aug 19th, 2009 at 22:02 | #1

    Genau sowas meine ich zum Beispiel:
    http://www.heise.de/newsticker/Kritische-Luecke-in-IM-Pidgin–/meldung/143730

    ZACK! ist der private Schlüssel futsch.

  2. cisa
    Aug 29th, 2009 at 10:21 | #2
  3. Joern Bredereck
    Apr 24th, 2010 at 17:56 | #3

    Wenn du den Key mit einer Passphrase schützt, hast du doch „best-of-both-worlds“: Der private-key alleine bringt dir ohne die Passphrase nichts und sollte dir jemand beim Eingeben des Passworts zusehen, kann er ohne den Key mit deinem Kennwort nichts anfangen. Ich finde das sicher genug…

  4. Apr 24th, 2010 at 19:03 | #4

    Joern Bredereck :
    “best-of-both-worlds” – Ich finde das sicher genug…

    Der Key liegt meistens im Homeverzeichnis des Benutzers. Jeder Prozess des Benutzers, zum Beispiel der Browser, kann den Key lesen.
    Wenn der Key erstmal weg ist, dann kann dieser in Ruhe auf dem System des Angreifers via Bruteforce geknackt werden.
    Versuch das mal bei einem SSH-Server. Solange Du die /etc/shadow nicht hast ist das wesentlich schwieriger. Die Tatsache, dass der SSHd nach 3 Versuchen die Verbindung trennt treibt die Zeit bis das Passwort geknackt ist sehr nach oben. Dazu kommen noch Werkzeuge wie fail2ban.

    Gut, wenn man sein Passwort natürlich immer recht offen eintippt… Blöd.

    Aber per se sagen, dass diese Variante auf jeden Fall bevorzugt werden soll (meistens ohne den Hinweis auf die Passphrase), halte ich persönlich für verwerflich. Das ist dann trügerische Sicherheit.

    Vielleicht kann sowas irgendwann mal helfen:
    http://www.heise.de/security/meldung/Sicherheit-durch-Virtualisierung-972500.html

  5. Joern Bredereck
    Apr 25th, 2010 at 02:27 | #5

    Dann gäbe es noch die Möglichkeit eine andere Userid für die SSH-Sessions zu benutzen. Du kannst als User A surfen und als user B SSH-Verbindungen aufbauen. Genaugenommen muss dein Keyfile auch nicht in $HOME/.ssh/$KEYFILE liegen, sondern kann an einer beliebigen anderen Stelle im Dateisystem liegen. Du musst dir dann eben nur einen Alias stricken, der den ssh-client mit dem richtigen Identity-Parameter aufruft.

    Und wenn dir das immernoch zu unsicher ist, kannst du dir auch mal „Portknocking“ angucken:

    http://en.wikipedia.org/wiki/Port_knocking

Leave a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>