| 6 Jan 2025 |
 palo | aber ich hab auch kein großes Problem mit SSH. Ich glaub das Hauptproblem mit SSH ist oft, dass sowas wie Jump Post benötigt werden, was sowas wie Einfallstor sind. Dort wird oft mit SSH agents gearbeitet, die gefordert werden und von anderen Hijack werden können. | 21:26:28 |
| palo | * aber ich hab auch kein großes Problem mit SSH. Ich glaub das Hauptproblem mit SSH ist oft, dass sowas wie Jump hosts benötigt werden, was sowas wie Einfallstor sind. Dort wird oft mit SSH agents gearbeitet, die gefordert werden und von anderen Hijack werden können. | 21:26:45 |
 CRTified | Ja gut, das sollte nun echt nicht gemacht werden | 21:27:03 |
| CRTified | SSH erlaubt so spannend-wilde Konstruktionen, theoretisch sogar mit TOTP 😄 Da ist das irgendwie schade dass es kaum genutzt wird | 21:27:42 |
| palo | In reply to @crtified:crtified.me
Ja gut, das sollte nun echt nicht gemacht werden ist aber leider sehr gängige praxis | 21:28:15 |
| CRTified | Ich schau mir theoretisch solche Späße beruflich an, SSH war bisher aber echt wenig vertreten 🫣 Aber vielleicht kommt das noch | 21:29:42 |
| palo | echt? ich habe das so oft gesehen, und in AWS sind wir zum glück in der regel auf den aws-agent gewechselt, der ohne jumphost auskommt und via IAM configuriert werden kann. hashicorp boundry ist sowas ähnliches self-hosted, aber hab damit noch keine erfahrungen. | 22:09:05 |
| CRTified | Vermutlich ein Ergebnis dessen, dass ich leider fast nur auf Windows-Kram schaue 🥲 | 22:09:35 |
| palo | oh, im sorry to hear that | 22:09:52 |
| CRTified | Ich bin mir stellenweise echt nicht sicher, ob oder wie lange ich beruflich da bleiben möchte. Aber aktuell läuft es zufridenstellend und das Team ist echt gut 🤷 | 22:10:28 |
| CRTified | Da kann ich Windows ertragen, ich muss es ja nicht administrieren | 22:10:36 |
| palo | ich glaube ein problem mit ssh ist auch das du die nutzer nicht zwingen kannst eine ordentliche config zu nutzen.
ohne password und so, werden die keys dann auch gerne in github eingecheckt.
ein wunsch in grossen setups ist das totp nicht optimal sonder zwang ist … und ssh liefert sowas nicht soweit ich weis. du kannst glaub ich weder password geschweige denn password komplexität erzwingen. | 22:12:42 |
| CRTified | Zumindest nicht fürn Key, das liegt halt beim User. Aber TOTP geht dank PAM ganz ok (so wie gefühlt alles dank PAM geht) | 22:14:04 |
| CRTified | Wenn keyboard-interactive oder halt password-auth verwendet wird, dann ist das Passwort wieder auf Serverseite -> Komplexitätsregeln sind enforcebar | 22:15:36 |
| CRTified | Aber dann hat man keine pubkey auth, das ist auch wieder blöd | 22:15:43 |
| palo | oh aber das mach ich gar nicht mehr, password auth finde ich irgendwie nixh schlimmer. | 22:16:31 |
| palo | * oh aber das mach ich gar nicht mehr, password auth finde ich irgendwie noch schlimmer. | 22:16:37 |
| CRTified | Ja, pubkey auth ist definitiv vorzuziehen, aus vielen Gründen | 22:17:18 |
| CRTified | Nebenbei: SSH ist mittlerweile seit einigen Jahren gegen Quantenangreifer resistent, weil Streamlined NTRU Prime neben ML-KEM per default supported und aktiv sind | 22:18:47 |
| CRTified | Also zumindest OpenSSH 😄 | 22:19:01 |
| palo | Aber ob Quantencomputer zu meiner Lebenszeit noch eine sinnvolle Aufgabe erfühllen werden, bezweifel ich immer mehr und mehr. Mit jedem bit werden die dinger fehleranfälliger und die durchbrüche von denen die da reden sind auch alle so "meeeh". Aber schadet nicht dagegen vor zu beugen. | 22:49:33 |
| CRTified | Man kann auch einen guten Grund sehen, andere Verfahren haben zu wollen, ohne dass man Quantencomputer als realistisch ansieht: Allein die Tatsache, dass es durch den Algorithmus von Shor einen einheitlichen Angriff auf Faktorisierungs- und DLog-basierter Kryptographie gibt, und für "die anderen Verfahren" eben keinen besonders guten Quantenangriff gibt, könnte ein Indikator dafür sein, dass die klassische Kryptographie auch ohne Quantencomputer eher Schwächen haben könnte | 22:56:01 |
| CRTified | Und es wird bei der Standardisierung jetzt einiges richtiger gemacht als bei alten Verfahren, z.B. wird direkt von Anfang an im Design der standardisierten "Funktionen" sichergestellt, dass standardkonforme Implementierungen resistenter gegen Fehlverwendungen sind (Bestes Negativbeispiel dürfte hier z.B. RSA im ECB-Modus sein 😄 ) | 22:57:09 |
| 8 Jan 2025 |
 bit | Wer ist nächste Woche wieder dabei?
Ich bin nächste Woche nicht da, werde mich dann aber wieder um einen Ersatzhost kümmern | 17:24:36 |
 Moritz Sanft | Ich wäre da | 17:35:10 |
 matthias | Ich auch | 17:38:11 |
 miampf | Weiß ich noch nicht, entscheide nächste Woche einigermaßen spontan :) | 22:25:43 |
| 9 Jan 2025 |
 Benedikt Ritter (britter) | Müsste ich mal mit meiner Frau verhandeln. Bin am Donnerstag schon unterwegs. Ich meld mich noch mal. | 17:38:56 |
|  🦎 Valentin 💛🤍💜🖤 (any pronouns) joined the room. | 21:18:21 |
| 10 Jan 2025 |
 butterkeks | Werde wohl auch da sein, kann also auf machen 👍️ | 01:58:36 |
