0j4n90
Goto Top

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

Content-Key: 22086095606

Url: https://administrator.de/contentid/22086095606

Printed on: May 28, 2024 at 07:05 o'clock

Member: LordGurke
LordGurke Jan 04, 2024 at 18:45:50 (UTC)
Goto Top
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.
Member: 0J4N90
0J4N90 Jan 04, 2024 at 19:06:19 (UTC)
Goto Top
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.
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! ;)
Member: Dani
Dani Jan 04, 2024 at 19:41:26 (UTC)
Goto Top
Moin,
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
Member: 0J4N90
0J4N90 Jan 10, 2024 at 13:18:58 (UTC)
Goto Top
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.
Member: Dani
Dani Jan 11, 2024 at 16:22:04 (UTC)
Goto Top
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.

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
Member: 0J4N90
0J4N90 Jan 11, 2024 at 18:53:57 (UTC)
Goto Top
Griasde,

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.

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.face-sad 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
Member: Dani
Dani Jan 15, 2024 at 19:38:46 (UTC)
Goto Top
Moin,
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. face-wink

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
Member: 0J4N90
0J4N90 Jan 16, 2024 at 08:46:04 (UTC)
Goto Top
Griasde

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. face-wink

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? face-smile

... Da denke ich noch gar nicht an Layer 4 oder Layer 7 Services.

Bitte Layer 8 nicht vergessen! face-wink

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.63s

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
Member: Dani
Dani Jan 17, 2024 at 11:54:41 (UTC)
Goto Top
Moin,
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