authnd installieren

Das Repository enthält die beiden Dateien, die ein systemd-Host braucht: packaging/sysusers.d/authnd.conf (das Konto) und packaging/systemd/authnd.service (die Unit). Diese Seite erklärt beide und die Schritte drumherum. Die versionierten Dienste von go-pkgx sollen das später für Sie übernehmen; es gibt sie noch nicht.

Das Release-Binary

Jeder Tag veröffentlicht authnd-<os>-<arch> für linux, darwin und windows auf amd64 und arm64 (.exe unter windows), gebaut mit CGO_ENABLED=0, ein SHA256SUMS-Manifest und eine Build-Provenance-Attestierung für jedes Binary.

version=v0.11.1
arch=amd64          # or arm64
base=https://github.com/go-authn/authnd/releases/download/$version

curl -fsSLO "$base/authnd-linux-$arch"
curl -fsSLO "$base/SHA256SUMS"

sha256sum -c SHA256SUMS --ignore-missing                      # the bytes the release published
gh attestation verify "authnd-linux-$arch" --repo go-authn/authnd   # built by the release workflow, at that tag

Brechen Sie ab, wenn eine der beiden Prüfungen fehlschlägt. Der Release-Workflow lehnt es ab, ein Binary zu veröffentlichen, das nicht genau den Tag meldet, unter dem es veröffentlicht wird, daher ist die Version etwas, das sich vergleichen lässt:

$ authnd --version
authnd version v0.11.1

Nur bauen, was Sie wollen

Der Server ist immer enthalten; zwei Build-Tags lassen weg, woher Personen kommen können. -tags nosql entfernt die drei Datenbanktreiber (PostgreSQL über pgx, MySQL/MariaDB, SQLite über modernc.org/sqlite) und den Block users "sql"; -tags noldap entfernt den LDAP-Client und den Block users "ldap". Einer Konfiguration, die einen Block nennt, ohne den das Binary gebaut wurde, wird genau das gesagt – this binary was built without SQL support (-tags nosql) – statt dass der Block nicht existiere. Die Release-Binarys werden ohne Tags gebaut.

Das Konto

#Type Name   ID Description                          Home           Shell
u     authnd -  "authnd LDAP directory and Kerberos KDC" /var/lib/authnd -

Ein statisches Konto aus sysusers.d, nicht DynamicUser=. Die Dateien, die authnd liest – Passwortdateien, ein DSN, ein Keytab, ein TLS-Schlüssel –, sind Geheimnisse, die der Gruppe authnd vorab übergeben werden, und eine Passwortänderung schreibt in sie zurück. Eine dynamische UID existiert erst, wenn der Dienst startet, und eine Datei, die sie geschrieben hat, gehörte dann einer Nummer, die später jemand anderen bezeichnet.

Die beiden Dateien stammen aus dem Verzeichnis packaging/ des Release-Tags, derselben Version wie das Binary: Kopieren Sie dieses Verzeichnis neben das Binary, aus einem Checkout des Tags oder, für v0.11.1, von https://github.com/go-authn/authnd/tree/v0.11.1/packaging.

sudo install -m 0755 "authnd-linux-$arch" /usr/local/bin/authnd
sudo install -m 0644 packaging/sysusers.d/authnd.conf  /usr/lib/sysusers.d/authnd.conf
sudo systemd-sysusers /usr/lib/sysusers.d/authnd.conf
sudo install -m 0644 packaging/systemd/authnd.service /etc/systemd/system/authnd.service
sudo systemd-analyze verify /etc/systemd/system/authnd.service
sudo systemctl daemon-reload

Was die Unit gewährt, und warum

[Service]
Type=exec
ExecStart=/usr/local/bin/authnd --config /etc/authnd
Restart=on-failure
RestartSec=5s

User=authnd
Group=authnd
UMask=0077

AmbientCapabilities=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
NoNewPrivileges=yes

StateDirectory=authnd
StateDirectoryMode=0700

ProtectSystem=strict

Der Rest der Unit ist die übliche Härtung (ProtectHome, PrivateTmp, PrivateDevices, ProtectProc=invisible, die Kernel- und cgroup-Schutzmechanismen, MemoryDenyWriteExecute, SystemCallFilter=@system-service, RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX). Drei Dinge, die sie weglässt, sind Absicht:

IPAddressAllow=/IPAddressDeny= sind ebenfalls nicht gesetzt: Welche Netze ein Verzeichnis fragen dürfen, hat der Standort zu entscheiden, in einem Drop-in:

sudo systemctl edit authnd

[Service]
IPAddressDeny=any
IPAddressAllow=localhost 10.0.0.0/8

Die eine Capability ist für die privilegierten Ports da: LDAP 389, LDAPS 636 und Kerberos 88 über UDP und TCP. Ein PostgreSQL oder MariaDB auf derselben Maschine wird über seinen Socket erreicht, was ein schreibgeschütztes Dateisystem zulässt. Das Zustandsverzeichnis /var/lib/authnd ist für eine SQLite-Datenbank da; authnd selbst hält keinen Zustand – die Sperrzähler des zweiten Faktors liegen im Speicher und werden bei jedem Neustart zurückgesetzt.

Das Konfigurationsverzeichnis

sudo install -d -o root -g authnd -m 0750 /etc/authnd

Jede Datei darin root:authnd, Modus 0640. Geheimnisse gehören in Dateien, die über *_file-Schlüssel benannt werden, statt inline: Eine Datei hat Berechtigungen, eine Konfiguration, die jemand einfügt, nicht. Mit ProtectSystem=strict kann der Dienst nicht unter /etc schreiben, was für die Konfiguration richtig ist und für die Passwörter, die Personen selbst ändern, falsch – geben Sie diesen ein eigenes Verzeichnis:

sudo install -d -o authnd -g authnd -m 0700 /etc/authnd/passwords
sudo systemctl edit authnd

[Service]
ReadWritePaths=/etc/authnd/passwords

Warum dieses Verzeichnis und nicht die Datei, erklärt Ein Passwort ändern.

Ein relativer Pfad in der Konfiguration wird gegen das Verzeichnis aufgelöst, in dem der Prozess läuft, nicht gegen das der Konfigurationsdatei; die Unit läuft in /, also schreiben Sie Pfade absolut.

Vor jedem Start:

sudo -u authnd authnd check /etc/authnd
sudo systemctl enable --now authnd
journalctl -u authnd

check wird auf einer eigenen Seite beschrieben; es als authnd auszuführen, beweist auch, dass das Konto jede Datei lesen kann.

Upgrade, Rollback, Entfernen

Prüfen Sie die Konfiguration mit dem neuen Binary, bevor es das alte ersetzt, und behalten Sie das alte. Das neue Binary wird zuerst neben dem alten installiert: Das macht es ausführbar und legt es dorthin, wo das Konto authnd es ausführen kann.

sudo install -m 0755 "authnd-linux-$arch" /usr/local/bin/authnd.new
sudo -u authnd /usr/local/bin/authnd.new check /etc/authnd
sudo cp /usr/local/bin/authnd /usr/local/bin/authnd.previous
sudo mv /usr/local/bin/authnd.new /usr/local/bin/authnd
sudo systemctl restart authnd
authnd --version

Vergleichen Sie packaging/ am neuen Tag mit dem, was installiert ist (das von v0.11.1 ist das von v0.10.2, unverändert). Ein Rollback ist dieselbe Installation aus authnd.previous und ein Neustart.

Von v0.10.x auf v0.11.0 ist das check oben der Schritt, auf den es ankommt: Eine Konfiguration mit publish_nt_hash = true und ohne samba-Block wird dort abgelehnt statt erst beim Neustart, und die Zeilen nach seinen Tabellen sagen, wer kein posixAccount mehr ist und welche Gruppen keine posixGroups mehr sind (die Einträge).

Zum Entfernen:

sudo systemctl disable --now authnd
sudo rm /etc/systemd/system/authnd.service
sudo rm -r /etc/systemd/system/authnd.service.d     # if a drop-in was added
sudo systemctl daemon-reload
sudo rm /usr/local/bin/authnd /usr/local/bin/authnd.previous /usr/lib/sysusers.d/authnd.conf

/etc/authnd, /var/lib/authnd und das Konto authnd bleiben bestehen: Die ersten beiden enthalten die Zugangsdaten von Personen, und einer wiederverwendeten UID können die Dateien eines anderen Kontos zufallen. Entfernen Sie sie bewusst.