Tobias Ludwig
Start
ErstgesprächKontakt
$whoami
Tobias Ludwig
DevOps · Application Manager · Software Engineer
$ls /pages
projekte/kontakt/kalender/impressum/
$git remote
github.com/nexas105
online·next.js 16·hono·postgresql
© 2026 tjl·stay curious_
/blog/Infrastruktur/linux-server-einrichten-teil-1

Linux Server einrichten – Teil 1: Grundlagen & Erstzugriff

Linux-Server von Grund auf einrichten: SSH-Login, System-Updates, sudo-User anlegen, SSH-Keys konfigurieren und Root-Login sicher deaktivieren — Schritt für Schritt für Ubuntu 24.04 LTS.

16. Juni 20267 min Lesezeit1.498 Wörter
linuxserverubuntusshdevopstutorialsicherheit
ReiheLinux Server einrichtenTeil 1 / 3
  1. 01Linux Server einrichten – Teil 1: Grundlagen & Erstzugriff
  2. 02Linux Server einrichten – Teil 2: Absicherung & Härtung
  3. 03Linux Server einrichten – Teil 3: Dienste & Deployment

Einen frischen Linux-Server in Betrieb zu nehmen klingt nach einer technischen Herausforderung — ist es aber gar nicht, wenn man die richtigen Schritte in der richtigen Reihenfolge kennt. Dieser erste Teil der Reihe "Linux Server einrichten" führt dich vom leeren VPS bis zu einem sicheren, aktuellen System mit einem dedizierten sudo-User und schlüsselbasiertem SSH-Login. Die Grundlagen, die du hier legst, sind das Fundament für alles Weitere.

Voraussetzungen

Das ist der erste Teil der Reihe — du brauchst keinerlei Vorkenntnisse aus vorherigen Artikeln. Mitbringen solltest du:

  • Einen gemieteten VPS oder Dedicated Server bei einem Hoster deiner Wahl (Hetzner Cloud, IONOS, DigitalOcean, Contabo, etc.) mit Ubuntu 24.04 LTS oder Debian 12
  • Die IP-Adresse und das Root-Passwort aus der Hoster-Konsole
  • Ein Terminal auf deinem lokalen Rechner (Linux/macOS: bereits vorhanden; Windows: Windows Terminal + WSL2 oder PuTTY)
  • Grundlegendes Verständnis dafür, was ein Terminal ist und wie man Befehle eingibt

Den Server bestellen und erste Zugangsdaten erhalten

Beim Anlegen eines neuen Servers im Dashboard deines Hosters wählst du das Betriebssystem (wir nehmen Ubuntu 24.04 LTS), die gewünschte Größe und den Standort. Nach dem Erstellen bekommst du per E-Mail oder direkt im Dashboard angezeigt:

  • Die öffentliche IP-Adresse des Servers
  • Das temporäre Root-Passwort (oder die Option, direkt einen SSH-Key zu hinterlegen)

Hinweis: Bei Hetzner Cloud und DigitalOcean kannst du beim Anlegen bereits einen SSH-Key hinterlegen. Das empfiehlt sich, aber für diesen Guide starten wir klassisch mit Passwort-Login, um den kompletten Weg nachzuvollziehen.

Erster SSH-Login als root

Öffne dein Terminal und verbinde dich mit dem Server:

ssh root@<DEINE-IP>

Beim allerersten Verbindungsaufbau fragt SSH, ob du dem Fingerprint des Servers vertraust:

The authenticity of host '1.2.3.4 (1.2.3.4)' can't be established.
ED25519 key fingerprint is SHA256:abc123...
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Gib yes ein und bestätige mit Enter. Anschließend gibst du das Root-Passwort aus dem Hoster-Dashboard ein. Du bist nun als root auf dem Server eingeloggt.

Sicherheitshinweis: Root-Login mit Passwort ist ein temporärer Zustand. Am Ende dieses Artikels wirst du ihn deaktivieren.

System aktualisieren

Der erste Schritt auf jedem frischen Server: alle Pakete auf den neuesten Stand bringen. Sicherheitslücken in veralteten Paketen sind eine der häufigsten Einfallstore für Angreifer.

apt update && apt upgrade -y
  • apt update aktualisiert die Paketliste (welche Versionen verfügbar sind).
  • apt upgrade -y installiert alle verfügbaren Updates ohne nachzufragen.

Wenn während des Upgrades ein Dialog zu sshd_config oder dem Kernel auftaucht, wähle in der Regel "Keep the local version currently installed" oder bestätige mit der Standardauswahl — du willst nicht, dass ein automatisches Update deine spätere SSH-Konfiguration überschreibt.

Nach umfangreichen Updates (besonders Kernel-Updates) empfiehlt sich ein Neustart:

reboot

Nach etwa 30 Sekunden kannst du dich erneut per SSH verbinden.

Hostname und Zeitzone konfigurieren

Hostname setzen

Der Hostname identifiziert deinen Server im Netzwerk und taucht im Terminal-Prompt auf. Setze ihn auf etwas Sinnvolles:

hostnamectl set-hostname mein-server

