Installer authnd

Le dépôt contient les deux fichiers dont un hôte systemd a besoin : packaging/sysusers.d/authnd.conf (le compte) et packaging/systemd/authnd.service (l’unité). Cette page explique les deux et les étapes qui les entourent. Les services versionnés de go-pkgx sont censés le faire pour vous plus tard ; ils n’existent pas encore.

Le binaire de la version

Chaque étiquette publie authnd-<os>-<arch> pour linux, darwin et windows sur amd64 et arm64 (.exe sous windows), compilé avec CGO_ENABLED=0, un manifeste SHA256SUMS, et une attestation de provenance de compilation pour chaque binaire.

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

Arrêtez-vous si l’une des deux vérifications échoue. Le workflow de publication refuse de publier un binaire qui n’annonce pas exactement l’étiquette sous laquelle il est publié : la version est donc quelque chose à comparer :

$ authnd --version
authnd version v0.11.1

Ne compiler que ce que vous voulez

Le serveur est toujours là ; deux étiquettes de compilation retirent des provenances possibles des personnes. -tags nosql retire les trois pilotes de base de données (PostgreSQL via pgx, MySQL/MariaDB, SQLite via modernc.org/sqlite) et le bloc users "sql" ; -tags noldap retire le client LDAP et le bloc users "ldap". Une configuration qui nomme un bloc sans lequel le binaire a été compilé se le voit dire — this binary was built without SQL support (-tags nosql) — plutôt que de s’entendre dire que le bloc n’existe pas. Les binaires des versions sont compilés sans étiquettes.

Le compte

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

Un compte statique issu de sysusers.d, pas DynamicUser=. Les fichiers qu’authnd lit — fichiers de mots de passe, un DSN, un keytab, une clé TLS — sont des secrets confiés au groupe authnd à l’avance, et un changement de mot de passe y réécrit. Un uid dynamique n’existe pas avant que le service démarre, et un fichier qu’il a écrit appartiendrait à un numéro qui désignera plus tard quelqu’un d’autre.

Les deux fichiers viennent du répertoire packaging/ de l’étiquette de la version, la même version que le binaire : copiez ce répertoire à côté du binaire, depuis une extraction de l’étiquette ou, pour v0.11.1, depuis 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

Ce que l’unité accorde, et pourquoi

[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

Le reste de l’unité est le durcissement habituel (ProtectHome, PrivateTmp, PrivateDevices, ProtectProc=invisible, les protections du noyau et des cgroups, MemoryDenyWriteExecute, SystemCallFilter=@system-service, RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX). Trois choses qu’elle omet le sont délibérément :

IPAddressAllow=/IPAddressDeny= ne sont pas définis non plus : quels réseaux peuvent interroger un annuaire, c’est au site de le dire, dans un drop-in :

sudo systemctl edit authnd

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

L’unique capacité sert aux ports privilégiés : LDAP 389, LDAPS 636, et Kerberos 88 en UDP et TCP. Un PostgreSQL ou un MariaDB sur la même machine est joint par sa socket, ce qu’un système de fichiers en lecture seule permet. Le répertoire d’état, /var/lib/authnd, est là pour une base de données SQLite ; authnd ne garde aucun état propre — les compteurs de verrouillage du second facteur vivent en mémoire et sont remis à zéro à chaque redémarrage.

Le répertoire de configuration

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

Chaque fichier qu’il contient est root:authnd, en mode 0640. Les secrets vont dans des fichiers nommés par des clés *_file plutôt qu’en ligne : un fichier a des permissions, une configuration que quelqu’un colle n’en a pas. Avec ProtectSystem=strict, le service ne peut pas écrire sous /etc, ce qui est juste pour la configuration et faux pour les mots de passe que les personnes changent elles-mêmes — donnez-leur un répertoire à part :

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

[Service]
ReadWritePaths=/etc/authnd/passwords

Pourquoi ce répertoire et pas le fichier est expliqué dans changer un mot de passe.

Un chemin relatif dans la configuration est résolu par rapport au répertoire dans lequel le processus s’exécute, pas à celui du fichier de configuration ; l’unité s’exécute depuis /, donc écrivez des chemins absolus.

Avant chaque démarrage :

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

check est décrit sur sa propre page ; le lancer sous authnd prouve aussi que le compte peut lire chaque fichier.

Mettre à niveau, revenir en arrière, désinstaller

Vérifiez la configuration avec le nouveau binaire avant qu’il ne remplace l’ancien, et gardez l’ancien. Le nouveau binaire est d’abord installé à côté de l’ancien : cela le rend exécutable, et le place là où le compte authnd peut le lancer.

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

Comparez packaging/ à la nouvelle étiquette avec ce qui est installé (celui de la v0.11.1 est celui de la v0.10.2, inchangé). Revenir en arrière, c’est la même installation depuis authnd.previous, et un redémarrage.

De la v0.10.x à la v0.11.0, le check ci-dessus est l’étape qui compte : une configuration avec publish_nt_hash = true et sans bloc samba y est refusée plutôt qu’au redémarrage, et les lignes après ses tableaux disent qui n’est plus un posixAccount et quels groupes ne sont plus des posixGroup (les entrées).

Pour le désinstaller :

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 et le compte authnd sont laissés en place : les deux premiers contiennent les identifiants des personnes, et un uid réutilisé peut se voir attribuer les fichiers de quelqu’un d’autre. Supprimez-les délibérément.