Gebruiker met sudo-rechten aanmaken en niet langer als root werken

Na de uitrol van een server bent u root, en root mag alles, zonder te vragen. Eén typefout raakt meteen het hele systeem, en root is de enige gebruikersnaam die elke aanvaller met zekerheid kent. Deze handleiding loopt de volledige route af: gebruiker aanmaken, in de juiste groep opnemen, de sudoers-configuratie uitbreiden, de publieke sleutel overzetten en pas als laatste root uitschakelen. Het beslissende deel staat vlak voor het einde: het bewijs dat u zichzelf niet hebt buitengesloten.

Referentiesystemen zijn Debian 13 (trixie), Debian 12 (bookworm), Ubuntu 24.04 LTS en Ubuntu 22.04 LTS. Waar RHEL-achtige systemen zoals AlmaLinux en Rocky Linux afwijken, staat dat erbij. De commando's zijn geschreven voor gebruik als root; als gewone gebruiker zet u voor elk commando een sudo. De korte versie staat in de checklist voor nieuwe rootservers, hier volgt de verdieping.

Voordat u iets wijzigt: de terugweg

Twee wijzigingen kunnen u hier de toegang kosten: de sudoers-configuratie en, helemaal aan het einde, de toestemming voor root om via SSH in te loggen. Een kapot sudoers-bestand neemt u de rechten af, een te vroeg uitgeschakelde rootlogin de reserveweg. Drie dingen regelt u daarom vooraf.

Een tweede sessie. Open een tweede terminalvenster met een actieve SSH-verbinding als root en sluit dat niet voordat alles is gecontroleerd. Een bestaande sessie overleeft zowel een herstart van de SSH-service als een foutief sudoers-bestand.

De weg langs SSH heen. Bij KVM-rootservers en dedicated servers van KernelHost opent u de VNC-console in het klantenpaneel. Die hangt aan de virtualisatielaag respectievelijk aan de aansluiting zelf, dus los van SSH, firewall en sudoers-bestand. Log daar één keer vooraf in: een nooduitgang die u pas in geval van nood uitprobeert, is er geen.

Een wachtwoord dat u kent. De console kent geen SSH-sleutels, daar logt u in met gebruikersnaam en wachtwoord of helemaal niet. Hier ontstaan de meeste buitensluitingen.

Vuistregel: de nooduitgang is een console, en een console kent alleen wachtwoorden. Voordat u de wachtwoordlogin uitschakelt, moet minstens één account een wachtwoord hebben dat u kent.

Inventarisatie: is sudo eigenlijk wel geïnstalleerd?

Op Ubuntu-serverimages is sudo aanwezig, op minimale Debian-images vaak niet. Drie regels maken de uitgangssituatie duidelijk:

command -v sudo || echo "sudo ontbreekt"
getent group sudo
awk -F: '$3 >= 1000 && $3 < 65534 {print $1, $3, $7}' /etc/passwd

De tweede regel toont de groep met haar leden, de derde alle reguliere accounts met UID en login-shell. Op images met cloud-init bestaat er vaak allang een account met sudo-rechten. Ontbreekt sudo, dan installeert u het alsnog:

apt-get update
apt-get install -y sudo
sudo -V | head -n 1

adduser of useradd: twee gereedschappen, twee resultaten

Wie useradd gebruikt maar adduser verwacht, krijgt een account zonder thuismap en met een shell waar hij niet op had gerekend.

Op Debian en Ubuntu is adduser de juiste keuze:

adduser --disabled-password --gecos "" kernel

--gecos "" slaat de vragen naar namen en telefoonnummers over, --disabled-password maakt het account zonder wachtwoord aan. Hier ligt de eerste valkuil: een account zonder wachtwoord kan niet inloggen op de VNC-console, en de wachtwoordvraag van sudo valt nooit met succes te beantwoorden. Stel daarom meteen daarna een wachtwoord in:

passwd kernel

Op RHEL-achtige systemen of in een script luidt de gelijkwaardige versie:

useradd -m -s /bin/bash kernel
passwd kernel

Controle:

getent passwd kernel
ls -ld /home/kernel
passwd -S kernel

getent passwd kernel toont de thuismap en de login-shell; staat daar /bin/sh of /usr/sbin/nologin, dan corrigeert usermod -s /bin/bash kernel dat. passwd -S kernel geeft in de tweede kolom de toestand van het wachtwoord: P voor bruikbaar, L voor geblokkeerd, NP voor geen wachtwoord. Na passwd kernel moet daar P staan.

De beheerdersgroep: sudo op Debian en Ubuntu, wheel op RHEL

Een wijdverbreid misverstand: de groep verleent de rechten niet uit zichzelf, maar alleen omdat er in /etc/sudoers een regel staat die naar haar verwijst. Op Debian en Ubuntu luidt die ongeveer %sudo ALL=(ALL:ALL) ALL, op RHEL-achtige systemen %wheel ALL=(ALL) ALL. Wat er bij u is vastgelegd, laat dit zien:

grep -E '^[^#]*%' /etc/sudoers

Op Ubuntu verschijnt daarnaast een regel voor de historische groep admin. Die groep bestaat op actuele images niet meer, de regel blijft zonder gevolg. De gebruiker voegt u zo toe:

usermod -aG sudo kernel

De -a is niet optioneel. Zonder die optie vervangt usermod -G alle secundaire groepen door de opgegeven lijst, zonder enige melding, en de schade valt vaak pas weken later op. De optie werkt uitsluitend samen met -G. Gelijkwaardig en minder foutgevoelig is gpasswd -a kernel sudo.

Controle:

id -nG kernel
getent group sudo
sudo -l -U kernel

De laatste regel zegt het meest, want die vraagt het aan sudo zelf. Verwacht wordt een blok dat eindigt op (ALL : ALL) ALL. Komt er in plaats daarvan User kernel is not allowed to run sudo on srv01., dan grijpt geen enkele regel.

Waarom de nieuwe groep pas bij de volgende login geldt

Groepslidmaatschappen krijgt een proces bij het inloggen mee en daarna niet meer. Daarom toont id -nG kernel als root de groep sudo, terwijl diezelfde uitvoer in de sessie van de gebruiker die groep niet bevat. Allebei klopt: het ene commando leest de gebruikersdatabase, het andere de lopende sessie. De oplossing is opnieuw inloggen, geen herstart. newgrp sudo werkt alleen in precies die shell waarin u het aanroept.

sudoers veilig bewerken: visudo en /etc/sudoers.d

Open /etc/sudoers nooit rechtstreeks met een editor. Eén syntaxfout maakt sudo voor alle gebruikers onbruikbaar, en als root al is uitgeschakeld, blijft alleen de console over. visudo vergrendelt het bestand tegen gelijktijdige wijzigingen en controleert de syntaxis vóór het opslaan. Vindt het een fout, dan vraagt het door:

>>> /etc/sudoers: syntax error near line 22 <<<
What now?
Options are:
  (e)dit sudoers file again
  e(x)it without saving changes to sudoers file
  (Q)uit and save changes to sudoers file (DANGER!)

Het juiste antwoord is e; de hoofdletter Q slaat het foutieve bestand op. Welke editor visudo start, bepaalt op Debian en Ubuntu het alternatives-systeem: blijvend via update-alternatives --config editor, eenmalig via EDITOR=nano visudo.

Voor eigen regels raakt u /etc/sudoers echter helemaal niet aan. Aan het einde van het bestand haalt één regel een hele map binnen, afhankelijk van de leeftijd van het systeem als @includedir /etc/sudoers.d of als #includedir /etc/sudoers.d. Het hekje ziet eruit als een commentaarteken, maar is het niet. Ook dat bestand maakt u met visudo aan:

visudo -f /etc/sudoers.d/10-kernel

De twee regels waarop bestanden in die map stuklopen

De bestandsnaam mag geen punt bevatten en niet op een tilde eindigen. sudo slaat zulke bestanden stilzwijgend over, zodat back-ups niet per ongeluk rechten uitdelen. 10-kernel.conf wordt daarom nooit gelezen, en wel zonder enige melding. Juist is 10-kernel.

