Ubuntu VPS einrichten: deine erste Website mit HTTPS

Voraussetzungen und Arbeitsumgebung

Du brauchst eine neue Ubuntu-24.04-Instanz, eine bekannte öffentliche IPv4-Adresse, einen funktionierenden initialen Zugang mit sudo und eine Konsole zur Wiederherstellung. Für HTTPS wird eine Domain benötigt, deren DNS du verwaltest. Plane eine unabhängige Sicherung, bevor du später wichtige Daten ablegst.

Die lokalen Beispiele verwenden Bash unter Linux, macOS oder WSL. Befehle nach dem SSH-Login laufen auf dem Server. Ersetze 203.0.113.10 und app.example.com durch deine Werte; beide sind ausschließlich Dokumentationsbeispiele.

SSH-Schlüssel hinterlegen und Zugriff prüfen

Prüfe lokal, ob der geplante Schlüsselname bereits existiert. Verwende einen neuen Namen statt einen vorhandenen Schlüssel zu überschreiben. Erstelle den Schlüssel und schütze ihn mit einer Passphrase:

mkdir -p ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/ubuntu_vps
cat ~/.ssh/ubuntu_vps.pub

Bei einer neuen Bereitstellung kannst du den öffentlichen Schlüssel über die Anbieteroberfläche hinterlegen. Auf einem bereits erreichbaren Server kopierst du ihn über den bestehenden, geprüften Zugang. Prüfe vor der ersten Verbindung den Host-Fingerprint über die vertrauenswürdige Konsole.

scp -i ~/.ssh/existing_vps_key ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pub

Die folgende Ergänzung auf dem Server erhält vorhandene Schlüssel in authorized_keys. Der private Schlüssel bleibt lokal.

if ssh-keygen -lf ~/ubuntu-vps-admin.pub; then
    mkdir -p ~/.ssh
    chmod 700 ~/.ssh
    printf '\n' >> ~/.ssh/authorized_keys
    cat ~/ubuntu-vps-admin.pub >> ~/.ssh/authorized_keys
    chmod 600 ~/.ssh/authorized_keys
fi

Lies über die vertrauenswürdige Anbieter-Konsole den Fingerprint des Gastservers aus und vergleiche denselben Schlüsseltyp beim SSH-Login:

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Teste den neuen Schlüssel in einer zweiten lokalen Sitzung. Die Beispiele verwenden ubuntu als initialen Benutzer; passe ihn an das gewählte Image an.

ssh -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

Kopiere die öffentliche Schlüsseldatei anschließend lokal über den geprüften Zugang auf den Server. Sie wird im nächsten Schritt für den zusätzlichen Benutzer benötigt. Wenn du sie bereits beim vorigen Kopiervorgang übertragen hast, ist dieser erneute Transfer nicht nötig.

scp -i ~/.ssh/ubuntu_vps ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pub

Einen Administrator anlegen und separat testen

Die folgenden Befehle laufen auf der neuen Instanz über den initialen Zugang. Prüfe das System und die Updates. Lege deploy nur an, wenn dieser Benutzer noch nicht existiert. Die übertragene öffentliche Datei muss unter ~/ubuntu-vps-admin.pub liegen.

cat /etc/os-release
free -h
df -h /
sudo apt update
sudo apt upgrade
sudo adduser deploy
sudo usermod -aG sudo deploy
sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo install -m 600 -o deploy -g deploy ~/ubuntu-vps-admin.pub /home/deploy/.ssh/authorized_keys

Öffne lokal eine weitere Verbindung als deploy:

ssh -i ~/.ssh/ubuntu_vps deploy@203.0.113.10

Prüfe in dieser neuen entfernten Sitzung die administrativen Rechte. Die erwartete Ausgabe ist root. Lass die bisher funktionierende Sitzung währenddessen geöffnet.

sudo whoami

Nginx installieren und Firewall passend zum Image wählen

Installiere Nginx auf der frischen Instanz über den geprüften Benutzer mit sudo:

sudo apt install nginx
sudo systemctl enable --now nginx

