Gå direkte til indholdet

Cookieindstillinger

Vælg for hver type, hvilke cookies du tillader. Du kan altid ændre dit valg via Cookieindstillinger nederst på hver side. Privatlivspolitik

Nødvendige

Altid slået til

Nødvendige for at logge ind, gemme din kurv og huske dine valg. De er altid slået til.

Hvilke cookies?
  • weboke_sessie, weboke_klant, weboke_remember: din session og at forblive logget ind
  • weboke_basket: din kurv
  • wkBtwIncl: vise priser med eller uden moms
  • wok_cookies: dit cookievalg, 12 måneder

Måler, hvilken annonce der fører til et besøg eller en bestilling, så vi ikke betaler for annoncer, der ikke virker.

Hvilke cookies?
  • Google Ads via Google Tag Manager (_gcl_au, _gcl_aw), op til 90 dage
  • OpenAI Ads, annoncer i ChatGPT
  • wok_aff: hvilken partner der henviste dig til os (affiliateprogram), 60 dage

4,6

Land og sprog

Hvert land har sin egen side med landets priser og moms.

Se

sudo og minimale rettigheder

Modul 3: Brugere, rettigheder og sudo · Læsetid: 11 minutter

Læringsmål: Efter denne lektion kan du arbejde som almindelig bruger med sudo, tilføje en administrator sikkert, ændre sudo-indstillingerne uden at låse dig selv ude og forklare, hvorfor minimale rettigheder beskytter din server.

Centrale begreber: sudo, gruppen sudo, gruppen wheel, /etc/sudoers, /etc/sudoers.d, visudo, NOPASSWD, sudo -l, lås root, sudo-log, minimale rettigheder (least privilege), tjenestebruger

Hvorfor ikke bare arbejde som root?

Efter installationen logger du ofte ind som root. Det er nemt: alt er tilladt. Men det er netop problemet:

  • Én tastefejl er nok. rm -rf / home/anna/oud (læg mærke til mellemrummet efter den første skråstreg) sletter hele din server, hvis du er root. Som almindelig bruger får du en fejlmeddelelse.
  • Alt kører som root. Et script, du kopierer fra internettet, et program, du tester: alt får fulde rettigheder.
  • Intet spor. Arbejder tre personer som root, ved ingen bagefter, hvem der gjorde hvad.
  • Root er det navn, alle angribere prøver. Login som root slår du helst helt fra (lektion 2.2), men det kan du først, når du har en anden vej til administratorrettigheder.

Den anden vej er sudo: du logger ind som dig selv og skriver kun sudo foran en kommando, der kræver administratorrettigheder.

anna@web1:~$ apt update
E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied)
anna@web1:~$ sudo apt update
[sudo] password for anna:
Hit:1 http://deb.debian.org/debian trixie InRelease
...

(Siden version 25.10 bruger Ubuntu som standard sudo-rs, en ny implementering af sudo. Til alt i denne lektion virker den på samme måde.)

sudo beder om din adgangskode, ikke roots. Derefter husker den den som standard i et kvarter, så du ikke skal indtaste den ved hver kommando. Hver kommando, du kører med sudo, bliver logget.

Opret en administrator

På Debian og Ubuntu må alle i gruppen sudo gøre alt via sudo. Det står i /etc/sudoers:

%sudo   ALL=(ALL:ALL) ALL

Læs det sådan: medlemmer af gruppen sudo (%) må på alle maskiner (ALL) køre enhver kommando (ALL) som enhver bruger og gruppe ((ALL:ALL)).

Du tilføjer altså en administrator i to trin, som root:

root@web1:~# adduser anna
root@web1:~# adduser anna sudo

Læg derefter Annas offentlige nøgle i /home/anna/.ssh/authorized_keys med den rigtige ejer og de rigtige rettigheder:

