| 3 Jan 2025 |
 Moritz Sanft | Kein Software-Key-Management, und kein nerviges Passwort-Eingeben | 11:10:57 |
| Moritz Sanft | * Kein Key-Management in Software, und kein nerviges Passwort-Eingeben | 11:11:11 |
| 6 Jan 2025 |
 f0rdprefect | was haltet ihr von https://github.com/hickford/git-credential-oauth für mich löst das ziemlich viele git auth probleme, weil es auch in unserem entra ms365 geraffel funktioniert wo alle angst vor ssh haben. Mit gnupg muss ich mich auch mal mehr auseinander setzen. Ist das hier nicht straight forward? https://www.codingblatt.de/gpg-keys-per-tpm-verschluesseln/ | 07:44:00 |
 Benedikt Ritter (britter) | Wieso haben die Leute Angst vor SSH? Vielleicht kann man besser da ansetzen und die Ängst nehmen? | 13:05:04 |
| f0rdprefect | In reply to @britter:yatrix.org
Wieso haben die Leute Angst vor SSH? Vielleicht kann man besser da ansetzen und die Ängst nehmen? Ich vermute weil das nicht zentral genug administrierbar ist | 14:21:52 |
 palo | ja, in der Regel möchte man zentral Authentifizierung und Autorisierung managen. Und wenn möglich jeglichen Zugriff sowie jede Aktion loggen. | 19:51:48 |
 CRTified | In reply to @mrvandalo:terranix.org
ja, in der Regel möchte man zentral Authentifizierung und Autorisierung managen. Und wenn möglich jeglichen Zugriff sowie jede Aktion loggen. Ssh keys im LDAP sind auch kein Hexenwerk | 20:46:00 |
| palo | 😅 für mich ist LDAP Hexenwerk 😅 | 21:22:45 |
| CRTified | Für mich auch so halb 😄 War aber der beste Kompromiss, um User Management auf meinem Homeserver nicht abhängig von der nix config zu machen | 21:23:54 |
| CRTified | Ansonsten wäre AuthorizedKeyCommand für sshd_config ein Blick wert, ganz am Anfang habe ich damit nämlich gogs fürs key management verwendet 🙃 | 21:24:32 |
| 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 |
