Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- linux:ssh:tofu_und_cert [21.12.2023 08:26. ] – [Fazit und Ausblick] django
+++ linux:ssh:tofu_und_cert [04.05.2024 11:35. ] (aktuell) – [Ausgangssituation] typofixing django
@@ Zeile 1: / Zeile 1: @@
+{{htmlmetatags>metatag-robots=()
+metatag-keywords=(TOFU,SSH,Zertifikate,ED25519,SHA256,Arch Linux, sicherer IT Betrieb,authorized_keys)
+metatag-description=(TOFU - Trust On First Use - SSH Zertifikate)
+}}
 ====== TOFU - Trust On First Use - SSH Zertifikate ======
 ===== Ausgangssituation =====
-O.K.,worum geht es hier eigentlich?
+O.K., worum geht es hier eigentlich?
-Verbinden wir uns das erste mal mit einem neuen System, sehen wir in aller Regel erst einmal sowas in der Art:
+Verbinden wir uns das erste mal mit einem neuen System, sehen wir in aller Regel erst einmal so was in der Art:
    $ ssh -Y vml172042
 <code>The authenticity of host 'vml172042 (172.17.2.42)' can't be established.
@@ Zeile 10: / Zeile 14: @@
 Are you sure you want to continue connecting (yes/no/[fingerprint])?</code>
-So und nun mal Hand aufs Herz was machen wir hier? Klar wir nun jeder sagen, bzw. was bekommen wir als Antworten wenn wir da mal etwas genauer nachfragen? Mögliche Antworten können nun sein:
+So und nun mal Hand aufs Herz was machen wir hier? Klar wird nun jeder sagen, bzw. was bekommen wir als Antworten wenn wir da mal etwas genauer nachfragen? Mögliche Antworten können nun sein:
 <WRAP center round important 80%>
   - Woot? Mir egal, ich antworte hier mit **''yes''** weil mit **''no''** komme ich nicht weiter und so habe ich Ruhe, die Meldung kommt nicht wieder! Und ganz ehrlich ich weiß nicht was das soll.\\ \\
