Varför inte bara fortsätta som root?

Allt du kör som root kan förstöra hela systemet, även ett stavfel. Botar provar dessutom användarnamnet 'root' först, så när du stänger av root-inloggning försvinner det mest gissade målet. En namngiven användare med sudo ger dig en paus före varje privilegierat kommando och en logg över vad som kördes.

Vad händer om jag låser ute mig själv?

Använd webbkonsolen i kundpanelen. Den fungerar även när SSH är trasigt eller brandväggen blockerar dig, så du kan logga in och rätta sshd_config. Det är också därför du testar den nya användaren innan du stänger root-sessionen.

Bör jag tillåta sudo utan lösenord?

För ett personligt konto, behåll lösenordsfrågan — den är sista försvarslinjen om din SSH-nyckel läcker. Sudo utan lösenord är rimligt för en separat deploy-användare som automatiseringen använder, begränsad till de kommandon den faktiskt behöver.

Kommandot sudo finns inte på min Debian-server. Varför?

Minimala Debian-images har det inte alltid med. Installera det som root med 'apt install -y sudo' och lägg sedan till din användare i gruppen sudo.

Vilken SSH-port ska jag använda?

Den som visas i kundpanelen. Planer med dedikerad IP använder port 22 på din egen IP; NAT-planer använder din personliga SSH-port.

Så skapar du en sudo-användare på en VPS och slutar köra som root

Skapa en sudo-användare utan root-behörighet på Ubuntu eller Debian, ge den din SSH-nyckel, testa den och stäng sedan av root-inloggning — i en ordning som inte låser ute dig.

Nästan varje ny VPS börjar likadant: du loggar in som root, installerar några saker och en månad senare är du fortfarande root. Det fungerar ända tills ett inklistrat skript raderar fel katalog. Att sätta upp en vanlig användare med sudo tar fem minuter, och ordningen är viktigare än kommandona — gör fel och du låser ute dig själv.

Här är den säkra ordningen för Ubuntu 22.04/24.04 och Debian 12.

1. Skapa användaren

Som root:

adduser deploy
usermod -aG sudo deploy

adduser frågar efter ett lösenord och några valfria uppgifter (tryck bara Enter förbi dem). Välj ett riktigt lösenord: du kommer att skriva det för sudo. På en minimal Debian-image kör du först apt install -y sudo om kommandot saknas.

2. Ge den din SSH-nyckel

Enklast är att kopiera roots auktoriserade nycklar och behålla rätt ägare:

rsync --archive --chown=deploy:deploy /root/.ssh /home/deploy

Om du hellre gör det för hand:

mkdir -p /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

Fel behörigheter är den klassiska orsaken till att nyckelinloggning tyst misslyckas. SSH ignorerar en authorized_keys som andra användare kan skriva till.

3. Testa innan du ändrar något

Håll root-sessionen öppen. I en ny terminal:

ssh -p 22 deploy@203.0.113.10
sudo whoami

Använd din egen IP och port — på en NAT-plan är det din personliga SSH-port från panelen. Om sudo whoami skriver ut root är allt klart. Misslyckas inloggningen har du fortfarande root-fönstret att rätta det i.

4. Stäng av root-inloggning

Stäng nu dörren. Skapa en liten drop-in-fil i stället för att redigera huvudkonfigurationen:

cat > /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
EOF
sshd -t && systemctl reload ssh

sshd -t kontrollerar syntaxen först. En trasig konfiguration plus en reload är hur folk hamnar i konsolen. PasswordAuthentication no är bara meningsfullt när nyckelinloggning fungerar för din nya användare — vilket du just har testat.

Öppna ytterligare en terminal och bekräfta att root nekas och att deploy fortfarande kommer in. Stäng sedan den gamla root-sessionen.

5. Valfritt: sudo utan lösenord för automatisering

Behöver ett deployskript sudo utan fråga, ge det exakt det och inget bredare:

visudo -f /etc/sudoers.d/deploy

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

Ärligt talat är NOPASSWD: ALL frestande, men då är en stulen nyckel lika med root. Begränsa det till de kommandon som automatiseringen kör.

Om något går fel

Webbkonsolen i panelen är inte beroende av SSH eller brandväggen. Logga in där, rätta filen i /etc/ssh/sshd_config.d/, gör en reload, klart. Hela återställningsflödet beskriver vi i så tar du dig in i en utelåst VPS igen.

Vad du gör sedan

Gå över till enbart nyckelinloggning på riktigt: autentisering med SSH-nyckel.
Dämpa bruset från brute force-försök: fail2ban.
Gå igenom resten av grunderna med säkerhetschecklistan för en ny VPS.

Åtkomstalternativen för varje plan finns i dokumentationen om åtkomst. Även en Nano för $3 förtjänar en användare utan root — det är den billigaste säkerhetsuppgraderingen som finns.