10505791074
04.01.2024, aktualisiert am 10.01.2024
1559
9
0
TOFU - Trust On First Use bei der SSH
HI Zusammen,
rein aus Interesse gefragt, wie handhabt Ihr das eigentlich so mit TOFU im Bezug auf die SSH?
Mögliche Antworten könnten sein:
Selbstverständlich wird das ernst genommen!
Keine Ahnung von was Du da sprichst, ich esse TOFU nur!
Ist mir egal, ich sag' da einfach nur "yes" bis zum nächsten Wechseln von Schlüssel und Ruhe ist!
t.b.c.
...
Wie ist da Eu're Einschätzung?
ttyl
rein aus Interesse gefragt, wie handhabt Ihr das eigentlich so mit TOFU im Bezug auf die SSH?
Mögliche Antworten könnten sein:
Selbstverständlich wird das ernst genommen!
Keine Ahnung von was Du da sprichst, ich esse TOFU nur!
Ist mir egal, ich sag' da einfach nur "yes" bis zum nächsten Wechseln von Schlüssel und Ruhe ist!
t.b.c.
...
Wie ist da Eu're Einschätzung?
ttyl
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 22086095606
Url: https://administrator.de/forum/tofu-trust-on-first-use-bei-der-ssh-22086095606.html
Ausgedruckt am: 21.12.2024 um 13:12 Uhr
9 Kommentare
Neuester Kommentar
Du meinst die Serverzertifikate? Wo man als Client den Fingerprint bestätigen soll?
Naja, die Zertifikate kann man von (s)einer CA signieren und der dann im Client pauschal vertrauen.
Oder man macht das mit TLSA-Records (das ist aber zugegebenermaßen relativ nervig).
Ich versuche auf jeden Fall so wenig wie möglich diese Meldung zu bekommen.
Naja, die Zertifikate kann man von (s)einer CA signieren und der dann im Client pauschal vertrauen.
Oder man macht das mit TLSA-Records (das ist aber zugegebenermaßen relativ nervig).
Ich versuche auf jeden Fall so wenig wie möglich diese Meldung zu bekommen.
O.K. ich muss das vielleicht noch präzisieren. Beim initialen Aufbau einer Verbindung zu einem noch unbekannten Ziel bekommt man ja in der Regel so'was da in der Art präsentiert.
Wie geht Ihr|Du damit um? Sag bitte blos nicht: Ich ruf den SSH CLient immer mit den beiden Optionen -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no auf.
SSH-Server Zertifikate und ggf. SSH-Client-Zertifikate ist hier ein oft genanntes best practice. Pauschales Vertrauen? Na ja ich weiß ja nicht, aber das kommt bei obiger Frage einfach dem yes (Augen zu und durch) gleich. Wenn dann doch lieber das SSH Zertifikat der SSH CA am Client benutzen, wenn schon, denn schon.
O.K. das mit den TLSA-Records und den SSH Host keys musst Du mir mal erklären!
Bei uns bekommen wir hier keine TOFU Frage gestellt, das ist soweit geregelt. Nur hatten mich beim letzten Stammtisch ein paar ungläubige Augenpaare angekuckt, als ich TOFU erwähnte. Klaus' Kommentar war da aber der allerbeste: TOFU? Igitt sowas ess ich grundsätzlich nicht! ;)
The authenticity of host 'ubuntu2204 (10.20.30.40)' can't be established.
ED25519 key fingerprint is SHA256:kIe5Ki/ItvQq9Cpfw/qLReo184d455Fr0mh311P1nN3r8nO4.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])?Wie geht Ihr|Du damit um? Sag bitte blos nicht: Ich ruf den SSH CLient immer mit den beiden Optionen -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no auf.
SSH-Server Zertifikate und ggf. SSH-Client-Zertifikate ist hier ein oft genanntes best practice. Pauschales Vertrauen? Na ja ich weiß ja nicht, aber das kommt bei obiger Frage einfach dem yes (Augen zu und durch) gleich. Wenn dann doch lieber das SSH Zertifikat der SSH CA am Client benutzen, wenn schon, denn schon.
O.K. das mit den TLSA-Records und den SSH Host keys musst Du mir mal erklären!
Bei uns bekommen wir hier keine TOFU Frage gestellt, das ist soweit geregelt. Nur hatten mich beim letzten Stammtisch ein paar ungläubige Augenpaare angekuckt, als ich TOFU erwähnte. Klaus' Kommentar war da aber der allerbeste: TOFU? Igitt sowas ess ich grundsätzlich nicht! ;)
Moin,
Gruß,
Dani
Wie geht Ihr|Du damit um? Sag bitte blos nicht: Ich ruf den SSH CLient immer mit den beiden Optionen -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no auf.
wir veröffentlichen immer die Keys im DNS (SSHFP Resource Record) Das gilt für interne aber natürlich auch für externe Server. Es gibt leider auch Netzwerke bei uns, wo das nicht geht. Hier wird zusätzlich der Key im PAM hinterlegt.O.K. das mit den TLSA-Records und den SSH Host keys musst Du mir mal erklären!
Das Ganze macht natürlich nur Sinn, wenn die DNS-Zone mit DNSSEC geschützt wird. Anderenfalls könnten Manipulationen nicht auffallen.Gruß,
Dani
Also das mit den SSH Hostkeys und den TLSA-Records ist ja auf den ersten Blick eine durchaus erstrebenswerte G'schicht'. Was mich da nur etwas stutzig macht ist die DNS-Abhängigkeit. Was ist denn wenn DNS nicht verfügbar ist? Ist dann der Verbindungsaufbau zum Zielsystem mit Hilfe der SSH dann beeinträchtigt? Steht man dann vor einem initialen TOFU? Was ist mit dem Zugriff, rein auf Host-IPv4|6, bzw. mit Namen aus der ~/.ssh/config, für die es keine DNS-Auflösung gibt?
Fragen über Fragen ... mal sehen was ich da noch herausfinden werde.
Fragen über Fragen ... mal sehen was ich da noch herausfinden werde.
Moin,
naja, was passiert mit einem LDAP/AD, wenn der DNS nicht sauber/gar nicht funktioniert? Dann geht da auch nicht mehr viel. Von daher gibt es immer eine Abhängigkeit, die nicht zu lösen ist.
Gruß,
Dani
naja, was passiert mit einem LDAP/AD, wenn der DNS nicht sauber/gar nicht funktioniert? Dann geht da auch nicht mehr viel. Von daher gibt es immer eine Abhängigkeit, die nicht zu lösen ist.
Was ist mit dem Zugriff, rein auf Host-IPv4|6, bzw. mit Namen aus der ~/.ssh/config, für die es keine DNS-Auflösung gibt?
Kann ich dir nicht beantworten. Weil bei uns hat alles ein FQDN - ohne Ausnahme. Oder lernst du IPv6 Adressen auswendig?Gruß,
Dani
Griasde,
Schon klar, aber bei uns gibt es Basis-Services die müssen so gut wie immer funktionieren, auch wenn der zentrale LDAP-Server und|oder DNS nicht verfügbar sind und dazu gehört eben die SSH.
Abhängigkeiten sind per se - so die Definition bei uns - möglichst minimiert für Dienste die quasi immer zur Verfügung stehen müssen. Denn im Zweifelsfall ist dann schnell Schluss mit Lustig und es ist Administration by Turnschuh|Dienstwagen angesagt und dazu hat keiner im Zweifelsfall so recht Lust. Wie Du schon sagtest es gibt im Zweifelsfall immer Abhängigkeiten, die nicht zu lösen sind, also schaffen wir hier bei uns diese erst schon mal soweit es geht gar nicht!
Apropos Abhängigkeiten, erzähle ich mal kurz einen Schwank aus meiner "Jugend". CEO gab die Order aus: "Ab sofort werden Passwörter nur noch im zentralen unternehmensweiten Vault sicher abgelegt. So ist sichergestellt, dass nur die Zugriff auf User und Passwörter haben, die dazu berechtigt sind!" Alle riefen: "Hurra, endlich!" Na ja, es dauerte nicht lange bis zum Tag X als das zentrale Vault eben nicht verfügbar war. Da war das Wehklagen gross. :/ Was passierte anschliessend? Tja, die Leute speicherten die Passwörter wieder auf Post-it, Zettel, Dateien im Share etc. pp. und erzählten dem CEO dass alles so toll läuft.
Was hat man gewonnen? Nix, NULL, de narda! Aber wie gesagt anderes Thema und Schwank aus meiner "Jugend" ...
Daher immer mit bedacht überlegen, was auf der Haben- und was auf der Soll-Seite der Rechnung steht und ob man bestimmte Abhängigkeiten haben will. #jm2ct
Logisch kenne ich die wichtigsten IPv6-Adressen, meine ist z.,B. ::1 :P
Nein Spass bei Seite, wir haben für die wichtigsten Dienste den Interface-ID so gewählt, dass man leicht an der vorhandenen Adress-Struktur bestimmte Hosts ausfindig machen kann. Wenn z.B. die Interface-ID des zentralen SMTP-Relays in der IDMZ auf :25 endet,wie wird dann wohl der im Netzsegment beheimatete DNS enden? Na, klar die :53 oder der ladp-Server die :636.
Für mich denkfaulen BOfH wurde eh' alles in die ~/.ssh/config gepackt, somit brauche ich nur die Namen der dort hinterlegten Kunden-VMs, zentralen Service-Nodes, aktiven Netzwerkdevices, Aliase etc. pp. verwenden und ich erreiche alles, auch ohne DNS.
Egal ob ich nun:
ssh smtp
ssh smtp.zone.example.com
ssh vml192168000025
ssh relayhost
ssh bitch
ssh 192.168.0.25
ssh fe80::1921:68ff:fe00:25
ssh 2003:YYYY:XXXX:7600:1920:168:0:25
...
verwende.
Ich muss mir keine grossen Gedanken machen. Denn alle Definitionen der Hosts, egal, ob intern, extern oder über einen oder mehrere Jump-Host erreichbar, werden zentral gepflegt und via Ansible auf die Ansible-Controll-Nodes bzw. gesonderte Administrationsworkstations orchestriert und stehen somit in den besagten ~/.ssh/config Dateien.
Aber @Dani danke für Deine rege Diskussionsteilname und Denkanstösse in Richtung TLSA-Records!
Pfiade
Zitat von @Dani:
Moin,
naja, was passiert mit einem LDAP/AD, wenn der DNS nicht sauber/gar nicht funktioniert? Dann geht da auch nicht mehr viel. Von daher gibt es immer eine Abhängigkeit, die nicht zu lösen ist.
Moin,
naja, was passiert mit einem LDAP/AD, wenn der DNS nicht sauber/gar nicht funktioniert? Dann geht da auch nicht mehr viel. Von daher gibt es immer eine Abhängigkeit, die nicht zu lösen ist.
Schon klar, aber bei uns gibt es Basis-Services die müssen so gut wie immer funktionieren, auch wenn der zentrale LDAP-Server und|oder DNS nicht verfügbar sind und dazu gehört eben die SSH.
Abhängigkeiten sind per se - so die Definition bei uns - möglichst minimiert für Dienste die quasi immer zur Verfügung stehen müssen. Denn im Zweifelsfall ist dann schnell Schluss mit Lustig und es ist Administration by Turnschuh|Dienstwagen angesagt und dazu hat keiner im Zweifelsfall so recht Lust. Wie Du schon sagtest es gibt im Zweifelsfall immer Abhängigkeiten, die nicht zu lösen sind, also schaffen wir hier bei uns diese erst schon mal soweit es geht gar nicht!
Apropos Abhängigkeiten, erzähle ich mal kurz einen Schwank aus meiner "Jugend". CEO gab die Order aus: "Ab sofort werden Passwörter nur noch im zentralen unternehmensweiten Vault sicher abgelegt. So ist sichergestellt, dass nur die Zugriff auf User und Passwörter haben, die dazu berechtigt sind!" Alle riefen: "Hurra, endlich!" Na ja, es dauerte nicht lange bis zum Tag X als das zentrale Vault eben nicht verfügbar war. Da war das Wehklagen gross. :/ Was passierte anschliessend? Tja, die Leute speicherten die Passwörter wieder auf Post-it, Zettel, Dateien im Share etc. pp. und erzählten dem CEO dass alles so toll läuft.
Was hat man gewonnen? Nix, NULL, de narda! Aber wie gesagt anderes Thema und Schwank aus meiner "Jugend" ...Daher immer mit bedacht überlegen, was auf der Haben- und was auf der Soll-Seite der Rechnung steht und ob man bestimmte Abhängigkeiten haben will. #jm2ct
Was ist mit dem Zugriff, rein auf Host-IPv4|6, bzw. mit Namen aus der ~/.ssh/config, für die es keine DNS-Auflösung gibt?
Kann ich dir nicht beantworten. Weil bei uns hat alles ein FQDN - ohne Ausnahme. Oder lernst du IPv6 Adressen auswendig?Logisch kenne ich die wichtigsten IPv6-Adressen, meine ist z.,B. ::1 :P
Nein Spass bei Seite, wir haben für die wichtigsten Dienste den Interface-ID so gewählt, dass man leicht an der vorhandenen Adress-Struktur bestimmte Hosts ausfindig machen kann. Wenn z.B. die Interface-ID des zentralen SMTP-Relays in der IDMZ auf :25 endet,wie wird dann wohl der im Netzsegment beheimatete DNS enden? Na, klar die :53 oder der ladp-Server die :636.
Für mich denkfaulen BOfH wurde eh' alles in die ~/.ssh/config gepackt, somit brauche ich nur die Namen der dort hinterlegten Kunden-VMs, zentralen Service-Nodes, aktiven Netzwerkdevices, Aliase etc. pp. verwenden und ich erreiche alles, auch ohne DNS.
Egal ob ich nun:
ssh smtp
ssh smtp.zone.example.com
ssh vml192168000025
ssh relayhost
ssh bitch
ssh 192.168.0.25
ssh fe80::1921:68ff:fe00:25
ssh 2003:YYYY:XXXX:7600:1920:168:0:25
...
verwende.
Ich muss mir keine grossen Gedanken machen. Denn alle Definitionen der Hosts, egal, ob intern, extern oder über einen oder mehrere Jump-Host erreichbar, werden zentral gepflegt und via Ansible auf die Ansible-Controll-Nodes bzw. gesonderte Administrationsworkstations orchestriert und stehen somit in den besagten ~/.ssh/config Dateien.
Aber @Dani danke für Deine rege Diskussionsteilname und Denkanstösse in Richtung TLSA-Records!
Pfiade
Moin,
Gruß,
Dani
Schon klar, aber bei uns gibt es Basis-Services die müssen so gut wie immer funktionieren, auch wenn der zentrale LDAP-Server und|oder DNS nicht verfügbar sind und dazu gehört eben die SSH.
SSH ist kein Services sondern ein Protokoll. Abhängigkeiten sind per se - so die Definition bei uns - möglichst minimiert für Dienste die quasi immer zur Verfügung stehen müssen.
Da würde mich interessieren, welche Services das sind, die keine oder nur wenige Abhängigkeiten haben weil. Sobald Virtualisierung, Segmentierung, Firewall, Routing im Spiel ist, ist das eigentlich nicht mehr möglich. Da denke ich noch gar nicht an Layer 4 oder Layer 7 Services.Denn im Zweifelsfall ist dann schnell Schluss mit Lustig und es ist Administration by Turnschuh|Dienstwagen angesagt und dazu hat keiner im Zweifelsfall so recht Lust.
Wie immer hängt es vom Notfallplan ab. Wir hätten das Personal aber zu wenige Dienstwagen und Firmenflieger. Um entsprechende Personal an alle RZ Standorte zu schicken.Ab sofort werden Passwörter nur noch im zentralen unternehmensweiten Vault sicher abgelegt. So ist sichergestellt, dass nur die Zugriff auf User und Passwörter haben, die dazu berechtigt sind!" Alle riefen: "Hurra, endlich!" Na ja, es dauerte nicht lange bis zum Tag X als das zentrale Vault eben nicht verfügbar war.
Hört sich eher nach Planungsversagen, Designfehler oder unfähiges Personal an. Wir haben im Konzern eine solche Lösung im Einsatz. Da sind Millionen Passwörter in unterschiedlichen Tresoren drin. In den letzten 5 Jahren noch keine 1 Stunde Ausfall gehabt.Logisch kenne ich die wichtigsten IPv6-Adressen, meine ist z.,B. ::1 :P
Geht auch nur bei einem überschaubaren Anzahl von Subnetzen und Geräten.Ich muss mir keine grossen Gedanken machen. Denn alle Definitionen der Hosts, egal, ob intern, extern oder über einen oder mehrere Jump-Host erreichbar, werden zentral gepflegt und via Ansible auf die Ansible-Controll-Nodes bzw. gesonderte Administrationsworkstations orchestriert und stehen somit in den besagten ~/.ssh/config Dateien.
Ich habe das bei uns mal ausprobiert. Dauert bei uns recht lange bis die Datei erstellt und verteilt wurde. Erzeugt auf dem Netzwerk einen deutlichen Peak und ist auch bei Nutzung nicht performant. Wie viele Geräte hast du in der Datei stehen?Gruß,
Dani
Griasde
Da hast Du natürlich Recht, laut RFC ist die Secure Shell ein Protokoll - laut manpage von ssh ist es ein Client und frage ich den Paket-Maintainer, dann bekomme ich als Antwort:
secure shell client and server (metapackage)
This metapackage is a convenient way to install both the OpenSSH client
and the OpenSSH server.
und nu, wollen wir uns jetzt hierzu wirklich "streiten" - nicht wirklich, oder?
Bitte Layer 8 nicht vergessen!
Tja, Du hast es erfasst - war u.a. ein Grund neben dem putty-Gewürge und noch ein paar andere Themen, warum ich dort weg bin - katastrophaler Laden, der sich selbst auch noch als systemrelevant einstuft(e).
Echt? Wie viele Ansible-Controll-Nodes bzw. gesonderte Administrationsworkstation hast Du denn da?
Na ja, gucken wir doch mal...
Für den Komfort für uns ein akzeptables "Kosten/Nutze"-Verhältnis, zumal ja nicht alle 5 Minuten 42 neue (v)Hosts hinzukommen.
Pfiade
Zitat von @Dani:
Schon klar, aber bei uns gibt es Basis-Services die müssen so gut wie immer funktionieren, auch wenn der zentrale LDAP-Server und|oder DNS nicht verfügbar sind und dazu gehört eben die SSH.
SSH ist kein Services sondern ein Protokoll. Da hast Du natürlich Recht, laut RFC ist die Secure Shell ein Protokoll - laut manpage von ssh ist es ein Client und frage ich den Paket-Maintainer, dann bekomme ich als Antwort:
secure shell client and server (metapackage)
This metapackage is a convenient way to install both the OpenSSH client
and the OpenSSH server.
und nu, wollen wir uns jetzt hierzu wirklich "streiten" - nicht wirklich, oder?
... Da denke ich noch gar nicht an Layer 4 oder Layer 7 Services.
Bitte Layer 8 nicht vergessen!
Hört sich eher nach Planungsversagen, Designfehler oder unfähiges Personal an.
Tja, Du hast es erfasst - war u.a. ein Grund neben dem putty-Gewürge und noch ein paar andere Themen, warum ich dort weg bin - katastrophaler Laden, der sich selbst auch noch als systemrelevant einstuft(e).
Ich habe das bei uns mal ausprobiert. Dauert bei uns recht lange bis die Datei erstellt und verteilt wurde.
Echt? Wie viele Ansible-Controll-Nodes bzw. gesonderte Administrationsworkstation hast Du denn da?
Erzeugt auf dem Netzwerk einen deutlichen Peak und ist auch bei Nutzung nicht performant. Wie viele Geräte hast du in der Datei stehen?
Na ja, gucken wir doch mal...
$ wc -l ~/.ssh/config
1860[09:35:00] ↳ config: Generieren und kopieren der SSH Client Konfiguration ~/.ssh/config.
↳ vmlXXXXXX | CHANGED | 1.63sFür den Komfort für uns ein akzeptables "Kosten/Nutze"-Verhältnis, zumal ja nicht alle 5 Minuten 42 neue (v)Hosts hinzukommen.
Pfiade
Moin,
Aber evtl. kann hier bei uns noch Optimierungen vornehmen. Muss ich bei Gelegenheit mal ansprechen.
Gruß,
Dani
Echt? Wie viele Ansible-Controll-Nodes bzw. gesonderte Administrationsworkstation hast Du denn da?
einige hundert Administrationsworkstation mit mehreren tausend Nutzern.Na ja, gucken wir doch mal...
Häng an deine Zahl noch 3 Stellen ran und bist grob in meiner Dimension unterwegs.Aber evtl. kann hier bei uns noch Optimierungen vornehmen. Muss ich bei Gelegenheit mal ansprechen.
Gruß,
Dani
