SSH Login auf Domainmember

UCS - Univention Corporate Server
1

Guten Morgen!

Das ist mein erster Post, also möchte ich mich kurz vorstellen:
Mein Name ist Ralf, bin knapp über 40 Jahre alt, habe seit gut 20 Jahren mit Linux zu tun (privat Windows-free seit 2005) und bin in einem saarländischen Systemhaus als DevOps Engineer tätig.

Nun wurde ich beauftragt, mögliche Verzeichnisdienste zu evaluieren, die uns vom hausinternen AD unabhängig machen. Ziel soll sein, dass wir, d.h. meine Abteilungskollegen und ich, uns nicht mehr wie bisher von unseren Desktops auf die Produktiv-VMs mit einem generischen User und Passwort anmelden. Wir wollen personalisierte User, die sich per SSH-Key anmelden. Bisher wurde der generische User und sein Pubkey per Chef auf die VMs verteilt, es wäre durchaus denkbar, dass wir dort unsere User mit unseren Pubkeys verwalten. Aber auch davon wollen wir -wenn möglich- weg.

Einen UCS habe ich installiert und gemäß Anleitung ein paar Ubuntu-VMs hinzugefügt, ebenso einige Testuser. Hat soweit alles problemlos funktioniert. Auch der Login von meinem Desktop in eine VM mit einem der Testuser-Accounts funktioneirt, allerdings nur mit Passwort. Ist dort das home für den User noch nicht vorhanden, wird es erstellt. so weit, so gut.
Allerdings würden wir gerne davon absehen, jedesmal beim deployen einer VM sämtliche User von Chef anlegen zu lassen und die Pubkeys zu verteilen. Das soll der zentrale Verzeichnisdienst erledigen.

Und hier kommt dann meine erste Frage: Im Benutzerregistrierungsformular habe ich dazu in den “Erweiterten Einstellungen” zwar die Möglichkeit gefunden, einen Key im DER Format hochzuladen. Wir haben allerdings eh schon eigene Schlüssel (generiert mit ssh-keygen) und würden die auch gerne weiterverwenden. Zum anderen werden privatre Schlüssel im DER eben nicht gespeichert; mir ist momentan nicht klar, ob und wenn ja, was dann in /home/<mein_user>/.ssh/authorized_keys stehen würde.

Hier: Ssh login ohne Passwort
ist davon die Rede,dass auf einem Zielsystem, sprich: ein der Produktiv-VMs, der User bereits vorhanden sein muss. Wie gesagt: die Userverwaltung würden wir gerne aus Chef rausziehen und es bspw. durch UCS erledigen lassen. Nach dem Erstlogin wird zwar /home/<mein_user> angelegt, allerdings ohne ~/.ssh/authorized_keys

Hier: http://docs.software-univention.de/handbuch-4.1.html#computers:SSH-Zugriff_auf_Systeme
ist davon die Rede, dass die Kennwortabfrage für root ausgeknipst werden kann, dass die Authentifizierung mittles Pubkey geschieht. Nur: woher kennt UCS den Pubkey von root? Wie kann ich UCS dazu bringen, genau das selbe (wenn ich es richtig verstanden habe) für non-root User zu tun?
Ist es möglich meine id_rsa.pub irgendwie dem UCS mitzugeben, damit er diese dann beim (Erst-)Login in die VM in mein home schreibt?

Im Vorraus schon einmal vielen Dank für Antworten und Tipps.

mfG
Ralf

2

Hallo Ralf,
die Zertifikatseinstellungen sind von SMIME Zertifikate und nicht für SSH-Keys.

Du kannst die ssh-keys einfach von Hand in der $HOME/.ssh/authorized_keys Datei eintragen.

Wenn das Verzeichnis und/oder Datei nicht vorhanden ist, musst du es anlegen. Dabei auf die Permissions achten.

Ich mache das mit den Keys so: Ich erselle auf jedem Gerät mit ssh-keygen einen eigenen Key. Das hat den Vorteil dass, wenn ich ein Gerät verlieren sollte, einfach diesen Key überall entferne und alles andere weiter läuft. Für das Deployment nutze ich Ansible. Wenn du NFS/Samba für Homeverzeichnise nutzt, musst du das auch nicht auf jeden Rechner neu anlegen, wäre das eine Option?

3

Hallo digitec-san,

vielen Dank für deine Antwort!
Nur leider trifft es nicht das, wo ich hin will. Derzeit verteilen wir die User und Pubkeys zwar nicht mit Ansible, aber mit Chef. Und genau davon will ich weg. Bzw.: ich will nur eine Lösung haben: entweder ein zentraler Verzeichnisdienst, der Benutzerobjekte verwaltet oder eben ein wie auch immer geartetes Provisionierungstool. Insbesondere für die Benutzerverwaltung tendiere ich zu ersterem. Chef/Puppet/Ansible/younameit sehe ich eher für Config- und Softwareverwaltung.