root@web1:~# mkdir -p /home/anna/.ssh
root@web1:~# cp /root/.ssh/authorized_keys /home/anna/.ssh/
root@web1:~# chown -R anna:anna /home/anna/.ssh
root@web1:~# chmod 700 /home/anna/.ssh
root@web1:~# chmod 600 /home/anna/.ssh/authorized_keys

Glem ikke chown: kopierer root filen, ejes den af root, og så kan Anna ikke logge ind med sin nøgle.

Test nu i et andet vindue, mens din root-session forbliver åben:

anna@laptop:~$ ssh anna@192.0.2.10
anna@web1:~$ sudo -l
[sudo] password for anna:
User anna may run the following commands on web1:
    (ALL : ALL) ALL
anna@web1:~$ sudo whoami
root

Først når det virker, sætter du PermitRootLogin no i dine SSH-indstillinger (lektion 2.2). Fra da af logger du altid ind som Anna.

En ting at huske: Anna skal nu bruge en adgangskode til sudo. Gem den i din adgangskodeadministrator. Login sker med nøglen, sudo med adgangskoden: to forskellige ting, som en indtrænger skal have begge af.

Ændr sudo-indstillinger: altid med visudo

En fejl i /etc/sudoers kan betyde, at sudo slet ikke virker mere. Kan root heller ikke logge ind, sidder du fast. Derfor redigerer du aldrig sudo-indstillinger med en almindelig editor, men med visudo. Den åbner en midlertidig kopi og kontrollerer indholdet, før den gemmer:

root@web1:~# visudo -f /etc/sudoers.d/backup

Ligesom ved SSH er det bedre at bruge en egen fil i /etc/sudoers.d/ end hovedfilen. Vær opmærksom på to regler for den mappe:

  • Filer, hvis navn indeholder et punktum eller ender på ~, bliver sprunget over. backup.conf virker altså ikke, men backup gør. Det er beregnet til at ignorere kopier fra editorer, men det overrasker mange.
  • Filen skal ejes af root og må ikke være skrivbar for andre (440 er almindeligt; visudo sørger for det).

Vil du kontrollere en eksisterende fil uden at redigere den: visudo -c kontrollerer det hele.

NOPASSWD: praktisk, men vid hvad du gør

Med NOPASSWD beder sudo ikke længere om en adgangskode:

anna ALL=(ALL:ALL) NOPASSWD: ALL

Nogle VPS-images sætter dette for standardbrugeren, så du er administrator, så snart du har logget ind med en nøgle. Tjek med sudo -l, hvad der gælder hos dig. Konsekvensen: den, der har Annas nøgle, er straks root. Der er ingen ekstra lås. På en personlig server kan du vælge det, men gør det bevidst.

Meget bedre er NOPASSWD kun for én bestemt kommando, for eksempel et backupscript, der skal kunne køre automatisk:

backup ALL=(root) NOPASSWD: /usr/local/bin/maak-backup

Brugeren backup må så køre netop det ene script som root, uden adgangskode, og intet andet. To faldgruber:

  • Brug altid den fulde sti. Med kun maak-backup kan nogen lægge et eget program med det navn forrest i sin sti.
  • Selve scriptet må ikke være skrivbart for den bruger. Ellers ændrer han det og kører vilkårlige kommandoer som root. Det samme gælder kommandoer, der selv kan åbne en shell, som en editor (vim, nano) eller less: den, der må starte dem via sudo, kan åbne en root-shell inde fra programmet. Giv aldrig sådanne kommandoer fri via sudo.

Hvad bliver logget

Hver gang nogen bruger sudo, kommer der en linje i journalen (og på systemer med rsyslog også i /var/log/auth.log):

anna@web1:~$ sudo journalctl _COMM=sudo --since today
Nov 09 10:31:02 web1 sudo[2214]:     anna : TTY=pts/0 ; PWD=/home/anna ; USER=root ; COMMAND=/usr/bin/apt update

