Follow

Klassiker: Feierabend weil dir der Zugriff auf die Maschine fehlt auf der die Daten sind die du gerade brauchst und alle Kollegen mit Zugriff sind im Urlaub.

Dieses Ding mit den ordentlich verteilen SSH Keys scheint mir auch noch nicht ganz gelöst. Wie macht ihr das denn so in größeren heterogenen Infrastruktur Landschaften (>100 Kisten)?

Doch noch einen Kollegen gefunden... doch kein Feierabend... schade :P

@uint8_t als ich das das letzte Mal angefasst habe, war das eher schmerzhaft. Ist das inzwischen weniger geworden?

@leah man muss schon auf Schmerz stehen wenn man LDAP aufsetzen will

@uint8_t warum hab ich nur mit dieser Antwort gerechnet 😋 Ne lass mal, das ist nicht so mein Kink

@uint8_t @leah Also Ldap tut eigentlich ganz gut. Mit sssd ist es besser geworden.
Mit dem Realm Tool und Kerberos ist die Integration in ein Microsoft AD auch einfach geworden. (Machen wir aber mit Passwort, ohne Key)

@leah Wir haben gerade einen Versuch gestartet, Unternehmensweit HashiCorp Vault einzusetzen, um geteilte Zugangsdaten zu speichern. Primär für Passwörter, aber ich kann mir vorstellen, dass da auch was mit SSH-Keys geht.

vaultproject.io/

@leah viele Kunden nutzen CyberArk *seufz* *seufz*
Toll ist das nicht, und auch da hast du dann das Problem, wenn wirklich mal keiner von denen da ist, die neue Zugriffe erlauben können... verschiebt das Problem also quasi nur.

@leah Also bei uns haben alle den selben Key 😉

@clerie
jeder der selber key? :o

@leah
ein zentraler server (der natürlich seehr gut abgesichert ist), mit dem man auf alle anderen kommt

@leah Ein anderer Teil der Firma hat chemnitzer.linux-tage.de/2019/ im Einsatz.

Kurzlebige SSH-Keys via 2FA und gar keine Verteilung von authorized_keys. Das ganze ist mit SSH CAs realisiert.

@leah Man kann sich einen CA-Key erstellen. Dessen public Teil verteilt man auf den Servern. Dann kann man damit die Keys der Mitarbeiter signieren und schon können die die "überall" benutzen.

@leah
heiliger root key liegt ausgedruckt im Tresor und nur der Chef kommt da ran. Auch nicht so hilfreich 😂

@leah Ex-Firma hat einfach bei Eintritt deinen SSH-Key genommen und auf allen Systemen (>700 damals) ausgerollt, per Puppet. Root-Rechte inklusive. ~30 Personen in der Technik.

@l3viathan @leah same here, aber nur 1,5 Vollzeit-Admins und 30 andere Mitarbeiter.

@leah Wir (GitLab) versuchen immer mehr Systeme und Daten per Bot / CI / Chat-Kommando verfügbar zu machen als Alternative zu SSH.

Dadurch ist es deutlich einfacher nachzuvollziehen was gemacht wurde, wenn etwas schief geht, man kann mehr Leuten Berechtigungen geben und wieder kehrende Aufgaben sind weniger nervig.

@leah Wir sind nicht _so_ heterogen, d.h. alles Debian. Wir bauen dann immer ein Paket mit den aktuellen Keys, wenn ein Mitarbeiter dazukommt/geht, und die Kisten holen es per Auto-Update.

Mit im Paket ist ein Script, was die paketierten Keys und zusätzliche Extra-Keys auf den Systemen (intern meist fürs Backup, extern haben einige wenige Kunden Zugang) zur authorized_keys zusammenbaut.

@leah entweder mit kerberos (ad oder freeipa falls) und entsprechend a2a konfiguieren (via gruppen) und/oder via salt/spacewalk einfach die keys verteilen - je nach rolle/activationkey.... funktioniert gut (>1600 linux kisten...) das schwierige ist eigentlich nicht das verteilen, sondern das korrekte gruppieren/einschränken der rechte :)

@leah SSH Schlüssel ordentlich verteilen. 😉 Über Paketquellen die automatisch aktualisiert werden oder Ansible Master Voodoo...

@kleinsophie darauf würde ich wegen der Schmerzen gerne verzichten.

@leah Welcher Schmerz? Das läuft absolut Problemlos. Nahezu Geräuschlos.