Überprüfen kannst du das Ergebnis mit:

hostnamectl

Außerdem solltest du den Hostnamen in /etc/hosts eintragen, damit die lokale Namensauflösung stimmt:

echo "127.0.1.1   mein-server" >> /etc/hosts

Zeitzone setzen

Eine korrekte Zeitzone ist wichtig für Log-Dateien, Cronjobs und Zertifikate. Liste verfügbare Zeitzonen auf und setze die passende:

timedatectl list-timezones | grep Europe
timedatectl set-timezone Europe/Berlin

Überprüfe das Ergebnis:

timedatectl

Die Ausgabe sollte Time zone: Europe/Berlin (CET, +0100) oder ähnlich zeigen.

Einen sudo-User anlegen

Als root zu arbeiten ist gefährlich — ein Tippfehler kann das System beschädigen. Lege einen neuen Benutzer an und füge ihn der sudo-Gruppe hinzu:

adduser deployer

Du wirst nach einem Passwort und optionalen Informationen gefragt. Vergib ein starkes Passwort und bestätige die Felder mit Enter.

Anschließend fügst du den User der sudo-Gruppe hinzu:

usermod -aG sudo deployer

Überprüfe die Gruppen des neuen Users:

groups deployer
# Ausgabe: deployer : deployer sudo

Teste kurz, ob der User sudo-Berechtigungen hat — wechsle in seine Shell:

su - deployer
sudo whoami
# Ausgabe: root

Wenn root ausgegeben wird, ist alles korrekt. Verlasse die User-Shell wieder mit exit.

SSH-Key-Login einrichten

Passwörter sind komfortabel, aber unsicher. SSH-Keys sind deutlich sicherer und mit dem richtigen Setup genauso komfortabel. Wir richten jetzt schlüsselbasierte Authentifizierung ein.

SSH-Key auf dem lokalen Rechner generieren (falls noch nicht vorhanden)

Auf deinem lokalen Rechner (nicht auf dem Server):

ssh-keygen -t ed25519 -C "mein-server-key"

Du wirst nach einem Speicherort gefragt (Standard: ~/.ssh/id_ed25519) und optional nach einer Passphrase. Eine Passphrase empfiehlt sich für erhöhte Sicherheit.

Public Key auf den Server übertragen

Der einfachste Weg ist ssh-copy-id:

ssh-copy-id -i ~/.ssh/id_ed25519.pub deployer@<DEINE-IP>

Alternativ kannst du es manuell machen — auf dem Server als deployer:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys
# Füge hier den Inhalt deiner ~/.ssh/id_ed25519.pub ein
chmod 600 ~/.ssh/authorized_keys

Die Berechtigungen sind kritisch: ~/.ssh muss 700 haben, authorized_keys muss 600 haben. Falsche Berechtigungen führen dazu, dass SSH den Key ignoriert — ein klassischer Stolperstein.

Verbindung mit Key testen

Öffne ein neues Terminal-Fenster (lass das alte offen!) und teste den Key-Login:

ssh deployer@<DEINE-IP>

Wenn du ohne Passwort-Abfrage (oder nur mit Key-Passphrase) eingeloggt wirst, hat es geklappt.

Wichtig: Schließe die alte Root-Session noch NICHT. Du brauchst sie für den nächsten Schritt.

Root-Login und Passwort-Authentifizierung deaktivieren

Jetzt, wo du dich per Key als deployer einloggen kannst, kannst du den unsicheren Root-Login und den Passwort-Login deaktivieren. Das ist einer der wichtigsten Sicherheitsschritte überhaupt.

Öffne die SSH-Konfigurationsdatei auf dem Server (als root oder mit sudo):

sudo nano /etc/ssh/sshd_config

Suche (Strg+W in nano) und ändere oder ergänze folgende Zeilen:

# Root-Login verbieten
PermitRootLogin no

# Passwort-Authentifizierung deaktivieren
PasswordAuthentication no

# Nur Public-Key-Authentifizierung erlauben
PubkeyAuthentication yes

Speichere die Datei (Strg+X, dann Y, dann Enter) und starte den SSH-Dienst neu:

sudo systemctl restart sshd

Teste sofort in einem neuen Terminal:

ssh deployer@<DEINE-IP>
# Muss funktionieren

ssh root@<DEINE-IP>
# Muss mit "Permission denied" scheitern

Grundlegende Navigation und Paketverwaltung

Zum Abschluss ein kompakter Überblick über die wichtigsten Befehle und Verzeichnisse, die du auf jedem Linux-Server täglich brauchst.

Wichtige Verzeichnisse

VerzeichnisZweck
/etcSystemweite Konfigurationsdateien (sshd_config, hosts, fstab, ...)
/var/logLog-Dateien (auth.log, syslog, nginx/access.log, ...)
/home/<user>Home-Verzeichnis des jeweiligen Benutzers
/tmpTemporäre Dateien (werden beim Reboot gelöscht)
/usr/bin, /usr/local/binInstallierte Programme/Binaries
/optManuell installierte Drittanbieter-Software
/srvServer-Daten (z. B. Webroot für Nginx/Apache)