@@ Zeile 35: / Zeile 39: @@
 Beim ersten Verbindungsaufbau werden wir also nun in unserem Beispiel hier eben darauf hingewiesen, dass wir dem System noch nicht vertrauen und wir das Vertrauen entweder bestätigen oder vielleicht auch auf andere Weise anderweitig herstellen wollen. Doch hierzu später mehr im Abschnitt **[[#loesung_smoeglichkeit|Lösung(smöglichkeit)]]**.
-Bestätigen wir nun das Vertrauen bei der ersten Verbindungsaufbau/-verwendung (**TOFU**((**T**rust**O**f**F**irst**U**se))) beim Initialen Verbindungsaufbau wir uns in unserer **''~/.ssh/authorized_keys''** ein entsprechender Eintrag hinzugefügt, welcher später dann als Anker dient und wir ohne TOFU-Meldung uns sofort mit den Zielsystem verbinden. Das bedeutet natürlich dass bei entsprechend vielen Zielsystemen entsprechend viele Zeilen dort sich ansammeln und sind dann auch noch wechselnde IP-Adressen im Spiel,das Ganze noch schneller anschwillt.
+Bestätigen wir nun das Vertrauen bei der ersten Verbindungsaufbau/-verwendung (**[[https://en.wikipedia.org/wiki/Trust_on_first_use|TOFU]]**((**T**rust**O**f**F**irst**U**se))) beim Initialen Verbindungsaufbau wir uns in unserer **''~/.ssh/authorized_keys''** ein entsprechender Eintrag hinzugefügt, welcher später dann als Anker dient und wir ohne TOFU-Meldung uns sofort mit den Zielsystem verbinden. Das bedeutet natürlich dass bei entsprechend vielen Zielsystemen entsprechend viele Zeilen dort sich ansammeln und sind dann auch noch wechselnde IP-Adressen im Spiel,das Ganze noch schneller anschwillt.
 Ändern sich dann auch noch **''ssh_host_ed25519_key''** von Zielsystemen, da z.B. bei Virtualisierungsumgebungen Virtuelle Maschinen getauscht oder erneuert werden, sind wir wiederum sehr schnell bei TOFU-Meldungen. Nach dem Hinzufügen von Verbindungen sind diese dauerhaft aktiv und die Daten in der **''~/.ssh/authorized_keys''** gepflegt werden.
@@ Zeile 83: / Zeile 87: @@
 SHA256:syMNF0jPr8b7hgqoCLgUZpSZhMulGeoGKFU/FWm3UKY vml172042 (ED25519)</code>
-O.K., wir haben zwar den Fingerprint des Server-Keys, aber wir haben diesen mit Hilfe des Programms **''ssh-keysan''** ermittelt der ja on-the-fly eine Verbindung zum Zielhost aufbaut und dessen präsentierten Schlüssel auswertet. Wenn das aber nun das kompromittierte MITM-System wäre, würden wir uns ja dessen Fingerprint für später merken.
+O.K., wir haben zwar den Fingerprint des Server-Keys, aber wir haben diesen mit Hilfe des Programms **''ssh-keyscan''** ermittelt der ja on-the-fly eine Verbindung zum Zielhost aufbaut und dessen präsentierten Schlüssel auswertet. Wenn das aber nun das kompromittierte MITM-System wäre, würden wir uns ja dessen Fingerprint für später merken.
 <WRAP center round important 80%>
@@ Zeile 2083: / Zeile 2087: @@
 Möchte man das Thema **TOFU** sauber lösen, ist die Verwendung von Host Zertifikaten sicherlich ein sehr guter Weg, den man beim **sicheren IT Betrieb** aufgreifen sollte. Denn theoretische Sicherheit ist toll, aber was helfen alle theoretischen Vorüberlegungen, wenn der Admin bei der initialen Kontaktaufnahme sich überrumpeln oder ablenken lässt. Der Zugewinn an Sicherheit ist hier definitiv ein Punkt der für die Verwendung von Host-Zertifikaten spricht!
-Ob man sich auch auf das Thema User-Zertifikate einlassen möchte, ist da schon mehr einer genauen Aufwands-Nutzenabwägung zu unterziehen. Wie werden z.B. die User-Zertifikate sicher verwahrt und abgesichert. Das Thema KRL ist dann sicher noch ein ganz besonderes Thema das Betrachtet werden muss. Diese beiden Themen manuell durch einen oder gar mehrere handelnde Personen erledigen zu lassen, wird aller Voraussicht nach lediglich die Administrationsaufwände signifikant erhöhen. Im schlimmsten Fall schafft man bei der manuellen Verwendung mehr Probleme und Risiken.
+Ob man sich auch auf das Thema User-Zertifikate einlassen möchte, ist da schon mehr einer genauen Aufwands-Nutzenabwägung zu unterziehen. Wie werden z.B. die User-Zertifikate sicher verwahrt und abgesichert. Das Thema KRL ist dann sicher noch ein ganz besonderes Thema das Betrachtet werden muss. Diese beiden Themen __manuell__ durch einen oder gar mehrere handelnde Personen erledigen zu lassen, wird aller Voraussicht nach lediglich die Administrationsaufwände signifikant erhöhen. Im schlimmsten Fall schafft man bei der manuellen Verwendung mehr Probleme und Risiken.
 Lösungen für diese Herausforderungen können zum einen eine Versionierung mit Hilfe von Git und Orchestrierung der Aufgaben mit einem State-of-th-Art- Werkzeug wie **Ansible** sein. Alternativ könnte auch die eingehende Betrachtung und Überlegung in Richtung **[[https://keyper.dbsentry.com/|KEYPER]]** gehen, sofern man sich auf Container einlassen kann|will. Keyper ist ein Open Source SSH-Schlüssel- und zertifikatsbasierter Authentifizierungsmanager, der auch als SSH-Zertifizierungsstelle (CA) fungiert.