Sudo-Benutzer auf dem VPS anlegen und root abschalten

Fast jeder neue VPS beginnt gleich: Sie melden sich als root an, installieren ein paar Dinge, und einen Monat später sind Sie immer noch root. Das geht gut, bis ein eingefügtes Skript das falsche Verzeichnis löscht. Einen normalen Benutzer mit sudo einzurichten dauert fünf Minuten, und die Reihenfolge ist wichtiger als die Befehle — macht man es falsch, sperrt man sich aus.

Hier die sichere Abfolge für Ubuntu 22.04/24.04 und Debian 12.

1. Benutzer anlegen

Als root:

adduser deploy
usermod -aG sudo deploy

adduser fragt nach einem Passwort und optionalen Angaben (dort einfach Enter drücken). Wählen Sie ein echtes Passwort: Sie tippen es für sudo. Fehlt der Befehl auf einem minimalen Debian, zuerst apt install -y sudo ausführen.

2. SSH-Schlüssel übertragen

Am einfachsten kopieren Sie die Schlüssel von root mit korrektem Besitzer:

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

Wer es lieber von Hand macht:

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

Falsche Rechte sind der klassische Grund, warum der Schlüssel-Login stillschweigend scheitert. SSH ignoriert eine authorized_keys, in die andere Benutzer schreiben können.

3. Testen, bevor Sie etwas ändern

Lassen Sie die root-Sitzung offen. In einem neuen Terminal:

ssh -p 22 deploy@203.0.113.10
sudo whoami

Setzen Sie Ihre eigene IP und Ihren Port ein — bei einem NAT-Tarif ist das Ihr persönlicher SSH-Port aus dem Kundenbereich. Gibt sudo whoami root aus, passt alles. Scheitert der Login, haben Sie noch das root-Fenster, um es zu beheben.

4. Root-Login abschalten

Jetzt die Tür zumachen. Statt die Hauptkonfiguration zu bearbeiten, legen Sie eine kleine Drop-in-Datei an:

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

sshd -t prüft zuerst die Syntax. Eine kaputte Konfiguration plus Reload — genau so landen Leute in der Konsole. PasswordAuthentication no ist erst sinnvoll, wenn der Schlüssel-Login für den neuen Benutzer funktioniert — und das haben Sie gerade getestet.

Öffnen Sie noch ein Terminal und prüfen Sie, dass root abgewiesen wird und deploy weiterhin hineinkommt. Dann schließen Sie die alte root-Sitzung.

5. Optional: sudo ohne Passwort für Automatisierung

Braucht ein Deploy-Skript sudo ohne Rückfrage, geben Sie ihm genau das und nicht mehr:

visudo -f /etc/sudoers.d/deploy

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

Ehrlich gesagt ist NOPASSWD: ALL verlockend, bedeutet aber: gestohlener Schlüssel gleich root. Beschränken Sie es auf die Befehle, die die Automatisierung ausführt.

Wenn etwas schiefgeht

Die Web-Konsole im Kundenbereich hängt weder von SSH noch von der Firewall ab. Melden Sie sich dort an, korrigieren Sie die Datei in /etc/ssh/sshd_config.d/, Reload, fertig. Den ganzen Ablauf haben wir in so kommen Sie wieder auf einen ausgesperrten VPS beschrieben.

Wie es weitergeht

• Richtig auf reinen Schlüssel-Login umstellen: SSH-Schlüssel-Authentifizierung.
• Brute-Force-Lärm dämpfen: fail2ban.
• Die restlichen Grundlagen mit der Sicherheits-Checkliste für neue VPS durchgehen.

Die Zugangsoptionen jedes Tarifs stehen in der Zugangs-Dokumentation. Selbst ein Nano für $3 verdient einen Nicht-root-Benutzer — billiger wird ein Sicherheitsgewinn nicht.