@mediacccde eher mehr als 40-jährigen Geschichte.... oder noch mehr...

@stefan also mein Kind ist schon im LDAP angelegt. Und damit hat es schon eine Email-Adresse, einen XMPP-Account, einen Pleroma-Account, einen Matrix-Account, einen Nextcloud-Account... usw. :)

@LemmyDev
Hi!

Ich würde auch gerne mit eurer Instanz föderieren. Meine Instanz ist neu, deutschsprachig und soll sich in erster Linie mit den Themen Eisenbahn, Modellbahn, Öffentlicher Verkehr, Radverkehr, Städtebau, Stadtplanung und ähnlichen Dingen beschäftigen.

Was bei mir nicht toleriert wird, sind Rassismus, Extremismus, Homophobie, Verschwörungstheorien, Hetze und Diskriminierung gegen und von Menschen aufgrund ihrer Herkunft, Aussehen, Religion, Behinderung oder sonstigem.

Einzig gegen selbstgewählte Dummheit und Ignoranz darf man sich schon auch einmal auslassen.

Es ist geplant, meine Instanz von der Userzahl eher klein zu halten, was die Themen und Beiträge aber nicht betreffen soll. Meine Instanz dient vorwiegend mir selbst und eventuell Familie und ein paar Freunden und Vereinsmitgliedern als Tor in die föderierte Lemmy-Welt.

Würde mich also sehr freuen, wenn ihr https://lemmy.schuerz.at mit lemmy.ml föderieren lasst.

@Teufel100 man kan berechtigterweise über Amazon, dessen Beschäftigungspolitik, dessen Steuersparen usw. klagen und schimpfen.

Aber dass Amazon so erfolgreich ist verdankt es auch dem Dilletantismus des heimischen Handels in Sachen "Neuland"...

@nitrokey Ich nutze zwar schon länger die Zertifikate, hab aber mangels HW-Token noch keine Erfahrung damit (Eure neuen Nitro-Keys werden meine ersten privaten sein - aktuell hab ich nur den etoken aus der Organisation im Einsatz, für die ich tätig bin). Und ich hab - muss ich gestehen - auch noch nicht wirklich Infos dazu gefunden, ob das Zertifikat auf den Key soll...

So wie in dieser Anleitung https://framkant.org/2017/07/scalable-access-control-using-openssh-certificates/ wird das Zertifikat im Filesystem abgelegt und per CertificateFile in der ssh-config oder über Commanline-Options eingebunden.

Meiner Meinung nach aber sollte das Zertifikat ja zum Private-Key - also auf den Token selbst. Und ich weiß nicht, ob ssh-agent oder gpg-agent in der lage sind, diese Zertifikate von dort auszulesen.

Momentan hab ich auch am derzeit eingesetzten etoken noch nicht geschafft, das Zertifikat abzulegen.

@nitrokey ssh zertifikate sind ziemlich cool. Wenn man eine entsprechende PKI aufbaut, wären so Tages-Zertifikate oder Wochenzertifikate möglich, die man sich am Beginn der Periode abholt, und die automatisch ablaufen.

Vor allem erleichtert es den Tausch eines Tokens, wenn dieses kaputt oder verloren ging enorm. Es reicht einen neuen Token auszugeben, das Zertifikat per Email dem User zuzustellen und schon kann dieser mit dem neuen Key sich schon wieder einloggen, ohne einen einzigen Pubkey auszutauschen.

Die Revoke-List ist ein einfaches kleines Text-File mit den Seriennummern der widerrufenen Zertifikate, welches aus der CA exportiert werden muss und dann per ansible oder ähnlichen Mechanismen auf die Server auch im Nachhinein verteilt werden muss. Sowas kann man auch schön automatisieren...

Im Gegensatz dazu steht, dass man mit Pubkeys only auf jedem Host die authorized-keys-Datei aktualisieren muss. Und das kann bei vielen Servern per ansible schon eine schöne lange Zeit dauern.

@nitrokey ok. Ohne dem Feature kommen die Nitrokeys bei uns nicht in Frage. Es stellt sich für uns dann die Frage, falls es das Feature gibt, ob bloß wir im Team auf Nitro-Keys umsteigen, das wären dann ~20 User.
Oder ob die gesamte Organisation eventuell umsteigen würde... das wären dann mehrere hundert Keys. Aber das liegt alles nicht in meiner Entscheidungskompetenz. Ich kann höchstens den Vorschlag machen und die Infos übermitteln.

@nitrokey ok.

ich hab mir einmal 2 der neuen Keys geordert und werde sie einmal selbst testen und den kollegen zeigen und darauf hinweisen, dass es die Möglichkeit gibt, eine eigene Lösung auch von euch zu bekommen.

Wäre sowas im Preis schon inbegriffen, oder müsste das extra bezahlt werden?

@saxnot @nuron Wem das eingefallen ist, dass das Zeugs mit dem GRÜNEN Punkt in den GELBEN Sack muss....

@Teufel100 nein. aber bitcoins schürfen...

@nitrokey Wenn ein Computer kompromittiert ist... ja da hätte jeder ein Problem. In jedem größeren Unternehmen gibt es User die vor ihren PCs wie die ersten Menschen sitzen... und auf alles Klicken, was wie ein Link aussieht... ich hab noch kein Unternehmen erlebt, wo das anders war... Da nutzt die beste Schulung oft nix, weil diese MA dort dann pennen...

