Anbinden eines Debian Trixie (13) System an OpenLDAP für die Benutzerauthentifizierung. Siehe auch einrichtung eines OpenLDAP Servers
Basis ist eine globale LDAP Konfiguration
/etc/ldap/ldap.conf die im weiteren Schritten benötigt wird. Hier wird
festgelegt wie der LDAP Server zu erreichen ist. Dafür das Paket
libldap-common installieren und die Konfiguration anpassen.
BASE dc=example,dc=net
URI ldaps://ldap.example.net
TLS_CACERT /etc/ssl/certs/ca-certificates.crt
Die Datei die mit TLS_CACERT angegeben wird muss das Root (und Intermediate
Zertifikat) enthalten mit dem das Zertifikat des LDAP Servers signiert wurde.
Mit dem Paket libpam-ldap wird auch der NSLCD und alles weiter installiert,
was benötigt wird um User, Passwörter und Gruppen vom LDAP Server, für eine
lokale Anmeldung am System zu holen.
/etc/nslcd.conf.
uid nslcd
gid nslcd
uri ldaps://ldap.example.net
base dc=example,dc=net
ldap_version 3
tls_reqcert demand
tls_cacertfile /etc/ssl/certs/ca-certificates.crt
pam_authz_search (&(cn=admins)(member=$dn))
Mit pam_authz_search wird eingeschränkt wer sich anmelden darf z.B. für ein
rfc2307bis Schema nur Mitglieder der Gruppe admins.
Damit beim Login der LDAP Server angefragt wird muss die /etc/nsswitch.conf
angepasst werden. Und passwd, group und shadow um den Eintrag ldap
erweitert werden.
passwd: files ldap
group: files ldap
shadow: files ldap
Damit bei einem Login das Homeverzeichnis des Users automatisch angelegt wird
die /etc/pam.d/common-session erweitern.
session optional pam_mkhomedir.so
Nach den Anpassungen den nscd neu starten, danach sollte man mit getent passwd die LDAP User sehen können und man sich auch mit einem LDAP User am
System anmelden.
Beim testen kann es hilfreich sein den NSCD Cache der die LDAP Daten auf dem
Client zwischenspeichert, auf ungültig zu setzen. nscd -i <passwd|group>
Typischerweise wird der SSH Key mit dem man sich per SSH anmelden möchte in der
~/.ssh/authorized_keys abgelegt. Dies muss so aber auf jedem einzelnen System,
an dem man sich mit seinem Key anmelden möchte erfolgen. Bequemer geht es, wenn
man seinen Key auf dem LDAP Server ablegt. Sollte sich der SSH Public Key
ändern, kann man diesen zentral austausche. Wie man das notwendige Schema
openssh-lpk auf einem OpenLDAP Server einbindet, habe ich im Artikel
OpenLDAP Server beschrieben.
Um den den OpenSSH Server anzuweisen im LDAP nach dem Public Key des Users zu
suchen erweitert man die Konfiguration unter /etc/ssh/sshd_config wie folgt:
AuthorizedKeysCommand /usr/local/bin/authorizedkey.sh
AuthorizedKeysCommandUser nobody
Das Script /usr/local/bin/authorizedkey.sh auf das in der Konfiguration
verwiesen wird sollte wie folgt aussehen:
1#!/bin/bash
2if [ -z $1 ]; then
3 exit
4fi
5
6ldapsearch -LLL -x -o ldif-wrap=no \
7 -D cn=authscript,dc=example,dc=net -w 'bindpw' \
8 "(&(uid=$1)(objectClass=posixAccount)(objectClass=ldapPublicKey))" \
9 sshPublicKey | sed -n 's/^sshPublicKey:\s\+\(.*\)/\1/p'
Das ldapsearch Kommando muss dafür auf dem System vorhanden sein (Debian
Paket ldap-utils), die LDAP Anmeldedaten (bind) sowie der Filter müssen an den
genutzten LDAP Server angepasst werden.
Zum Testen das Script aufrufen und als Parameter eine im LDAP vorhandene UID übergeben, es sollte der SSH Public Key zurückgegeben werden.
Nach dem Restart des SSH Servers sollte dann die Anmeldung per SSH Key funktionieren, ohne das dieser auf dem System direkt hinterlegt werden muss.
Auch Sudo lässt sich so einrichten, dass man sich per SSH Public Key vom LDAP
Server authentifizieren kann. Unter Debian Trixie (13) installiert man dafür
das Paket libpam-ssh-agent-auth
In der /etc/pam.d/sudo vor die bestehenden Einträge wird Folgendes eingefügt,
damit bleibt die Authentifizierung mit Passwort erhalten, wenn es per SSH Key
nicht klappt. Das Script ist dasselbe wie das, was für den SSH Server verwendet
wird.
auth sufficient pam_ssh_agent_auth.so authorized_keys_command=/usr/local/bin/authorizedkey.sh authorized_keys_command_user=nobody
In die /etc/sudors muss noch folgendes hinzugefügt werden.
Defaults env_keep+="SSH_AUTH_SOCK"
Im verwendeten SSH Client muss Key Forwarding aktiviert sein, beim OpenSSH
Client ist das in der ~/.ssh/config
ForwardAgent yes
Nach dem neu anmelden mit dem SSH Key sollte nun z.B. ein sudo ls ohne
Eingabe des eigenen Passworts möglich sein. Ein sudo -i funktioniert erst
wenn zuvor ein anderer Befehlt per sudo ausgeführt wurde ohne direkt in eine
andere Shell zu wechseln. Sollte es nicht funktionieren sollte man zunächst mit
ssh-add -l prüfen ob die Weiterleitung des SSH Keys geklappt hat.