Die nächste UFW-Sequenz gilt nur für einen gewöhnlichen neuen Ubuntu-Server, dessen Netzkonfiguration damit vereinbar ist. Erlaube zuerst den tatsächlich genutzten SSH-Port; das Beispiel verwendet 22. Bei Oracle-Ubuntu diese Sequenz auslassen: vorhandene Plattform- und iSCSI-Regeln dürfen nicht ersetzt werden.

sudo apt install ufw
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Öffne zusätzlich in der Anbieter-Firewall die benötigten HTTP- und HTTPS-Zielports 80 und 443. SSH sollte nur aus deinem benötigten Netz erreichbar sein. Gast-Firewall und Anbieterregeln müssen beide passen.

Eine abgegrenzte Nginx-Site anlegen

Verwende die Beispielpfade /var/www/first-site und /etc/nginx/sites-available/first-site sowie den Link in sites-enabled nur, wenn sie noch nicht belegt sind. Ersetze app.example.com in der Konfiguration vor dem Ausführen durch deinen Domainnamen. Die Befehle schreiben eine kleine Seite und eine eigene Nginx-Site:

sudo install -d -m 755 /var/www/first-site
printf '%s\n' '<!doctype html><html lang="de"><title>Erste Bereitstellung</title><h1>Diese Seite läuft auf einem Ubuntu VPS</h1></html>' | sudo tee /var/www/first-site/index.html
sudo tee /etc/nginx/sites-available/first-site >/dev/null <<'EOF'
server {
    listen 80;
    listen [::]:80;
    server_name app.example.com;
    root /var/www/first-site;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}
EOF
sudo ln -s /etc/nginx/sites-available/first-site /etc/nginx/sites-enabled/first-site
sudo nginx -t

Der Konfigurationstest muss erfolgreich sein, bevor Nginx neu geladen wird. Bei einem Fehler die Meldung beheben und den bisher funktionierenden Dienst beibehalten.

sudo systemctl reload nginx

Teste anschließend von deinem lokalen Rechner gegen die öffentliche Serveradresse mit dem richtigen Hostnamen. Dadurch lässt sich Nginx vor der DNS-Umstellung prüfen:

curl --resolve app.example.com:80:203.0.113.10 http://app.example.com/

DNS verbinden und HTTPS einschließlich Erneuerung prüfen

Lege den A-Eintrag für deine Domain an. Einen AAAA-Eintrag veröffentlichst du nur, wenn IPv6 bis zum Webserver korrekt funktioniert. Warte, bis die Domain auf die erwartete Adresse auflöst und HTTP über den Domainnamen erreichbar ist.

Beantrage dann auf dem Server mit Certbot das Zertifikat für deine tatsächliche Domain. Prüfe die Änderungen an Nginx, den Erneuerungstest und den zuständigen Timer:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d app.example.com --redirect
sudo nginx -t
sudo certbot renew --dry-run
systemctl list-timers --all certbot.timer

Ein erfolgreicher einmaliger Abruf ist noch kein Nachweis für dauerhaft funktionierendes HTTPS. Beobachte auch die spätere automatische Erneuerung.

Von außen testen und den Betrieb vorbereiten

Rufe die echte Domain von deinem lokalen Rechner aus auf. Kontrolliere HTTP-Weiterleitung, gültiges Zertifikat und erwarteten Seiteninhalt. Eine Standard-Nginx-Seite kann trotz Status 200 die falsche Konfiguration anzeigen.

curl -I http://app.example.com/
curl -I https://app.example.com/
curl -fsS https://app.example.com/

An der neuen, entbehrlichen Instanz kannst du anschließend einen geplanten Neustart über die Anbieteroberfläche durchführen. Bei einem produktiven Server wären Wartungsfenster und Wiederherstellungsweg vorher zu klären.

Kontrolliere anschließend SSH, Nginx und HTTPS erneut. Richte Überwachung und externe Sicherungen ein. Die Wiederherstellungsübung zeigt einen kleinen Dateitest; eine Datenbank benötigt zusätzlich ein dazu passendes Sicherungsverfahren.

Fragen und Antworten