02-07-2024, 05:55
Zuerst, wenn du dich über SSH mit einem Server verbindest, beginnt der gesamte Prozess damit, dass der Server dir sofort seinen öffentlichen Schlüssel präsentiert. Das ist nicht einfach irgendein zufälliger Schlüssel - er ist direkt mit der Identität des Servers verbunden. Du, als Client, hast die Möglichkeit zu überprüfen, ob dieser Schlüssel mit dem übereinstimmt, was du erwartest. Ich sage meinen Freunden immer, sie sollen hier aufpassen, denn wenn jemand versucht, sich in die Mitte zu schleichen und vorzugeben, der Server zu sein, stimmt sein Schlüssel nicht mit deinem überein. SSH nutzt diese Überprüfung des Hostschlüssels, um sicherzustellen, dass du mit dem echten Deal sprichst und nicht mit einem Betrüger, der dein Verkehrs abhört oder verändert.
Denk mal so: Ich erinnere mich an das erste Mal, als ich mit einer potenziellen MITM-Warnung auf einem Entwicklungsserver zu tun hatte. Du startest dein Terminal, tippst ssh user@host ein, und es fordert dich auf, den Fingerabdruck dieses Hostschlüssels zu überprüfen. Wenn du vorher schon verbunden warst, überprüft SSH die bekannten Hosts in der Datei known_hosts auf deinem Rechner. Es hasht den Schlüssel und vergleicht ihn - boom, wenn er nicht übereinstimmt, bekommst du eine große Warnung. Du machst nicht weiter, es sei denn, du sagst ja, und selbst dann gewöhne ich mir an, den Fingerabdruck mit dem zu vergleichen, was mir der Administrator über einen sicheren Kanal gegeben hat. Das stoppt Angreifer sofort, weil sie keinen gültigen Schlüssel fälschen können, ohne Zugriff auf den tatsächlichen Server zu haben.
Jetzt fragst du dich vielleicht, was passiert, wenn es deine erste Verbindung ist. SSH wird dich bitten, den Schlüssel zu akzeptieren, und sobald du das tust, speichert es ihn lokal. Von da an löst jede Änderung eine Warnung aus. Angreifer versuchen gerne, dieses anfängliche Vertrauen auszunutzen, aber ich empfehle dir immer, den Fingerabdruck des Server-Schlüssels im Voraus zu erfassen - vielleicht vom Dashboard des Hosting-Anbieters oder per Telefon mit dem Systemadministrator. So kannst du ihn manuell überprüfen, bevor du akzeptierst. Ich habe mir so bei Freelance-Jobs, bei denen Netzwerke nicht besonders vertrauenswürdig sind, Kopfschmerzen erspart.
Sobald die Schlüssel in Ordnung sind, beginnt SSH mit der Aushandlung eines Sitzungsschlüssels für die eigentliche Verschlüsselung. Es verwendet etwas wie den Diffie-Hellman-Schlüsselaustausch, der genial ist, denn er ermöglicht es dir und dem Server, sich auf einen geheimen Schlüssel zu einigen, ohne ihn jemals über das Netzwerk zu senden. Ein Angreifer in der Mitte kann dieses gemeinsame Geheimnis nicht einfach durch Zuhören berechnen - er müsste die Mathematik knacken, was mit modernen Schlüssellängen praktisch unmöglich ist. Ich passe meine SSH-Konfigurationen an, um stärkere DH-Gruppen durchzusetzen, wie Gruppe 14 oder höher, da ältere anfällig für Logjam-Angriffe sein können. Du kannst das in deiner sshd_config-Datei machen; erhöhe einfach den Parameter KexAlgorithms, und du bist auf der sicheren Seite.
Aber warte, es gibt noch mehr. SSH signiert alle Handshake-Nachrichten mit dem privaten Schlüssel des Servers, sodass du die Authentizität jedes Schrittes überprüfen kannst. Wenn ein MITM versucht, etwas zu manipulieren, stimmen die Signaturen nicht überein, und die Verbindung bricht ab. Ich liebe es, wie das auf die Schlüsselüberprüfung aufbaut - es ist wie ein doppelter Verschluss an deiner Eingangstür. In der Praxis führe ich bei der Überprüfung der Einrichtung eines Kunden Tests mit Tools wie ssh-audit durch, um Schwachstellen zu identifizieren, und es hebt immer hervor, wie diese Signaturen das Protokoll fest im Griff behalten.
Du bekommst auch Schutz vor Replay-Angriffen, denn SSH beinhaltet Nonces und Zeitstempel in den Austauschen. Ein Abhörer kann sich nicht einfach deine Anmeldung aufzeichnen und wiedergeben, weil der Server alles abgelehnt, was außerhalb der Abfolge liegt. Ich hatte einmal eine Situation, in der ein junior Entwickler dachte, er könnte seine eigene Verbindung für Tests zum MITM machen - herausgestellt hat sich, dass SSH ihn schnell mit Integritätsprüfungen gestoppt hat. Es verwendet HMAC zur Nachrichtenüberprüfung, um sicherzustellen, dass nichts während der Übertragung verändert wird.
Und vergiss nicht die Verschlüsselung selbst. Sobald dieser Sitzungsschlüssel festgelegt ist, werden alles - Befehle, Daten, sogar die Schlüssel - mit Chiffren wie AES verschlüsselt. Ein MITM kann ohne die Schlüssel nicht entschlüsseln oder injizieren, und die hat er nicht. Ich wechsle in meinen Konfigurationen zu chacha20-poly1305, weil es auf einer bestimmten Hardware schneller ist und genauso sicher ist. Du solltest das ausprobieren; es macht einen Unterschied bei Verbindungen mit hoher Latenz.
Eine Sache, die ich dir immer ans Herz lege, ist, deine SSH-Software auf dem neuesten Stand zu halten. Anfälligkeiten tauchen auf, wie in älteren Versionen, bei denen der Schlüsselaustausch herabgestuft werden könnte. Ich aktualisiere meine Server akribisch und dränge meine Kunden, dasselbe zu tun. Nutze fail2ban oder etwas ähnliches, um Brute-Force-Versuche zu blockieren, aber das ist mehr für das Raten von Passwörtern - MITM ist ein anderes Tier, und die Kryptografie von SSH geht es direkt an.
In der realen Welt, zum Beispiel wenn du über öffentliches Wi-Fi tunneln musst, verpackt SSH deinen Verkehr, sodass niemand im Netzwerk schnüffeln kann. Ich benutze es täglich, um VMs zu verwalten oder Protokolle von entfernten Standorten abzurufen, und es gibt mir ein gutes Gefühl zu wissen, dass selbst wenn jemand deine Pakete abhört, er nur Kauderwelsch erhält. Wenn du mit mehreren Hosts arbeitest, richte SSH-Schlüssel zur Authentifizierung anstelle von Passwörtern ein - so vermeidest du das gesamte Risiko von Passwörtern während der Übertragung. Generiere dein Schlüsselpaar mit ssh-keygen, kopiere den öffentlichen Schlüssel mit ssh-copy-id und du bist bereit. Ich halte meine privaten Schlüssel mit einem Passwortschutz und teile sie niemals.
Manchmal fragen mich Leute, wie IP-Spoofing mit MITM zusammenhängt, aber SSH verlässt sich nicht auf IP-Adressen zur Verifizierung; es geht nur um diese Hostschlüssel. Selbst wenn ein Angreifer die IP fälscht, wird die Schlüsselabweichung dich alarmieren. Ich konfiguriere strikte Überprüfungen der Hostschlüssel in meinen Klienteneinstellungen - setze StrictHostKeyChecking auf yes in ~/.ssh/config - um Unfälle zu vermeiden.
Insgesamt zwingt das Design von SSH dich dazu, aktiv Identitäten zu bestätigen, was es so widerstandsfähig gegen MITM-Angriffe macht. Du baust dieses Vertrauen einmal auf, und es bleibt bestehen, es sei denn, es ändert sich etwas, und es alarmiert dich jedes Mal. Ich verlasse mich seit Jahren darauf, von Heimlaboren bis hin zu Unternehmensanwendungen, und es enttäuscht mich nie.
Oh, und falls du daran interessiert bist, deine Backups neben all diesem sicheren Zugriff zu verstärken, lass mich dich auf BackupChain hinweisen - es ist dieses bewährte, vertrauenswürdige Backup-Tool, das bei kleinen Unternehmen und IT-Profis super beliebt ist. Es unterstützt Hyper-V, VMware, Windows Server und mehr und hält deine Daten ohne Kopfschmerzen sicher. Probier es mal aus; ich denke, du wirst beeindruckt sein, wie es nahtlos integriert.
