| 3 Jan 2025 |
|  Haris DD1ZZ (📞 6080) changed their profile picture. | 00:16:24 |
|  exonaiku changed their display name from exonaiku | DECT 93436 to exonaiku. | 06:19:21 |
 Benedikt Ritter (britter) | Benutzt einer von euch einen YubiKey für GPG? Ich hab jetzt schon einige male http://drduh.github.io/YubiKey-Guide/ angeschaut, aber das wirkt alles sooo aufwendig... | 10:20:10 |
 Moritz Sanft | Ja. Das Setup ist auch leider aufwendig. Aber sobald du einmal einen Key bespielt hast ist es einigermaßen plug-and-play. Bin sehr froh, ihn für Git etc. nutzen zu können | 10:21:20 |
 Paul Z | In reply to @britter:yatrix.org
Benutzt einer von euch einen YubiKey für GPG? Ich hab jetzt schon einige male http://drduh.github.io/YubiKey-Guide/ angeschaut, aber das wirkt alles sooo aufwendig... Ja, im Prinzip ist das aber das normale PGP setup, nur das nach einem Key-Backup die Keys auf den Yubikey verschoben werden. Der Yubikey kann das zwar auch on-board, dann kann man aber den privaten Schlüssel nicht sichern. | 10:40:14 |
| Benedikt Ritter (britter) | Warum macht ihr das? Wegen der erhöhten Sicherheit oder der convenience nicht jedes mal das Passwort eingeben zu müssen? Ich nutze pinentry-curses und gebe halt mein Passwort jedes mal ein, wenn ich einen commit mache 🤔 | 10:58:02 |
| 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 |