Und social engineering funktioniert leider immer wieder... vor allem, wenn es gut gemacht ist, und deine Organisation gezielt ausgewähltes Target eines solchen Angriffes ist... (Ich sage nur Stuxnet...)

Und wenn über so einen Angriff die Keys von Schlüssel-Arbeitskräften ausgeschaltet werden, dann kann der kompromittierte Rechner leicht in das ganze Netzwerk vordringen, ohne aufgehalten zu werden, da die Systeme nicht mehr per ssh erreichbar sind... weil die Keys zurückgesetzt wurden...

Ja, in Summe eine ziemlich ungute Situation. Vor allem wenn es Sicherheitsrelevante Systeme sind, die nicht einfach so abgedreht werden können...

Ich nehme an, per Firmware könnte man einen Master-PIN zum zurücksetzen sehr einfach einbauen.

@nitrokey Ich meine nicht die Private-Keys. Ich meine ZERTIFIKATE! Das ist etwas anderes.

Ich kann einen Pubkey oder auch einen Hostkey mit einer CA Zertifizieren (diese wird AUCH mit ssh-keygen erzeugt!!!).
auf dem Host wird dann nur mehr das CA-Zertifikat hinterlegt (keine Pubkeys in einer authorized-keys Datei mehr!!!) , mit der die User-Pubkeys zertifiziert wurden und am Client wird nur mehr ein CA-Zertifikat hinterlegt, von der die Host-Keys der Server signiert wurden.
Es gibt dann auch keine Datei "known-hosts" mehr. ssh prüft ob der Key, der sich einloggen möchte auch von der hinterlegten CA zertifiziert wurde (bzw. der Client prüft, ob der Hostkey mit der richtigen CA zertifiziert wurde).

Das ist eine Erweiterung zum klassischen Priv/Pubkey-Authentifizierungs-Modell von openssh.

Im Zertifikat können noch IP-Adressen von denen aus es gültig ist, principals und Befehle hinterlegt werden, die ausgeführt werden dürfen.

Eine ziemlich geniale Geschichte.

Zum Angriffsvektor... Nun. Derzeit haben wir etoken im Einsatz. Die Begehrlichkeiten für Nitrokeys sind bei uns vorhanden, es großflächiger einzusetzen. Es gibt aber die unumstößliche Anforderung, dass ein Key nur mit Master-PIN zurückgesetzt werden können darf... daher schieden bisher sämtliche Anbieter außer etoken aus... Ich mein ja nur... es könnte durchaus sein, dass ihr euch durch das Fehlen dieses Features ordentlich Geschäft entgehen lasst... Wir sind sicher nicht die einzigen, die diese Anforderung haben.

@levin @kuketzblog Den Nitrokey HSM brauchst du für die CA. Wenn du es genau nimmst, bräuchtest du eigentlich 2 solcher HSMs weil du sinnvollerweise 2 CAs betreibst. Eine für die Hostkeys, welche von den Sysadmins verwatet wird, und eine für die User-Keys, welche von der z.B. Personalverwaltung verwaltet wird, die auch die HW-Tokens für die Mitarbeiter ausgibt.

Auf die Rechner der User kommt das CA-Zertifikat der Hostkey-CA, auf die Server kommt das CA-Zertifikat der User-CA (und zusätlich das Zertifikat des Hostkeys)

Jeder User bekommt mit dem Token auch sein persönliches Zertifikat ausgegeben, welches er dann zwingend zur Authentifizierung benötigt.

@nitrokey Ich hab euch eh schon einmal gefragt und das Szenario geschildert, warum ein Zurücksetzen mit Master-PIN (so wie es etoken macht) sinnvoll und für den Einsatz bei uns im Unternehmen unumgänglich ist.

Angenommen:
Ein kompromittierter Rechner ist im Unternehmen. Der Mitarbeiter steckt seinen Key rein, und der komprommitierte Rechner setzt beim Einstecken des Sticks diesen zurück, da es ohne Master-Key geht. Der Stick ist raus. Der MA kommt nicht mehr auf seine Server.

Es kommt der Admin, und steckt seinen Key in den rechner (es ist noch nicht bekannt, dass der Rechner kompromittiert ist). Und auch sein Stick wird zurückgesetzt.
Es kommt der 3 Admin... und schon sind im schlimmsten Fall alle wesentlichen Tokens unbrauchbar und die Admins auch von den Servern ausgesperrt.

Ein Szenario, welches mit Rücksetzen ausschließlich mit Master-Key nicht möglich ist, das so aber ein ungutes DoS verursachen kann.

Und mit SSH-Zertifikaten meine ich das:

https://ef.gy/hardening-ssh

Ein wirklich geniales, relativ neues Feature von openssh (hat auch schon ein paar Jahre auf dem Buckel... aber im Vergleich zu ssh selbst, ist es relativ neu)

@levin @kuketzblog Ein "relativ" neues und leider noch sehr unbekanntes Feature von openssh.

https://chandanduttachowdhury.wordpress.com/2014/12/31/certificate-based-ssh-user-authentication/

https://ef.gy/hardening-ssh

Ziemlich geniale Geschichte.