Du ser hvem, hvor, som hvem og hvilken kommando. Det er en af grundene til ikke at arbejde flere personer som root. Mislykkede sudo-forsøg ("incorrect password attempts") fra en konto, der ikke er din, er et advarselstegn.

Minimale rettigheder i det store billede

sudo er én anvendelse af et generelt princip: minimale rettigheder (least privilege). Hver bruger og hver tjeneste får præcis de rettigheder, der er nødvendige, og ikke flere. På en server betyder det blandt andet:

  • du arbejder som almindelig bruger og bruger kun sudo, når det er nødvendigt;
  • hver tjeneste kører under sin egen bruger uden shell (lektion 3.1), ikke som root;
  • en webapplikation får en databasebruger, der kun må bruge sin egen database, ikke administratoren af databaseserveren;
  • et backupscript må kun den ene kommando, det har brug for (NOPASSWD med fuld sti);
  • en kollega, der kun opdaterer hjemmesiden, får skriveret til /var/www/example.com via en gruppe, ikke sudo.

Idéen: går noget galt (et hul i et plugin, en stjålet nøgle), forbliver skaden begrænset til den ene bruger eller tjeneste. Det dukker op igen og igen i CIS-principperne og i lektionen om hardening (10.1).

På AlmaLinux og Rocky Linux

Der hedder administratorgruppen wheel i stedet for sudo: usermod -aG wheel anna. Linjen i /etc/sudoers er %wheel ALL=(ALL) ALL. visudo og /etc/sudoers.d virker på samme måde. Sudo-meddelelser står der også i /var/log/secure.

Opsummering

  • Arbejd som almindelig bruger og brug sudo til administration; sudo beder om din egen adgangskode og logger hver kommando.
  • Opret en administrator: adduser anna, adduser anna sudo (wheel på RHEL-lignende systemer), nøgle med rigtig ejer og rettigheder, test i et andet vindue, og slå først derefter root-login fra.
  • Rediger kun sudo-regler med visudo, helst i en egen fil i /etc/sudoers.d/ uden punktum i navnet.
  • NOPASSWD for alt fjerner en lås; brug det hellere kun til én kommando med fuld sti, som brugeren ikke kan ændre.
  • Minimale rettigheder: hver bruger og tjeneste får præcis det nødvendige, så en fejl eller et hul forbliver lille.

Quiz

1. Hvilken adgangskode beder sudo som standard om, når Anna skriver sudo apt update?



2. Du opretter filen /etc/sudoers.d/backup.conf med en gyldig linje, men den virker ikke. Hvorfor?



3. Hvorfor redigerer du sudo-regler med visudo?



4. Hvilken linje giver en backupbruger den mindste risiko?



5. I hvilken rækkefølge slår du root-login fra uden at låse dig selv ude?



Opgave

Opgave O3.2: En administrator med sudo. Opret en almindelig administrator på din server (for eksempel anna), sæt din nøgle rigtigt op, test login og sudo -l i et andet vindue, og slå derefter root-login via SSH fra (PermitRootLogin no). Sæt flueben ved trinene, indsæt outputtet fra id (kun navn og grupper), og besvar spørgsmålene: hvilken linje giver din administrator rettigheder, står der NOPASSWD et sted, og hvordan kommer du ind, hvis du glemmer din adgangskode?

Opgave O3.2: En administrator med sudo

Denne opgave laver du selv; ingen tjekker den. Afkryds hvad du har gjort, og markér opgaven som udført.




Dine afkrydsninger og noter forbliver kun i denne browser; vi sender dem ingen steder hen. Er du logget ind, gemmer vi kun i Mine kurser, at du har udført opgaven.

Læs mere

Trinene i disse artikler gælder for WebOkés VPS'er; hos andre udbydere fungerer det på lignende måde.

Et øjeblik…

Opsæt dine domæner

Angiv for hvert domæne navneserverne, tilknytningen til din hosting, og hvem der bliver ejer.

Indlæser dine domæner…