Paketverwaltung mit apt — Cheatsheet

apt update                    # Paketliste aktualisieren
apt upgrade -y                # Alle Pakete upgraden
apt install <paket>           # Paket installieren
apt remove <paket>            # Paket entfernen (Config bleibt)
apt purge <paket>             # Paket inkl. Config entfernen
apt autoremove                # Nicht mehr benötigte Pakete entfernen
apt search <stichwort>        # Pakete suchen
dpkg -l | grep <name>         # Prüfen, ob Paket installiert ist
systemctl status <dienst>     # Status eines Systemdienstes prüfen
journalctl -u <dienst> -f     # Live-Logs eines Dienstes anzeigen

Häufige Fehler

Sich selbst aussperren

Der klassische Fehler: du deaktivierst PasswordAuthentication und PermitRootLogin, aber hast den Key noch nicht auf den Server übertragen oder die Berechtigungen von ~/.ssh sind falsch. Du kannst dich dann nicht mehr per SSH einloggen.

Lösung: Immer in einem separaten Terminal-Fenster testen, bevor du die alte Session schließt. Im Notfall bieten die meisten Hoster eine Web-Konsole (VNC/KVM) im Dashboard an, über die du trotzdem Zugriff bekommst.

Falsche Dateiberechtigungen bei SSH-Keys

SSH ist bei den Berechtigungen sehr streng. Typische Fehler:

  • ~/.ssh hat 755 statt 700 → SSH ignoriert den authorized_keys
  • ~/.ssh/authorized_keys hat 644 statt 600 → Key wird nicht akzeptiert

Prüfen und korrigieren:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

apt update schlägt fehl wegen veralteter Mirrors

Auf frischen Servern manchmal: Hash Sum mismatch oder Failed to fetch. Lösung:

apt clean
apt update --fix-missing

sudo funktioniert nicht für den neuen User

Wenn sudo whoami nach dem adduser / usermod noch nicht funktioniert, hast du die Session nicht neu gestartet. Der User muss sich neu einloggen, damit die Gruppenänderung wirksam wird:

su - deployer  # oder neu einloggen via SSH

timedatectl zeigt falsche Zeit trotz korrekter Zeitzone

Häufige Ursache: NTP ist deaktiviert. Aktivieren mit:

timedatectl set-ntp true

Nächste Schritte

Du hast jetzt einen aktuellen, grundlegend konfigurierten Linux-Server mit einem sicheren sudo-User und schlüsselbasiertem SSH-Zugang. Das ist ein solider Ausgangspunkt — aber noch kein gehärteter Server.

In Teil 2 der Reihe — "Absicherung & Härtung" — geht es darum, den Server aktiv gegen Angriffe abzusichern:

  • UFW-Firewall einrichten: welche Ports offen bleiben, alles andere sperren
  • Fail2ban konfigurieren: automatische IP-Sperrung bei Brute-Force-Versuchen
  • SSH weiter härten: nicht-Standard-Port, AllowUsers, LoginGraceTime und weitere sshd_config-Parameter
  • Unattended Upgrades: automatische Sicherheitsupdates einrichten
  • Auditd und logwatch: Systemaktivitäten überwachen

Bis dahin: lass deinen Server nicht zu lange ohne Firewall im Netz — die ersten automatisierten Scan-Versuche kommen oft schon Minuten nach dem Erstellen des Servers an.

Verwandte Artikel

  • Infrastruktur· 3 gemeinsame TagsLinux Server einrichten – Teil 2: Absicherung & Härtung
  • InfrastrukturLinux Server einrichten – Teil 3: Dienste & Deployment
  • KI / AILokale KI – Teil 3: Lokale Agenten & Pipelines
  • KI / AILokale KI – Teil 2: Bilder & Audio lokal generieren
Nächster Teil Linux Server einrichten – Teil 2: Absicherung & Härtung

Neue Artikel via RSS abonnieren

Inhalt
  • Voraussetzungen
  • Den Server bestellen und erste Zugangsdaten erhalten
  • Erster SSH-Login als root
  • System aktualisieren
  • Hostname und Zeitzone konfigurieren
  • Hostname setzen
  • Zeitzone setzen
  • Einen sudo-User anlegen
  • SSH-Key-Login einrichten
  • SSH-Key auf dem lokalen Rechner generieren (falls noch nicht vorhanden)
  • Public Key auf den Server übertragen
  • Verbindung mit Key testen
  • Root-Login und Passwort-Authentifizierung deaktivieren
  • Grundlegende Navigation und Paketverwaltung
  • Wichtige Verzeichnisse
  • Paketverwaltung mit apt — Cheatsheet
  • Häufige Fehler
  • Sich selbst aussperren
  • Falsche Dateiberechtigungen bei SSH-Keys
  • apt update schlägt fehl wegen veralteter Mirrors
  • sudo funktioniert nicht für den neuen User
  • timedatectl zeigt falsche Zeit trotz korrekter Zeitzone
  • Nächste Schritte
Tags
linuxserverubuntusshdevopstutorialsicherheit
RSS-Feed

Neue Artikel im Reader.