| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung |
| linux:ssh:tofu_und_cert [21.12.2023 08:21. ] – [Erzeugen des Hostkey-Zertifikates] django | linux:ssh:tofu_und_cert [04.05.2024 11:35. ] (aktuell) – [Ausgangssituation] typofixing django |
|---|
| | {{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 ====== | ====== TOFU - Trust On First Use - SSH Zertifikate ====== |
| ===== Ausgangssituation ===== | ===== 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 | $ ssh -Y vml172042 |
| <code>The authenticity of host 'vml172042 (172.17.2.42)' can't be established. | <code>The authenticity of host 'vml172042 (172.17.2.42)' can't be established. |
| Are you sure you want to continue connecting (yes/no/[fingerprint])?</code> | 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%> | <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.\\ \\ | - 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.\\ \\ |
| 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)]]**. | 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. | Ä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. |
| 256 SHA256:syMNF0jPr8b7hgqoCLgUZpSZhMulGeoGKFU/FWm3UKY vml172042 (ED25519)</code> | 256 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%> | <WRAP center round important 80%> |
| * **''-s /etc/ssh/ssh_ca/ssh_ca_user_key''** : Zertifizieren (signieren) eines öffentlichen User-Keys mit dem angegebenen CA-Schlüssel (private key). | * **''-s /etc/ssh/ssh_ca/ssh_ca_user_key''** : Zertifizieren (signieren) eines öffentlichen User-Keys mit dem angegebenen CA-Schlüssel (private key). |
| * **''-z 1''** : Gibt eine Seriennummer an, die in das Zertifikat eingebettet wird, um es von anderen Zertifikaten der derselben CA zu unterscheiden. Sofern wir der serial_number ein '+'-Zeichen voranstellen, wird die Seriennummer für jedes jedes in einer einzigen Befehlszeile signierte Zertifikat erhöht. Die Standard-Seriennummer ist hier Null "0". | * **''-z 1''** : Gibt eine Seriennummer an, die in das Zertifikat eingebettet wird, um es von anderen Zertifikaten der derselben CA zu unterscheiden. Sofern wir der serial_number ein '+'-Zeichen voranstellen, wird die Seriennummer für jedes jedes in einer einzigen Befehlszeile signierte Zertifikat erhöht. Die Standard-Seriennummer ist hier Null "0". |
| * **''-V +521d''** : Definiert die Zeit die das Zertifikat gültig sein soll, die also beim Signieren des Host-Schlüssels verwendet wird. Das Gültigkeitsintervall kann aus einem einzigen Zeitpunkt bestehen, der angibt, dass das Zertifikat ab jetzt gültig ist und zu diesem Zeitpunkt abläuft, oder es kann aus zwei Zeitpunkten bestehen, die durch einen Doppelpunkt durch einen Doppelpunkt getrennt sein, um ein explizites Zeitintervall anzugeben. In unserem Konfigurationsbeispiel also 52 Wochen und ein Tag zusätzlich → also in einem Jahr. | * **''-V +52w1d''** : Definiert die Zeit die das Zertifikat gültig sein soll, die also beim Signieren des Host-Schlüssels verwendet wird. Das Gültigkeitsintervall kann aus einem einzigen Zeitpunkt bestehen, der angibt, dass das Zertifikat ab jetzt gültig ist und zu diesem Zeitpunkt abläuft, oder es kann aus zwei Zeitpunkten bestehen, die durch einen Doppelpunkt durch einen Doppelpunkt getrennt sein, um ein explizites Zeitintervall anzugeben. In unserem Konfigurationsbeispiel also 52 Wochen und ein Tag zusätzlich → also in einem Jahr. |
| * **''-I django''** : Der Key-Identifier ein "Schlüsselbezeichner", der vom Server protokolliert wird, wird herangezogen sobald das Zertifikat zur Authentifizierung verwendet wird. Wir verwenden hier also den Namen unseres Admin-Users von dem wir den public-key erhalten hatten. | * **''-I django''** : Der Key-Identifier ein "Schlüsselbezeichner", der vom Server protokolliert wird, wird herangezogen sobald das Zertifikat zur Authentifizierung verwendet wird. Wir verwenden hier also den Namen unseres Admin-Users von dem wir den public-key erhalten hatten. |
| * Definiert den beim Signieren eines öffentlichen Server-Schlüssels die Schlüsselidentität der CA. | * Definiert den beim Signieren eines öffentlichen Server-Schlüssels die Schlüsselidentität der CA. |
| ===== Fazit und Ausblick ===== | ===== Fazit und Ausblick ===== |
| <WRAP center round tip 80%> | <WRAP center round tip 80%> |
| 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. | 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. | 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. |
django