@kleinsophie als ich mir dass das letzte mal angeguckt habe war das ein rumwühlen in quasi unleserlichen Config Dateien usw. Hat sich das geändert?

@leah Zumindest im RedHat Ökosystem gibt es sowas wie authconfig der du einfach sagst: Da ist ein LDAP server. Mach da Auth.

Wird alles im Kickstart erledigt.

@kleinsophie der Schmerz bezog sich nicht auf das LDAP auf dem Client, sondern auf den LDAP Server den man dafür aufsetzen müsste.

@leah 389 Directory Server und Microsoft AD (ist auch LDAP) sind sehr handzahm.

Letzteres gibt es auch als Azure-Service. Damit hast du eine Dauerhafte Verfügbarkeit.

@kleinsophie MS AD ist keine Option. Ersteres kannte ich noch nicht, werde ich mir mal ansehen. Der erste Blick auf die Doku schreckt mich schon mal nicht sofort ab :) Danke

@leah @kleinsophie Früher gabs mal Fusiondirectory das ist ein LDAP mit einfachem GUI und debian installer damit amn so use cases wie Access abhandeln kann

nichts für weitere Datenbank use cases aber als Auth mit einfacher bedinenung sehr cool.

Sind aber am umbauen der supportstruktur finde deren page nur noch auf Französisch :)

fusiondirectory-user-manual.re

@leah @kleinsophie ja, heute wühlst du direkt im ldap rum anstatt in config files.

@leah Auf den Cloud-Maschinen durch den Jenkins ins Base-Image eingebacken, ansonsten via Ansible verteilt.

(Ansible in meinem Fall hier mit: github.com/luzifer-ansible/use)

@leah also wir hatten bis vor kurzem ja auf allen ~100 Systemen einfach das gleiche root Passwort...

@leah mittlerweile nicht mehr.

Mittlerweile hat jeder einen SSH-Key und dadurch Rechte auf den Systemen.

@leah not entirely relevant but Google Cloud Platform hat ein Feature zum automatischen Ausrollen von Accounts und Keys auf allen (beliebig vielen) VMs.

@leah wir verteilen die ssh keys und sudoer files per Ansible. Nach Gruppen sortiert oder selten auch Host spezifisch.

@leah vaultproject.io/docs/secrets/s ? Noch nicht für ssh-keys benutzt für Token & pki war es gut. Per HTTS Public key abholen sollte ja auch recht Platform agnostisch gehen

@leah Configuration management. Ich nutze Chef (chef.io/). Aber es gibt viele systeme. :)

@leah für SSH Keys ansible, daneben steht noch eine freeipa Instanz die sso für ein paar Dienste macht. Darüber könnte man aber glaube ich auch ssh/auth Abwickeln lohnt bei uns aber noch nicht

@leah Den aktuellen "keyring" per https:/…/company-name.keyring runterladbar, via skript in die ~/.ssh/authorized_keys packen.

Mit ein bißchen drumrum knnast Du auch externe Keys je user einbinden, die nicht im company keyring sind.

Ich werde den Nachbau der scripte vom Vorarbeitgeber mal veröffnetlichen.

Das Update läuft dann so:

1. Anmelden auf dem system
2. "sshkey-update" eingeben.

Punkt 1 kann auch ein ansible script mit einem passenden inventory file erledigen.

@leah ssh fragt ldap nach den keys, im ldap steht auch auf welche Kisten wer drauf darf.

@leah OpenLDAP / Samba4 als zentraler Verzeichnisdienst. Persönliche Accounts zum Anmelden auf den Servern, dann sudo je nach Gruppe und Server.

@leah
Wir warten bis der entsprechende Kollege wieder da ist hahaha :'D

@leah wir hosten grundsätzlich mit unserem Stammhoster, den Chef und die wichtigsten Mitarbeiter kennen wir persönlich. Wenn ich denen eine Mail schreibe, dass ich meinen Key auf diesem oder jenem Server brauche und von welcher anderen Kiste sie den nehmen sollen ist der da innerhalb von 10 Minuten. Sehr unautomatisiert aber selten nötig

@leah Wir haben in unseren Clouds automatisiertes Key-Provisioning. Wenn man die entsprechende Rolle hat kann man seinen Pubkey auf der Kiste ausrollen. Aber man ist genauso nass wenn niemand da ist um die Rolle zuzuweisen.

@leah Unsere keys sind mandantenbasiert. Kunde X hat Key X und wer für den arbeitet, kann alle Maschinen erreichen.

Sign in to participate in the conversation
chaos.social

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!