Sudo-rechten en authorized_keys fleet-breed inventariseren met één script

De vraag komt altijd op het slechtste moment: een collega vertrekt, een laptop wordt gestolen, een auditor vraagt "wie heeft root op de databaseserver?", en het antwoord is een rondje ssh over alle hosts terwijl iedereen wacht. Het probleem is niet dat de informatie ontbreekt; ze staat in /etc/passwd, /etc/sudoers en dertig authorized_keys-bestanden. Het probleem is dat niemand ze op één plek heeft, met een datum, in een vorm die je kunt vergelijken met gisteren.

Stap 1: wat er op één host staat

# Interactieve accounts (uid ≥ 1000, echte shell) + root
awk -F: '($3>=1000 || $1=="root") && $7!~/nologin|false/ {print $1, $3, $6, $7}' /etc/passwd

# Wie mag sudo? Via groep...
getent group sudo admin wheel 2>/dev/null
# ...en via expliciete regels (zonder commentaar en Defaults)
sudo grep -rhvE '^\s*(#|@|Defaults|$)' /etc/sudoers /etc/sudoers.d/ 2>/dev/null

# Welke keys zijn geautoriseerd, waar, en van wie?
for d in /root /home/*; do
  f="$d/.ssh/authorized_keys"; [ -f "$f" ] || continue
  echo "== $f"; sudo ssh-keygen -lf "$f" 2>/dev/null       # bits, fingerprint, comment, type
done

Twee dingen die ssh-keygen -lf je meteen laat zien: keys van 1024-bit RSA of van het type ssh-dss (allebei sinds jaren verboden in OpenSSH-defaults, maar nog verrassend vaak aanwezig), en keys zonder comment, waarvan niemand weet van wie ze zijn.

Vergeet de plaatsen buiten authorized_keys niet:

# Alternatieve locaties uit sshd_config
sshd -T | grep -iE '^(authorizedkeysfile|authorizedkeyscommand|trustedusercakeys) '
# SSH-certificaten (CA): dan zit de autorisatie bij de CA, niet in een bestand
# Systeemaccounts met een shell én een key (deploy-users, backup-users)
awk -F: '$3<1000 && $7!~/nologin|false/ {print $1}' /etc/passwd

Stap 2: één script, één tsv per host

Het script levert drie soorten regels, user, sudo, key, in een vorm die je kunt sorteren, diffen en in een spreadsheet plakken.

sudo tee /usr/local/sbin/access-inventory.sh >/dev/null <<'EOF'
#!/usr/bin/env bash
# Output: host<TAB>type<TAB>subject<TAB>detail<TAB>extra
H=$(hostname -s)

# Accounts met een shell (incl. systeemaccounts met shell: deploy-users zijn óók toegang)
awk -F: -v h="$H" '$7!~/nologin|false|sync|halt|shutdown/ {
  printf "%s\tuser\t%s\tuid=%s\tshell=%s\n", h, $1, $3, $7 }' /etc/passwd

# Laatste SSH-login per account, uit de journal (lastlog en wtmp zijn op Ubuntu ≥ 24.04 niet meer betrouwbaar/aanwezig)
journalctl -u ssh --since "365 days ago" --no-pager -o short-iso 2>/dev/null \
  | grep -E 'Accepted (publickey|password)' | awk '{print $7, $1}' | sort -k1,1 -k2,2r | awk '!seen[$1]++' \
  | awk -v h="$H" '{printf "%s\tlastlogin\t%s\t%s\t\n", h, $1, $2}'

# Sudo via groepslidmaatschap
for g in sudo admin wheel; do
  getent group "$g" 2>/dev/null | awk -F: -v h="$H" -v g="$g" '$4!="" {n=split($4,u,","); for(i=1;i<=n;i++) printf "%s\tsudo\t%s\tgroup=%s\t\n", h, u[i], g}'
done
# Sudo via expliciete regels (zonder commentaar, Defaults en @include-directieven)
grep -rhvE '^\s*(#|@|Defaults|$)' /etc/sudoers /etc/sudoers.d/ 2>/dev/null \
  | awk -v h="$H" '{ subj=$1; $1=""; sub(/^ /,""); printf "%s\tsudo\t%s\trule=%s\t\n", h, subj, $0 }'

# Keys: één regel per geautoriseerde key, met fingerprint, type en comment
for d in /root /home/*; do
  f="$d/.ssh/authorized_keys"; [ -f "$f" ] || continue
  u=$(basename "$d"); [ "$d" = /root ] && u=root
  ssh-keygen -lf "$f" 2>/dev/null | awk -v h="$H" -v u="$u" '{ fp=$2; type=$NF; gsub(/[()]/,"",type); $1=""; $2=""; $NF=""; sub(/^ +/,""); sub(/ +$/,""); printf "%s\tkey\t%s\t%s\t%s %s\n", h, u, fp, type, $0 }'
done
EOF
sudo chmod 0755 /usr/local/sbin/access-inventory.sh
sudo /usr/local/sbin/access-inventory.sh | column -t -s $'\t' | head -30
# web-01  user       jeroen   uid=1001                         shell=/bin/bash
# web-01  sudo       jeroen   group=sudo
# web-01  sudo       deploy   rule=ALL=(root) NOPASSWD: /usr/bin/systemctl restart webapp
# web-01  key        jeroen   SHA256:7Kq…                      ED25519 jeroen@laptop-2024
# web-01  key        deploy   SHA256:aa1…                      RSA ci-runner
# web-01  key        deploy   SHA256:9f3…                      RSA (geen comment)   ← van wie?

Stap 3: fleet-breed verzamelen en per persoon draaien

Vanaf een beheer-host, over een hosts.txt:

D=/srv/inventory/access; mkdir -p "$D"
while read -r h; do
  ssh -o ConnectTimeout=5 -o BatchMode=yes "$h" sudo /usr/local/sbin/access-inventory.sh 2>/dev/null \
    || echo "$h	error	-	unreachable	" 
done < hosts.txt > "$D/$(date +%F).tsv"

# Draai de vraag om: per KEY, op welke hosts en onder welk account staat hij?
awk -F'\t' '$2=="key" {print $4, $5, "→", $1":"$3}' "$D/$(date +%F).tsv" | sort | uniq
# SHA256:7Kq… ED25519 jeroen@laptop-2024 → db-01:jeroen
# SHA256:7Kq… ED25519 jeroen@laptop-2024 → web-01:jeroen
# SHA256:9f3… RSA (geen comment)         → web-01:deploy   ← één key, geen eigenaar: opruimen of labelen
# SHA256:aa1… RSA ci-runner              → web-01:deploy, web-02:deploy, db-01:root   ← CI-key op root van de database?

# Per persoon: op welke hosts heeft hij sudo?
awk -F'\t' '$2=="sudo" {print $3, "→", $1, "("$4")"}' "$D/$(date +%F).tsv" | sort

Die omgekeerde lijst, per key, waar staat hij, is waar de verrassingen zitten: de CI-key op de root-account van de database, de key van een ex-collega onder een gedeeld deploy-account, en de key zonder comment die niemand durft te verwijderen.

Stap 4: dagelijkse diff, meld wat erbij kwam

Een nieuwe key of sudo-regel is altijd óf een bewuste wijziging (dan staat er een ticket tegenover) óf een incident. In beide gevallen wil je hem dezelfde dag zien.

sudo tee /usr/local/sbin/access-diff.sh >/dev/null <<'EOF'
#!/usr/bin/env bash
NTFY="https://ntfy.example.be/security"
D=/srv/inventory/access
today=$D/$(date +%F).tsv
prev=$(ls -1 "$D"/*.tsv 2>/dev/null | grep -v "$today" | tail -1)
[ -f "$prev" ] || exit 0
# Alleen keys en sudo-regels vergelijken (lastlogin verandert elke dag)
added=$(comm -13 <(grep -E $'\t(key|sudo|user)\t' "$prev" | sort) <(grep -E $'\t(key|sudo|user)\t' "$today" | sort))
removed=$(comm -23 <(grep -E $'\t(key|sudo|user)\t' "$prev" | sort) <(grep -E $'\t(key|sudo|user)\t' "$today" | sort))
if [ -n "$added$removed" ]; then
  { [ -n "$added" ] && { echo "ADDED:"; echo "$added"; }; [ -n "$removed" ] && { echo "REMOVED:"; echo "$removed"; }; } \
  | curl -s -H "Title: access change (fleet)" -H "Priority: high" --data-binary @- "$NTFY" >/dev/null
fi
EOF
sudo chmod 0755 /usr/local/sbin/access-diff.sh
echo '15 6 * * * root /usr/local/sbin/access-collect.sh && /usr/local/sbin/access-diff.sh' | sudo tee /etc/cron.d/access-inventory

(Zet de while read-loop uit stap 3 in /usr/local/sbin/access-collect.sh.) Het resultaat: elke ochtend een bericht als er iets veranderde, en anders stilte. Een ADDED … key … root …-regel zonder ticket is een incident, geen to-do.

Stap 5: opruimen zonder iemand buiten te sluiten

De lijst is één ding; keys weghalen is het spannende deel. Werk in deze volgorde:

1. Comment toevoegen aan elke key waarvan je de eigenaar kent (ssh-keygen kan dat niet; bewerk het bestand: het derde veld is vrij).
2. Keys zonder eigenaar eerst 30 dagen loggen: LogLevel VERBOSE in sshd_config logt de fingerprint bij elke login (Accepted publickey for deploy … SHA256:9f3…). Wordt hij niet gebruikt: weg.
3. Gedeelde accounts (deploy met acht keys) omzetten naar persoonlijke accounts + sudo-regel, of naar SSH-certificaten met korte TTL. Dan is elke login herleidbaar tot een persoon.
4. 1024-bit RSA en DSA vervangen door ed25519: die accepteert OpenSSH 9+ standaard niet meer, dus ze zijn toch al kapot op de nieuwste hosts.

Valkuilen

• AuthorizedKeysCommand. Als sshd keys uit een IdP of een centrale bron haalt, is authorized_keys leeg en je inventaris ook. sshd -T vertelt het (stap 1); dan inventariseer je aan de bron.
• Keys in ~/.ssh/authorized_keys2. Verouderd maar op oude hosts nog gelezen als het in AuthorizedKeysFile staat. Zelfde check.
• Sudo via %group uit LDAP/SSSD. getent group sudo toont die leden alleen als NSS ze oplost; op hosts met SSSD kan dat traag zijn of leeg bij een storing. Cache-loze run in het onderhoudsvenster.
• NOPASSWD-regels op commando's met argumenten. NOPASSWD: /usr/bin/systemctl (zonder argumenten) betekent elk systemctl-commando, inclusief systemctl --now disable auditd. Beperk tot het exacte commando met argumenten.
• sudo -l per gebruiker vergeten. De sudoers-regels zeggen wat mag; sudo -l -U jeroen zegt wat effectief mag na alle groepen en aliassen. Voor de review is dat de betere bron.

Wat je hiermee nog niet hebt

• De koppeling met personeel. De tsv zegt "jeroen heeft sudo op 12 hosts", niet of Jeroen nog in dienst is. Dat is de kwartaal-review, met de HR-lijst ernaast.
• Historie per key. Wanneer verscheen deze key, wie zette hem erop (welke sudo-sessie), en wanneer werd hij voor het laatst gebruikt? Drie vragen, drie bronnen.
• Bewijs. Een auditor wil de inventaris ondertekend en onveranderbaar, en het bewijs dat de diff-alert werkt (een testlog).

Zo doet monsys het

De monsys-agent inventariseert per host de accounts, sudo-rechten (effectief, na groepen en aliassen), authorized_keys per gebruiker met fingerprint en comment, en de laatste login: als onderdeel van de gewone inventaris. De hub toont het fleet-breed per persoon en per key, meldt een nieuwe key of sudo-regel als drift-detectie, en genereert elk kwartaal een ondertekend access-review-rapport (ISO 27001 A.5.18) met alle accounts, hun rechten en hun laatste activiteit, inclusief de SSO-configuratie zonder secrets.

FAQ

Hoe zie ik van wie een SSH-key is als er geen comment bij staat?

Zet LogLevel VERBOSE in sshd_config; vanaf dan logt elke login de fingerprint. Na een paar weken weet je welke keys gebruikt worden en vanaf welk IP. Keys die nooit gebruikt worden, kun je verwijderen; keys die wel gebruikt worden, vraag je na bij de gebruiker van dat IP.

Wat is het verschil tussen de sudo-groep en een sudoers-regel?

Lidmaatschap van sudo (Ubuntu) of wheel (RHEL) geeft ALL=(ALL:ALL) ALL, alles. Een expliciete regel in /etc/sudoers.d/ kan beperkt zijn tot één commando. Voor de review tellen beide; sudo -l -U <user> toont het gecombineerde resultaat.

Hoe vaak moet ik dit draaien?

De inventaris dagelijks (automatisch, met de diff-alert), de menselijke review elk kwartaal. NIS2 en ISO 27001 vragen niet om een frequentie in dagen, maar om aantoonbaarheid dat toegang periodiek wordt herzien, en een kwartaal is wat auditors verwachten.