Unsicherheiten bei SSH mit Keys

Hinweis: In dem Thema Unsicherheiten bei SSH mit Keys gibt es 7 Antworten. Der letzte Beitrag () befindet sich ganz unten auf dieser Seite.
  • Hallo,


    beim Lesen von Artikeln über die Verwendung von Crypto Keys fehlt mir, dass in einfacher Sprache die Hintergründe mehr beleuchtet werden.


    Mit "ssh-keygen" erstellt man z.B. ein Schlüsselpaar bestehend aus "private" und "public" Key. Doch den "public" Key veröffentlicht man nicht auf seiner Webseite, sondern gibt ihn vertrauensvoll an Personen die Zugang benötigen. Versuchen diese dann einzuloggen wird der "private" Key dafür verwendet den "public" Key zu prüfen. Stimmt wenigstens das soweit?


    Doch bedeutet das nicht auch, dass der "Private" Key besonders geschützt werden müßte anstatt ihn in ~/.ssh/ sitzen zu lassen?


    Brauche ich den "public" Key lokal auf dem System dann noch?



    Grüße,
    icmp

    ---
    freundliche Grüße, icmp

    Für den Inhalt des Beitrages 111692 haftet ausdrücklich der jeweilige Autor: icmp

  • Doch bedeutet das nicht auch, dass der "Private" Key besonders geschützt werden müßte anstatt ihn in ~/.ssh/ sitzen zu lassen?

    Warum sollte der noch weiter geschützt werden?
    Ansehen darf ihn eh nur der User und root.

    Code
    ls -al ~/.ssh

    Für den Inhalt des Beitrages 111697 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Die mit ssh-keygen erzeugten Schlüsselpaare werden für alle Dinge, die man mit ssh machen kann, verwendet (und das sind viel, viel mehr, als nur sich irgendwo remote einzulogggen).
    Sie auf einem Webserver zu veröffentlichen ist etwas sinnfrei.
    Aber den Public- Key dieses Paares kannst du jederzeit bedenkenlos dort veröffentlichen.
    Das ist egal.
    Man könnte das sogar absichtlich wollen, um aktuelle Keys abzugleichen.
    Wenngleich es dafür sehr viel sicherere und bessere Methoden gibt.
    Aber das ist KEIN Risiko.
    Er wird nicht umsonst public Key genannt.


    Beim Private- Key dieses Paares sieht das anders aus.
    Wer den kennt, kann sich jederzeit auf allem Maschinen unter deinem dortigen Useraccount anmelden mit deinen dortigen Rechten.
    Hat jemand anders diesen Private- Key, bist du kompromittiert.
    Punkt.


    Prinzipiell musst du diesen Private-Key nicht einmal speichern.
    Du könntest ihn auch auswendig lernen, und bei jedem Gebrauch frisch eintippen.
    Oder du lagerst ihn auf Papier im Tresor deiner Oma, die eine private Standleitung zu dir unterhält.
    Dann muss deine Oma das Tippen übernehmen.


    Ob du das dann für sicherer hältst, oder nicht, ist nur eine Frage deiner Paranoia.
    Die Bude deiner Oma ist überwachungstechnisch vermutlich leichter zu knacken, als ein .ssh in deinem Home.


    Man kann als normaler User bei den allermeisten Linuxsystemen die Dateien und Verzeichnisse anderer User lesen.
    Das ist Defaulteinstellung; und die Meisten scheren sich nicht darum ihr System da etwas zu härten.
    Mit ssh klappt das nicht.
    Dort sind die Rechte sehr restriktiv gesetzt. Und ssh wird nicht funktionieren, wenn du da dran rumspielst. Sobald jemand anders deinen Private- Key lesen KÖNNTE, verweigert ssh radikal. Spiel ruhig mal mit den Rechten in .ssh im Home und den Rechten mit den Dateien, die dort drin liegen.


    Die damit erreichte Sicherheit ist ein allgemein akzeptierter Kompromist®™ zwischen tatsächlicher Sicherheit und praktikabler Anwendung.
    Kannst'e so steh'n lassen.


    Falsch ist deine Auffassung davon, wie das wirklich abläuft.
    Die Key- Paare werden nur verwendet, um die festzustellen, ob die eingehende Verbindung erlaubt werden soll, oder nicht.
    Mehr nicht. Es kann weder festgestellt werden, ob der damit verbundene Useraccount auch tatsächlich von diesem User verwendet wird. Wer den Private- Key hat, IST aus Sicht des Systems dieser User, WENN dieses Key- Paar diesem User zugeordnet wurde.
    Das Key- Paar selbst ist davon völlig unabhängig.


    Es ist nicht möglich all die Fragen in einem Post erschöpfend zu beantworten.
    Das bedarf jahrelangen Studiums.


    Es gibt sehr viele verschiedene Methoden etwas zu verschlüsseln.
    Deine (von mir so vermutete) Vorstellung davon, trifft eher auf die Verschlüsselung einer Mail oder eines Dokumentes zu.
    Man verschlüsselt eine Mail mit dem öffentlichen Schlüssel des Empfängers, sendet ihm das verschlüsselte Dokument/Mail, und der kann sie dann mit seinem privaten Schlüssel wieder lesbar machen.
    Das ist Einbahnstraßen- Kommunikation.
    Will dieser Empfänger dir eine verschlüsselte Antwort schicken, so muss er jetzt deinen öffentlichen Schlüssel nehmen, seine Nachricht damit verschlüsseln, damit dann letztlich du mit deinem privaten Schlüssel das Zeuchs entziffern kannst. Deshalb MUSS man seine Public- Keys auf einem sogeannten Key-Server veröffentlichen, damit die anderen etwas speziell für dich verschlüsseln können.
    Eine zweite Einbahnstraße. Und erst zwei Einbahnstrassen a zwo Spuren machen eine Datenautobahn.
    Etwas umständlich, aber systemisch notwendig.
    (Manchen könnte man die Empfehlung geben, statt zu Tippen, ein handschriftliches Papier zu verfassen. Manche Handschrift ist exzellente Kryptographie. So sicher verschlüsselt, dass Entziffern generationenlang nicht gelingen wird.)


    Ganz anders sieht die Sache bei TLS, SSL und SSH aus.
    Dort wird ein Strom von Information verschlüsselt.
    Es wird eine Verbindung zwischen zwei Teilnehmern aufgebaut, und alles, was über diese Verbindung fliesst, wird verschlüsselt.
    Damit werden an die Algorithmen völlig andere Anforderungen gestellt. Die Ver- und Entschlüsselung muss hochperformant erfolgen.
    Weshalb man sogenannte Stromchiffren verwendet.
    Ganz andere Baustelle.


    Bleiben sie dran!
    Der nächste Teil im nächsten Post folgt postwendend!

  • Teil2


    Es werden also weder Public- noch Private- Key zur Verschlüsselung verwendet.
    Die dienen wirklich nur dazu, festzustellen, ob Server und Client ein gemeinsames Key- Paar finden können.
    Wer das nutzt, und wie verschlüsselt wird, ist hier nicht relevant.


    Tatsächlich sind in SSH noch viel mehr Dinge implementiert.
    Wenn ein verschlüsselter Datenstrom über ein Netzwerk geschickt wird, so kann das Netz mal spinnen, und dadurch ein Paket nicht ankommen. Oder es wird völlig außerhalb der Reihe geliefert. Es gibt noch mehr so Dinge, die bei der Übertagung Ärger machen können.
    All das muss berücksichtigt sein, damit eine solche Verbindung tatsächlich leisten kann, was sie soll.


    Es werden z.B. für alle Blöcke Prüfsummen mit eingebaut, oder sogenannte MessageAuthentication- Codes (MAC wird nicht nur die eindeutige Ethernetadresse von Netzwerkkarten genannt, sondern auch solche Prüfverfahren), mit denen man solche Probleme umschiffen will.
    Es kommen einige solcher Techniken zum Einsatz, um eine schlichte SSH- Verbindung aufbauen zu können.


    Grob lassen sich all diese Dinge in vier Kategorien einteilen:

    • Authentifizierung
      Genau das macht das ssh-keygen Paar. Und NUR das. Nicht einmal der User ist damit eindeutig. Egal, wer den Private-Key hat, der IST das.
    • Schlüsselaustausch
      Das wird heute bei Otto- Normal- Linuxern meist durch den Diffie-Helman Algorithmus erledigt, es gibt aber auch davon viele. (RSA z.B. kann ebenfalls Schlüssel tauschen). In dieser Phase werden lediglich die eigentlich für die Verschlüsselung verwendeten Schlüsselpaare erzeugt und ausgetauscht.
    • Hashen
      Das sind im Prinzip schlichte Prüfsummen. Sie machen hauptsächlich den Inhalt überprüfbar und sichern die Übertragung mit ab. SHA, der SecureHashAlgorithums wäre nur ein Beispiel von vielen.
    • Die eigentliche Verschlüsselung des Datenstromes
      Hier werden hauptsächlich CBC ChainBlockCiffer Methoden angewendet. Im Wesentlich meint das, das man die zu übertragendenen Daten in Blöcke einteilt, dann den ersten Block verschlüsselt sendet, gleicheitig eine Prüfsumme über dieses Chiffrat bildet, und diese Prüfsumme zur Verschlüsselung des zweiten Datenblocks mit verwendet wird. Die Verschlüsselung ändert sich also von Datenblock zu Datenblock.

    Diese vielen teilweise völlig verschiedenen Methoden sind standardisiert, denn ohne diese Standardisierung, wäre es nahezu unmöglich praktikabel zu verschlüsseln.
    Man beschreibt sie auch in einer standardisierten Form.
    Dieses seltsame Zeichenkettchen beschreibt ganz präzise, wie diese eine von unzähligen Möglichkeiten Verschlüsselung durchgeführt werden soll: ECDH-RSA-DES-CBC3-SHA. Das sagt im Klartext, dass wir mit einem EliptischenCurfen Algorithmus verschlüsseln wollen, der das Diffie-Hellman Keyexchangeverfahren verwenden soll, und so weiter, und so weiter. Hier wurden nur die ersten vier Buchstaben dieser Kette beschrieben. Alles ganz schön kompliziert.


    Bei einem SSH Verbindungsaufbau passieren im Wesentlichen die folgende Schritte:

    • Client und Server senden sich einen sogenannten Fingerprint.
      Kennt der Client ihn, wird fortgesetzt. Kennt ihn der Client nicht, ergibt das eine Warnung. Der Client speichert sich diese Daten in die Datei ~/.ssh/known-hosts. Der Server wirft ihn meist weg. All das ist auch per Konfiguration (oder beim ssh Aufruf ) abschaltbar.
      Diese Warnung erscheint beim ersten Verbindungsversuch. Ist der Eintrag in der known_hosts vorhanden, geht es weiter. Man kann diese ~/.ssh/known_hosts bedenkenlos löschen, sie wird jedesmal neu erstellt. Sie ist nicht relevant und hat auch nichts mit der Verschlüsselung zu tun.
    • Jetzt kommt die eigentliche Anmeldung
      Per Default sind Spasswortanmeldung und Anmeldung via Schlüssel erlaubt. Jetzt braucht man einen Usernamen samt Spasswort ODER einen Usernamen samt Schlüsselpaar.
      Es sind auch völlig andere Methoden möglich. Via PAM, via LDAP oder GSSAPI und noch mehr. Je nach Konfig. Man muss auch nicht unbedingt einen Usernamen bei der Anmeldung vorzeigen, wenn Root den SSH-Server so konfiguriert hat. Man kann z.B. einen SSH Schlüssel erzeugen, den der Server einem Backupjob zuordnet. Egal, welche Maschine sich mit diesem Schlüssel einloggt: Es wird ein Backupjob mit den dafür definierten User ausgeführt.
      Das ist aber fortgeschrittene Nutzung von SSH. (Ich schrieb schon, dass man damit sehr viel machen kann, wenn man kann).
      Bei der "normalen" Linuxuserschlüsselanmeldung guckt der Server, wenn der Client die Schlüsselauthentifizerung verlangt hat, im Home des mit angegebenen Users nach, ob in ~/.ssh/authorized_keys ein entsprechender Eintrag für diesen Schlüssel exisiert. Dort werden die öffentlichen Schlüssel, samt ein paar Verwaltungsangaben dazu gespeichert. Pro Schlüssel eine Zeile, egal, wie lang die sein mag.
      Wird diese Datei gelöscht, kann man sich nicht mehr als dieser User mit Schlüssel anmelden. Das Programm ssh-copy-id dient dazu den öffentlichen Schlüssel eines Users in diese Datei einzutragen. Da diese Datei -wie fast immer unter *nices üblich- eine reine Textdatei ist, kann man das aber auch händisch oder mit jedem Texteditor machen.
      Der Server sendet nun eine "Challenge"- Nachricht, die der Client mit seinem privaten Key verschlüsselt und das Chiffrat davon an den Server zurücksendet. Kann der Server dieses Paket nun mit dem öffentlichen Schlüssel dieses Users wieder entschlüsseln, seine vorher gesendete Challengenachricht wieder im Original lesen, so ist der User authentifiziert. Die Schlüssel haben für das nun folgende keine Bedeutung mehr. Wir kommen in die Phase des KeyExchanges.
    • Der Server bietet dem Client alle bei ihm vorkonfigurierten Varianten der Verschlüsselung an, und der Client darf sich eine davon aussuchen. Das sind jetzt diese komischen Zeichenketten, wovon wir weiter oben zumindest die ersten vier Buchstaben besprochen haben. Haben sie sich irgendwann auf ein Verfahren geeignet, so wird die tatsächlich verschlüsselte Verbindung tatsächlich aufgebaut.
      Der SSH- Serverprozess hatte beim allerersten Clientkontakt einen Kindprozess gestartet, der sich um diese ersten drei Schritte kümmert. Jetzt wird dieser Kindprozess durch einen neuen Prozess ersetzt, der nun mit den jeweiligen Userrechten läuft und die Verbindung tatsächlich verschlüsselt.
    • Während nun der User sich austoben kann, kommen die anderen Methoden zur Anwendung. Irgendeine CBC- Methode mit allen möglichen Prüfsummen.


    Ich hoffe damit alle Unklarheiten professionell vergrößert zu haben,
    und versichere, dass das wirklich nur der Anfang ist.

  • Das hab ich doch auch gesagt, nur eben in Kurzform..........

    Für den Inhalt des Beitrages 111703 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Das war mehr als ein Denkanstoß. Das war ein .... :)
    Wow. Wie kann ich denn bei so tollen Antworten meinen Dank zum Ausdruck bringen? Hat das Forum eine Funktion die ich noch nicht sehe?



    icmp

    ---
    freundliche Grüße, icmp

    Für den Inhalt des Beitrages 111735 haftet ausdrücklich der jeweilige Autor: icmp

  • Das steht unter der Kalle Lizenz.
    Die liest sich so:

    Das ist wesentlich sinnvoller, als ein paar Dukaten irgendwohin zu werfen.
    Mach es.
    Mehr braucht die Welt nicht.


    Und nicht zu vergessen: Sauerland ist eine arme S**
    Der betreibt mit mir einen Root- Server (wo du auch Schulung in der Konsole kostenlos kriegst in einer gemeinsam gesharten Screen - Session mit Mumble- Unterstützung (Mumble ist das open source Teamspeak, frei, bessere Soundqualität bei geringerem Ressourcenverbrauch); Nirgendwo lernst du schneller.)
    Und dafür hat er dann sogar einen Dukatensauger bei PayPal.