Dank unseres sehr guten Hiwis Oliver G., ist es nun möglich den eigenen öffentlichen SSH Schlüssel über die Support Webseite hochzuladen.
Technisch wurde es dadurch sinnvoll möglich, in dem ich den LDAP Server um ein passendes Schema erweiterte, damit der Schlüssel im jeweiligen Benutzerkontext abgelegt werden kann.
Der Schlüssel wird vom Frontend (support.rbg..) entgegen genommen, auf Plausibilität überprüft (Fingerprint) und dann in den LDAP Server eingetragen. Das Backend unserer Studentenverwaltung (auf einem anderen Server) holt diesen Schlüssel aus dem LDAP heraus und schreibt ihn dann in das Heimatverzeichnis.
Das Backend sorgt auch dafür, dass die Datei- und Verzeichnisrechte stimmen. Außerdem könnt ihr mehrere Schlüssel (nacheinander) hochladen, wenn ihr mehrere verwendet. Die authorized_keys wird nicht überschrieben, sondern immer nur angehangen. Das ist sehr sinnvoll, wenn ihr eure schwachen Schlüssel gegen stärkere tauschen wollt 🙂
ISP Blog - Fachbereich Informatik
Technische Infos über den ISP Betrieb
ISP Blog - Fachbereich Informatik © 2017
Frontier Theme
Das ist super. 🙂 Das wird einiges einfacher machen!
Was ich nur nicht verstehe ist das recht aufwändige Authentifikationsverfahren:
Zuerst muss ich mich auf support.rbg im SSO einloggen (HRZ-Daten). Dann bekomme ich eine Mail an meine @stud Adresse und muss sie abrufen (mit HRZ-Daten) und der darin enthaltene Link führt mich dann zu einer Seite in der ich mich (vielleicht) nochmal im SSO (HRZ-Daten) anmelden muss. Dann darf ich den Key hinterlegen.
Warum der Umweg über die E-Mail? IMHO ist es Authentifikation genug wenn ich einmal statt zwei bis drei mal meine HRZ-Daten eingegeben habe 😉
Das ist das gleiche Prozedere wie bei einer Passwortänderung. Es wird über zwei Wege festgestellt, ob auch wirklich DU die Anfrage gestellt hast, und nicht jemand, der zufällig deine offene SSO Session mitbenutzt.
Ok, das ergibt schon Sinn. Ich meinte aber mal gehört zu haben, dass sich das SSO so konfigurieren lässt, dass auf ner bestimmten Seite eine Neuanmeldung erzwungen wird. Bin mir aber nicht sicher ob das tatsächlich so ist.
Kurz etwas Offtopic. Das WordPress merkt sich die Profileinstellungen nicht. Wenn man sich neu einloggt sind alle Änderungen vergessen. Insbesondere bei Anzeigename. Das ist sehr ärgerlich, weil ich das vorhin nicht bemerkt habe und da oben nun mein vollständiger Nachname steht und ich das nicht editieren kann. Könntest du das für mich erledigen? :S
Hi Jannik. Support zwingt dich zur Neuanmeldung beim SSO für jede Aktion, die du durchführst.
Ich finde es selbst etwas nervig, wenn man direkt nach Anfrage auf den Link in der Mail klickt, da man in kürzester Zeit den HRZ-Login erneut eingeben muss. Aber da man ja eigentlich nur selten Aktionen auf Support anfragt, fällt das insgesamt nicht ins Gewicht und wir verwenden daher die ‚renew‘ für jede Aktion.
Dass jede Aktion (ausser Accountverlängerung) bestätigt werden muss, hat andere Gründe. Mit anklicken der Bestätigung in der Mail verifizieren wir für dich ein Ticket vom SSO auf dem Server, der die Accountänderung durchführt. Das Ticket ist effektiv eine Signatur deines HRZ-Logins mit dem Inhalt ‚Ich war hier und hab X gewollt‘. Das Ticket und dessen Verifizierung läuft damit völlig ausserhalb vom Support-Webservice.
Ja ok, aber wo ist der Gewinn durch die E-Mail? Wenn ich mich ohnehin neu im SSO anmelden muss, wenn ich support.rbg besuche, kommt die angesprochene Gefahr durch Missbrauch einer offenen Session ja nicht in Frage.
Was ich meine ist, dass das was auch immer ausgeführt wird wenn ich auf den Link in der E-Mail klicke, ja auch direkt passieren könnte, wenn ich auf den „SSH Publik-Key registrieren“ Button klicke. Ich kenne natürlich die Interna nicht, aber das ging mir so durch den Kopf.
Letztendlich könnt ihr das natürlich machen wie ihr wollt. Dachte nur anders wäre es ggf. nutzerfreundlicher.
Dieser Umweg verhindert, dass jemand mit Zugriff auf Support ein Passwort ändern kann, ohne dass beim SSO ein Proxy dafür geöffnet wurde (was Support selbst nicht kann).
Es dient also nicht zur doppelten Absicherung der Authentizität des Nutzers, sondern zum Schutz vor unbefugten Änderungen.