Het bestand moet eigendom van root zijn en mag voor de groep en voor overige gebruikers niet schrijfbaar zijn, verwacht wordt modus 0440.

chown root:root /etc/sudoers.d/10-kernel
chmod 0440 /etc/sudoers.d/10-kernel
visudo -c

visudo -c controleert alle ingelezen bestanden en geeft voor elk daarvan één regel:

/etc/sudoers: parsed OK
/etc/sudoers.d/10-kernel: parsed OK

Dat is tegelijk de beste controle op de eerste regel: staat uw bestand er niet tussen, dan wordt het niet gelezen, en dan is een punt in de bestandsnaam vrijwel altijd de oorzaak. Bij verkeerde rechten meldt visudo in plaats daarvan /etc/sudoers.d/10-kernel: bad permissions, should be mode 0440.

NOPASSWD: wat het werkelijk kost

Vroeg of laat stuit iedereen op deze regel:

kernel ALL=(ALL) NOPASSWD: ALL

Die is gevaarlijker dan hij eruitziet. De wachtwoordvraag is de laatste horde tussen "iemand heeft een shell als kernel" en "iemand is root". Wie via een kwetsbare webapplicatie, een gekopieerde private sleutel of een onbeheerde sessie bij het account komt, is met deze regel zonder verdere stap root. Met NOPASSWD: ALL krimpt de veiligheidswinst ten opzichte van rechtstreeks als root inloggen dus tot één gebruikersnaam die een aanvaller niet kent.

Terecht is NOPASSWD daar waar niemand kan typen: Ansible-runs, back-upscripts, deployment-pipelines. Maar dan strak afgebakend en niet voor de mens achter het terminal:

deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx

Drie valkuilen bij zulke regels:

• Absolute paden zijn verplicht. Een programmanaam zonder pad past op niets.
• Zonder vermelde argumenten zijn alle argumenten toegestaan. deploy ALL=(root) NOPASSWD: /usr/bin/systemctl staat elke systemctl-aanroep toe. Pas wanneer u de argumenten mee opschrijft, moet de commandoregel precies zo luiden. Mag er helemaal geen argument bij, hang er dan een leeg argumentenpaar aan, bijvoorbeeld /usr/bin/id "".
• Jokertekens zijn zelden zo strak als ze lijken. /usr/bin/* staat elk programma in die map toe en komt in de praktijk neer op volledige roottoegang.

De belangrijkste vraag bij elke beperkte regel: kan het toegestane commando een ander programma starten of een shell openen? Editors, pakketbeheerders, archiefgereedschappen en interpreters kunnen dat, en een regel die een editor via sudo toestaat, staat in de praktijk alles toe.

Het betere compromis is de onthoudtijd: sudo bewaart een geslaagde invoer standaard 15 minuten, apart per terminal. Aanpassen kan dat onder /etc/sudoers.d/:

Defaults:kernel timestamp_timeout=5

sudo -k gooit die aantekening onmiddellijk weg, sudo -v vernieuwt hem zonder een commando uit te voeren.

De publieke sleutel bij de nieuwe gebruiker krijgen

Zolang de wachtwoordlogin via SSH actief is, gaat dat vanaf uw werkstation het makkelijkst met ssh-copy-id kernel@203.0.113.10. Is die al uitgeschakeld, dan mislukt het met Permission denied (publickey). Dan loopt de weg via de nog openstaande rootsessie.

De voor de hand liggende greep is daar cp -r /root/.ssh /home/kernel/.ssh, en die is fout: de bestanden zijn daarna eigendom van root, de SSH-server wijst ze af, en het commando neemt een eventuele private sleutel van root mee, die op een tweede account niets te zoeken heeft. Zet in plaats daarvan gericht alleen de publieke sleutels over:

install -d -m 700 -o kernel -g kernel /home/kernel/.ssh
install -m 600 -o kernel -g kernel /root/.ssh/authorized_keys /home/kernel/.ssh/authorized_keys

install zet rechten en eigenaar in één keer goed, zodat er geen vergeten chown achterblijft. Bestaat /root/.ssh/authorized_keys niet, maak het doelbestand dan leeg aan en zet de sleutel er met een editor in:

install -m 600 -o kernel -g kernel /dev/null /home/kernel/.ssh/authorized_keys

Controle:

ls -ld /home/kernel /home/kernel/.ssh
ls -l /home/kernel/.ssh/authorized_keys
ssh-keygen -l -f /home/kernel/.ssh/authorized_keys

De laatste regel geeft van elke opgeslagen sleutel de vingerafdruk. Vergelijk die met ssh-keygen -l -f ~/.ssh/id_ed25519.pub op uw werkstation. Zo weet u al vóór de eerste inlogpoging dat de juiste sleutel is aangekomen.

Een detail dat uren kan kosten: met StrictModes yes controleert de SSH-server niet alleen .ssh en authorized_keys, maar ook de thuismap. Is die voor de groep of voor overige gebruikers schrijfbaar, dan weigert hij de sleutellogin, en de client meldt alleen Permission denied (publickey). Welke rechten uw systeem uitdeelt, staat in /etc/adduser.conf onder DIR_MODE. Alles over de sleutellogin zelf staat in SSH beveiligen en inloggen met sleutel instellen.

De test voordat u root uitschakelt

Vier controles, en pas als ze allemaal kloppen, raakt u de SSH-configuratie aan. De oude rootsessie blijft openstaan.

Ten eerste: een nieuwe SSH-sessie als de nieuwe gebruiker, in een net geopend venster, niet in de bestaande verbinding.

ssh kernel@203.0.113.10

Verwacht wordt een shell zonder wachtwoordvraag. Wordt u naar een wachtwoord gevraagd, dan heeft de sleutel niet gewerkt; ssh -v laat zien welke sleutels de client eigenlijk aanbiedt. Hapert het opbouwen van de verbinding al, dan helpt Verbinding maken met uw server via SSH verder.

Ten tweede: sudo in precies die nieuwe sessie.

id
sudo -v
sudo id

id moet de groep sudo noemen, sudo id moet met uid=0(root) beginnen. Een sudo -l -U kernel vanuit de rootsessie vervangt deze test niet: dat toont wat sudo zou toestaan, niet of het inloggen van de gebruiker werkt.

Ten derde: de console. Log via de VNC-console in het klantenpaneel in als kernel met gebruikersnaam en wachtwoord en voer daar sudo -i uit. Deze test is de belangrijkste van de vier, omdat de console de nooduitgang is en alleen wachtwoorden kent.

Ten vierde: de toestand van de wachtwoorden.

passwd -S root
passwd -S kernel

Bij minstens één van beide accounts moet in de tweede kolom een P staan. Twee geblokkeerde accounts plus een foutieve SSH-configuratie leveren een systeem op dat alleen nog via een reddingssysteem bereikbaar is.

root uitschakelen, maar dan goed

Drie maatregelen worden vaak op één hoop gegooid, terwijl hun gevolgen sterk uiteenlopen.

Voor de meeste servers is prohibit-password de juiste keuze: root blijft als noodgreep via een sleutel bereikbaar, en het raden van wachtwoorden is toch kansloos. De instelling hoort in een eigen bestand onder /etc/ssh/sshd_config.d/, en vóór elke herstart van de service staat de syntaxcontrole:

sshd -t && systemctl restart ssh
sshd -T | grep -i permitrootlogin

passwd -l root is de hardere variant en alleen verdedigbaar wanneer de derde test hierboven is gelukt. Het commando blokkeert uitsluitend de wachtwoordlogin: een opgeslagen SSH-sleutel blijft werken, sudo -i eveneens.

Wat af te raden is: root de login-shell afnemen, bijvoorbeeld met usermod -s /usr/sbin/nologin root. Dat blokkeert niet alleen het inloggen, maar ook sudo -i en de noodshell tijdens het opstarten.

Veelvoorkomende fouten en oplossingen

kernel is not in the sudoers file.: de gebruiker zit in geen enkele groep waarvoor een regel bestaat, of de sessie is ouder dan de groepswijziging. Controleer id -nG kernel als root en getent group sudo, en log daarna opnieuw in. Oudere versies hangen er nog een zin achter over een gemeld incident.

sudo: 3 incorrect password attempts, hoewel u correct hebt getypt: het account heeft helemaal geen wachtwoord, meestal omdat het met --disabled-password is aangemaakt. passwd -S kernel toont dan L of NP, en passwd kernel lost het op. Bovendien vraagt sudo naar het wachtwoord van de aanroepende gebruiker, niet naar dat van root.

sudo: no tty present and no askpass program specified: er is geen terminal waarop sudo zou kunnen doorvragen. Typisch bij ssh server 'sudo commando' en in cronjobs. Bij SSH helpt ssh -t, in een cronjob hoort de regel in de crontab van root.

sudo: /etc/sudoers.d/10-kernel is mode 0644, should be 0440: verkeerde rechten op het regelbestand. chmod 0440 verhelpt het; tot dan werkt de regel niet.

/etc/sudoers.d/10-kernel: bad permissions, should be mode 0440: dezelfde oorzaak, gemeld door visudo -c. Gebruik dat commando na elke wijziging.

Het regelbestand komt in de uitvoer van visudo -c helemaal niet voor: de bestandsnaam bevat een punt of eindigt op een tilde. Hernoem 10-kernel.conf naar 10-kernel.

usermod: group 'sudo' does not exist: u werkt op een RHEL-achtig systeem. Daar heet de beheerdersgroep wheel, wat getent group wheel bevestigt.

Permission denied (publickey) bij de nieuwe gebruiker, terwijl root nog gewoon kan inloggen: bijna altijd de rechten. /home/kernel/.ssh moet 700 zijn, authorized_keys 600, beide moeten eigendom van de gebruiker zijn, en de thuismap mag voor de groep en voor overige gebruikers niet schrijfbaar zijn. De oorzaak staat in het logboek:

journalctl -t sshd -n 50 --no-pager

Gezocht wordt een regel die begint met Authentication refused: bad ownership or modes for directory en de betreffende map noemt.

sudo: unable to resolve host srv01: Name or service not known: de hostnaam ontbreekt in /etc/hosts. sudo werkt alsnog, maar merkbaar vertraagd. De passende regel staat in de rootserver-checklist.

En als het account weer moet verdwijnen: gpasswd -d kernel sudo neemt alleen de rechten af, deluser --remove-home kernel respectievelijk userdel -r kernel verwijdert het inclusief thuismap.

Verschillen tussen de distributies in één oogopslag

Korte samenvatting

1. Terugweg regelen: een tweede rootsessie openhouden, de VNC-console in het klantenpaneel één keer uitproberen, het rootwachtwoord kennen.
2. apt-get install -y sudo, als command -v sudo niets oplevert.
3. adduser --disabled-password --gecos "" kernel, daarna passwd kernel, zodat de console bruikbaar blijft.
4. usermod -aG sudo kernel, op RHEL-achtige systemen wheel. De -a is verplicht.
5. Publieke sleutel met install overzetten: map 700, bestand 600, eigenaar de nieuwe gebruiker.
6. Eigen regels alleen via visudo -f in /etc/sudoers.d/, bestandsnaam zonder punt, modus 0440, daarna visudo -c.
7. Controleren: sudo -l -U kernel, een nieuwe SSH-sessie, sudo id, inloggen op de console met wachtwoord.
8. Pas daarna PermitRootLogin aanraken.

Een gebruiker met sudo-rechten haalt zowel de onbedoelde totale schade als de bekendste gebruikersnaam bij u weg. Tegen open poorten helpt de UFW-firewall, tegen aanvallen die de aansluiting verzadigen alleen filtering in het netwerk ervoor, bij KernelHost in het maincubes-datacenter in Frankfurt am Main. Op de server zelf blijft uw taak de kleinste en tegelijk de meest effectieve: dat precies één account precies de rechten heeft die het nodig heeft.