“Einfach von Hand eintragen” … Nein! Ich mache alles nur einmal von Hand, für repetitive und dröge Aufgaben sind Computer da.:wink:
Ok im Ernst. Wir nehmen VMs, wofür sie gedacht sind: als Wegwerfobjekte zum einmaligen Gebrauch. Die Entwickler schreiben ihren Code, pushen ihn ins Git, da laufen Hooks los, die den Code paketieren, die VMs, auf denen der “alte” Code läuft, werden weggeschmissen und neue VMs mit neuer Software deployt. Das kann -je nach Codefragment- auch mehrfach die Woche passieren. Da ist es schlichtweg weder handelbar, noch irgendwie zumutbar, die VMs erst mehr oder weniger langwierig vorzubereiten.

Ich habe mir zwischenzeitlich auch mal freeipa angesehen: dort ist es machbar.
ipa user-add loginname --first=vorname --last=nachname --sshpubkey=“ssh-rsa …” und fertig ist der Lack.
Auf einer neu zu deployenden VM (basiert auf einem vanilla Ubuntu-Cloudimg) wird per Chef und ein paar Skript-Tricksereien der freeipa-Client installiert, die sshd_conf wird ebenfalls vom Chef angepasst, ich logge mich von meinem Desktop in die VM ein, bekomme dort (soweit noch nicht vorhanden) ein home-Verzeichnis erstellt (natürlich inkl. authorized_keys) und bin sofort arbeitsfähig. Ohne dass ich lokal irgendetwas tun müsste, ohne dass ich die VM in irgendeiner Weise von Hand zu Fuß vorbereiten müsste, ohne dass ich manuell am Cloudimg rumbasteln müsste. Genau so stelle ich mir das vor.

Jetzt die Frage: kann UCS das nicht, bzw. ist es womöglich dafür gar nicht ausgelegt?
Ich habe mittlerweile verstanden, dass UCS bei weitem mehr ist, als “nur” ein aufgebohrter LDAP-Server mit angeflanschtem DNS und DHCP. Und dass wir mglw. zum Teil leicht abweichende Anforderungen haben, als der Großteil der avisierten Zielgruppe. So weit, so gut. Aber ist UCS tatsächlich nicht für das ausgelegt, was wir uns im Moment vorstellen? :thinking:

mfG
Ralf

4

Hallo Ralf,
es geht halt nicht Out-Of-The-Box.
Du kannst die LDAP und die UCS Überfläche erweitern um z.B. ein Attribut für den SSH-Public-Key.

Du kannst einen Listener schreiben, der immer wenn sich etwas an dem Attribut ändert eine Aktion ausführt. Wie das genau zu Eurem Setup passt, musst du dir dann überlegen.

Das kann man natürlich noch beliebig komplexer machen, z.B. Gruppenzugehörigkeit führt dazu, das der Key in bestimmte Dateien geschrieben wird etc.

Gruß
Sven

5

Das klingt extrem verschwenderisch und zeitaufwändig. Warum volle VMs und keiner Container (z.B. auf Kubernetes)?

Ich lasse mich da gerne eines besseren belehren aber landet nicht auch jede gejointe Maschine erstmal als Objekt im LDAP? Dann hat man je nach Anzahl der deployments pro Tag irgendwann einen Gigabyte grossen Verzeichnisbaum.

Die selbe Trickserei welche mit Chef und dem FreeIPA Client auf Ubuntu funktioniert kann sich aber sicherlich auch auf den UCS Domain Join von UCS übertragen lassen.

6

Das klingt extrem verschwenderisch und zeitaufwändig. Warum volle VMs und keiner Container (z.B. auf Kubernetes)?

Ja, da hast du Recht: Container wären da schon besser. Da wollen wir auch hin, sind in den Vorbereitungs- und Umstellungsarbeiten, sind aber noch nicht so weit. Stand jetzt lassen sich auch nich alle VMs containerisieren.

Ich lasse mich da gerne eines besseren belehren aber landet nicht auch jede gejointe Maschine erstmal als Objekt im LDAP? Dann hat man je nach Anzahl der deployments pro Tag irgendwann einen Gigabyte grossen Verzeichnisbaum.

Das muss ich mal im Auge behalten. Ich ging bisher davon aus, dass ein Objekt einmal angelegt wird, wenn die Maschine gejoint wird und UCS beim nächsten Mal sieht, dass er bisher bereits ein Objekt mit dem selben (Rechner-)Namen hat, also kein neues anlegt. Wenn intern die Objekte über eine UID verwaltet werden und nicht per Namen, dann ja: dann wird der Baum irgendwann einmal Ausmaße annehmen. Den Pflegeaufwand würde ich mir gern sparen.
Guter Tipp, dank dir dafür :+1: