SSH von der Pike auf Geschichte und was wirklich passiert. (Teil 2a)

Hinweis: In dem Thema SSH von der Pike auf Geschichte und was wirklich passiert. (Teil 2a) gibt es 6 Antworten. Der letzte Beitrag () befindet sich ganz unten auf dieser Seite.
  • Die Geschichte

    SSH (SecureSHell) wurde schon 1995 von Tatu Ylönen an der Universität Helsinki entwickelt. Es war als Ersatz für das altehrwürdige rsh gedacht. Angeblich hatte er die ständigen Angriffe aus dem Netz satt und war sogar selbst wohl einmal Opfer eines solchen Angriffs. (Was erklären könnte, warum SSH so gut ist. 8) ) Da es schnell populär wurde, und bald die ersten Flaws entdeckt wurden, kam bereits 1996 die Version2 heraus. Das openSSH Projekt, das heute alle freien Distris einsetzen, spaltete sich von der Mutter 1999 ab. Es ist heute Standard, und die Protokollversion SSH1, der Urvater, ist heute längst deaktiviert und findet keine Verwendung mehr. Wir setzen ausschließlich die Protokollversion SSH2 ein.


    Dabei handelt es sich nicht nur um ein Programm, mit dem man sich via Internet auf einem Remotehost einloggt, und dort eine Shell für den User dann bereitsteht. Tatsächlich ist das mittlerweile ein ganz eigenes Universum an Tools. Wir nennen das die openSSH Suite.

    Eine Paketsuche dürfte - je nach Distri - gut 100 Tools listen.

    Möglich wird das, weil man in SSH sogar eigene Subsysteme definieren kann. Heute liegen schon fünf solcher Subsysteme als RFC vor. (RequestForComment heißen traditionell die "Vorschläge", wie ein interoperables Protokoll, oder Gerät arbeiten muss, damit Maschinen über das Netzwerk zusammenarbeiten können. Quasi die Internetgesetze der technischen Umsetzung für die Netzkommunikation ). Für uns das einzig relevante ist das sftp Submodul (SecureFileTransferProtokol).

    Es sollte heute auf KEINEM Rechner mehr irgendein FTP Server laufen! Das ist ein vorsätzliches Sicherheitsloch -egal, was deren Fans zetern.

    Später mag noch das ssh-auth Subsystem in den Focus kommen - falls ich dazu später noch Lust habe.


    Heute ist die SSH- Suite Standard. Sie ist das Rückgrat in allen Rechenzentren. Eine Unzahl von Tools beruht darauf. So gibt es viele Tools, die gleichzeitig auf zig Hosts Kommandos ausführen mit jeweils komplett verschlüsselten Verbindungen zur Verfügung stellen. Man kann auch z.B. mit einem kurzen SSH- Befehl auf einem Remotehost z.B. Firefox ausführen lassen, dessen Fenster dann auf dem lokalen Desktop dargestellt wird, wobei Keyboard und Mouse dann ebenfalls über die SSH- Verbindung getunnelt werden.

    Eben ein Universaltool für jedweden Zweck, das sichere Kommunikationsstrecken sauber verschlüsselt dargestellt wird.


    SSH Basics und was da wirklich passiert

    Beim Anlegen eines neuen Useraccounts werden von /etc/skel alle Dateien und Verzeichnisse in dieses neue Home kopiert.

    Das kann dann so aussehen:


    Hier ist noch weit und breit nichts von SSH zu sehen. (Blaue Einträge sind Verzeichnisse.). Man beachte das -ls zur Anzeige aller Dateien, auch der "Dotfiles".

    Sobald jedoch zu diesem Account eine SSH- Verbindung hergestellt wurde, oder eine Verbindung versucht wurde, ändert sich das. Bei einem ablehnten Versuche sieht das dann so aus:

    Der rote Kasten im oberen grünen Kasten zeigt, dass dieser Verbindungsversuch ein Unterverzeichnis namens .ssh angelegt hat. Darin befindet sich, wie der zweite grüne Kasten zeigt, eine einzige Datei namens known_hosts.

    Und das cat .ssh/known_hosts im dritten grünen Kasten zeigt letzlich den Inhalt dieser known_hosts.

    Diese Datei wird also automatisch angelegt, ebenso, wie das Verzeichnis. Das Format war früher®™ noch halbwegs lesbar - heute ist es nicht einmal mehr leicht dechiffrierbar. Das brauchen wir auch nicht. Für uns ist nur wichtig, dass wir wissen, dass es automatisch erzeugt wird.

    Das Format der .ssh/known_hosts ist einigermaßen kompliziert. Die roten Kästen sollen zeigen, dass die Felder dieser Datei hauptsächlich durch Leerzeichen getrennt sind. Die einzelnen Felder sind aber noch weiter unterteilt - und sind je nach der verwendeten Verschlüsselung anders unterteilt. Wie die blauen Pfeile andeuten gehören dazu +-Zeichen, Slashes und Pipe- Zeichen, wie sie am Zeilenanfang zu sehen sind. Im Prinzip sind das alles Prüfsummen und verschlüsselte Angaben zum verwendeten Verschlüsselungsmechanismus und zum verbindenden Host. Findet sich am Ende eines Feldes ein =-Zeichen, so ist das Teil einer verschlüsselten Sequenz. Da in der modernen, asymmetrischen Verschlüsselung aus Performancegründen hauptsächlich Blockchiffren verwendet werden, kommt es häufig vor, dass der letzte Block des Chiffrats kürzer ist, als die jeweilige Blocklänge vorschreibt. Dadurch weiß der Entschlüsselungsalgorithmus, dass er zuerst am Ende so viele "Endezeichen" einfügen muss, bis der Block "vollständig" ist. Erst danach kann der letzte Block des Chiffrats tatsächlich entschlüsselt werden. Der ganze Kladaradatsch ist übrigens Base64 codiert.

    Muss man aber alles nicht wissen. Ich höre förmlich das Gott-sei-Dank-Soifffzen


    Es reicht für uns völlig aus, wenn wir uns das folgende merken:

    Merke:

    1. Die known_hosts wird automatisch angelegt.
      Man kann sie bedenkenlos löschen.
    2. Sie enthält verschlüsselt den Hostnamen (oder die IP- Adresse), Angaben zur tatsächlich verwendeten Verschlüsselung und andere Kleinigkeiten.

    Also fast. Wir werden später noch einmal auf diese Datei zurückkommen.


    Wenn einmal irgendetwas nicht so klappt, ist das -verbose Flag von Vorteil. Es taucht im nexten (hübsche Schlechtschreibung) Bild dann als debug1: auf Man kann bis zu drei -vvv schreiben, was dann eben als debug2: oder debug3: erscheint. Viel zu Lesen für kalte Winterabende, wenn der Hacker ohne Netz am Rechner einsam darbt.

    Schon im Debuglevel 1 tauchen viele Zeilen auf - bei Debuglevel 3 wird es ein kompletter Ulysses.

    Auch hier sind wir bescheiden und beschränken uns auf Debuglevel 1. Dieses Level zeigt uns aber schön, welche Phasen eine solche SSH- Verbindung durchläuft. Noch BEVOR überhaupt eine User Passwortabfrage, oder die "persönlichen Schlüssel" zum Einsatz kommen.

    Die ganze Sequenz dient nur der Verschlüsselung zwischen den beiden Rechnern. Die Authentifizierung und das Bereitstellen eines Terminals mit einer Shell erfolgt komplett verschlüsselt. Und hier endlich das Debug Dingens:

    2 Mal editiert, zuletzt von Sauerland ()

    Für den Inhalt des Beitrages 286473 haftet ausdrücklich der jeweilige Autor: Berichtigung

  • Im grünen Kasten #1 ist nur interessant, dass die Konfiguration, die der Root vorgegeben hat, von /etc/ssh/ssh_config eingelesen wird. Eine User Konfig im Home haben wir noch nicht erstellt.

    Im Kasten #2 versucht SSH einfach alle Standardschlüssel zu finden. Die beginnen immer mit id, was für IDentität steht. Durch einen Unterstrich getrennt folgt dann der "Verschlüsselungsbezeichner". rsa ein Akronym seiner Erfindern Rivest, Shamir und Adleman. Die nächste Kryptosuite ist die dsa (DigitalSignatureAlgorithm) Suite. Es gibt noch zwei weitere in dem Bild und in der Realität noch viel, viel mehr. Wobei bei SSH nicht ganz soviele Verwendung finden. Wir werden später noch einmal darauf eingehen.

    Bei unserem Beispiel hat SSH überhaupt keinen Schlüssel gefunden. Also der Verbindungsversuch eines Standardlosers ohne Sicherheitsbewußtsein und ohne Kenntnis dieses Tutorials.

    SSH fährt also fort und stellt im grünen Kasten #3 fest, dass beide Maschinen das openSSH Paket von Debian verwenden.

    Im grünen Kasten #4 beginnt nun die Verhandlung der beiden Rechner auf ein einheitliches Verfahren.

    Wir senden ein SHF2_MSG_KEXINIT (== SSH2_MeSsaGe_KexEXchangeINIT ) an den anderen Rechner, der darauf antwortet.

    Und somit befinden wir uns in der kex - Phase ( KeyEXchange )


    Den gucken wir uns im Rest dieses -verbosen Verbindungsaufbau an:


    Im grünen Kasten #1 wird noch die KeyExchangePfase beendet. Der SSH- Server auf der entfernten Maschine wird sich künftig mit dem

    Server host key: ecdsa-sha2-nistp256 SHA256:IMS3XmmgiGgdrQrsr40Shqe6znXjcRdTVYFF0wPl+i8

    identifizieren wird.

    Im grünen Kasten #2 stellt unsere Kiste aber fest:

    The authenticity of host '[localhost]:22022 ([127.0.0.1]:22022)' can't be established.

    Auf deutsch: Den kenn' i ned.


    Und der Fingerprint des begnerischen Servers lautet: ECDSA key fingerprint is SHA256:IMS3XmmgiGgdrQrsr40Shqe6znXjcRdTVYFF0wPl+i8.

    Das ist der SecureHashAlgorithm256 . den wir sehr häufig verwenden.


    Wir werden noch gefragt, ob wir das wirklich wollen.

    Are you sure you want to continue connecting (yes/no)? yes

    Und wenn wir yes antworten, wird die Zeile für diesen Rechner der known_host hinzugefügt.

    Geht natürlich bei der sehr sicherheitsbewußten SSH- Suite nicht ohne

    Warning: Permanently added '[localhost]:22022' (ECDSA) to the list of known hosts.


    Und damit sind wir im grünen Kasten #3

    Dort wird noch schnell das "Rekeying" vereinbart.

    Im oberen roten Kasten fragt unser Client, ob der Server ein Rekeying parat hält, was der gegnerische SSH- Server klar bejaht.

    Und wenn über diese Verbindung

    debug1: rekey after 134217728 blocks

    (mittlerer roter Kasten) so und so viele Blöcke ausgetauscht wurden, beginnt ein erneutes Verhandeln Parameter. Die Verschlüsselung wird also nach dieser Anzahl von Blöcken komplett erneut ausgehandelt und geändert. Sehr, sehr sicher.

    Dann bietet der gegnerische SSH- Server noch eine Liste seiner bevorzugten Verschlüsselungsmethoden an.

    Und letztendlich sagt er uns noch, dass

    SSH2_MSG_SERVICE_ACCEPT received

    der Service für uns von ihm geleistet wird. Mach'n mir.


    Jetzt sind wir im grünen Kasten #4

    Der Server teilt uns dort als erstes mit, welche Methoden er akzeptiert, damit wir uns bei ihm einloggen können.

    Das sagt er mit

    Authentications that can continue: publickey,keyboard-interactive

    Eine kleine Schlamperei von mir. Das keyboard-interactive - also das Abfragen vom Spasswort sollte gar nicht erlaubt sein.

    (Is abba egal, da kommen noch andere Mechanismen, die das unterbinden- ich gelobe Besserung)

    Und weil eben nur publickey akzeptiert wird, sucht unser Client jetzt die Schlüssel von denen in den zahllosen Hinz&Kunz Tutorials immer die Rede ist.

    Haben wir aber nicht. Wir haben nicht einmal einen erzeugt. Das machen wir in Teil 3.

    Und dass nun Ende Gelände ist, sagt er uns auch mit

    debug1: No more authentication methods to try.

    Permission denied (publickey,keyboard-interactive)


    Wir haben es nicht einmal geschafft, wirklich eine Verbindung herzustellen, weil der Server partout auf einen Key besteht, der wir noch nicht haben. Aber wir haben jetzt einen Eintrag in der known_hosts.


    Im nächsten Teil werden wir uns aber echt solche Schlüssel basteln und ab da schon Semihalbprofessionell rumsshen.

    Gerne können noch mehr Leute mitmachen.

    Aber antwortet bitte in irgendeinem der Teil und teilt mir mit, welchen Accountnamen ihr in unserem Container Server haben möchtet.

    Und wenn ihr richtig gute Unterstützung wollt, so kommt auf unseren Mumble-Server.

    Nach einem zypper in mumble könnte ihr euch mit www. interhacktive. de (ohne Leerzeichen) verbinden.

    Nick ist dort frei wählbar, der Rest bleibt auf Standard (und ein Tutorial dazu gibt es hier auch- einfach nach mumble suchen hier im Forum).

    2 Mal editiert, zuletzt von Sauerland ()

    Für den Inhalt des Beitrages 286474 haftet ausdrücklich der jeweilige Autor: Berichtigung

  • Jaaa, ich wiederhole mich...

    Trotzdem, sehr interessant, informativ und ein krasser (guter) Schreibstil.

    Danke dir...

    Für den Inhalt des Beitrages 286477 haftet ausdrücklich der jeweilige Autor: sterun

  • Danke Berichtigung , durchgelesen habe ich, aber mit einmal durchlesen ist bei mir nicht getan. Habe also Lektüre für den Abend. :)

    Wir müssen lernen, entweder als Brüder miteinander zu leben oder als Narren unterzugehen.

    Zitat von Martin Luther King.

    Für den Inhalt des Beitrages 286480 haftet ausdrücklich der jeweilige Autor: Heinz-Peter

  • Danke Berichtigung , durchgelesen habe ich, aber mit einmal durchlesen ist bei mir nicht getan.

    Heinz-Peter, denkst Du bei mir ist das anders?


    Jetzt kann ich mir auch unter bekannte Hosts etwas vorstellen.

    Wenn ich per ssh auf einen Freifunk oder DD-WRT Router zugreifen wollte fragte mich das Ding

    ob ich das wirklich will.

    Dank der Erklärung meines K****k*******ns, weiß ich jetzt warum.

    Für den Inhalt des Beitrages 286500 haftet ausdrücklich der jeweilige Autor: Kanonentux