SSH unter Ubuntu aktivieren

Kurz gesagt: sudo apt install openssh-server installiert den SSH-Dienst; ab Ubuntu 22.10 startet und aktiviert er sich bei der Installation von selbst, es bleibt also meist nichts mehr zu tun. Ist er schon installiert, antwortet aber nicht, hilft sudo systemctl enable --now ssh und, falls eine Firewall aktiv ist, sudo ufw allow OpenSSH.

Ubuntu Server hat SSH schon; Ubuntu Desktop nicht

Der Installer von Ubuntu Server bietet OpenSSH Server als Checkbox während der Einrichtung an, und fast jeder wählt sie aus – deshalb nimmt ein frischer Ubuntu-Server-VPS schon ab dem ersten Boot SSH-Verbindungen an, ohne weitere Schritte. Ubuntu Desktop installiert SSH dagegen nie, aus der (vernünftigen) Annahme, dass ein Desktop-Rechner standardmäßig keine eingehenden Logins annehmen muss – genau deshalb kommt die Frage, wie man SSH aktiviert, überhaupt erst dort auf.

1. 1openssh-server installieren

   sudo apt update
   sudo apt install -y openssh-server

   Das installiert den Dienst ssh (sein systemd-Einheitenname) und den sshd-Daemon selbst. Prüfe, ob er überhaupt da ist:

   dpkg -l | grep openssh-server

2. 2Prüfen, ob er läuft

   systemctl status ssh

   active (running) heißt, er funktioniert bereits – nichts weiter zu tun. Steht dort inactive (dead) oder could not be found, weiter zum nächsten Schritt.

3. 3Aktivieren und starten

   sudo systemctl enable --now ssh

   enable sorgt dafür, dass er ab jetzt bei jedem Boot startet; --now startet ihn außerdem sofort, du musst also nicht erst neu starten, um zu sehen, ob es funktioniert hat.

4. 4Die Firewall öffnen, falls eine aktiv ist

   sudo ufw status
   sudo ufw allow OpenSSH

   OpenSSH ist hier ein Anwendungsprofil, das ufw mitbringt, kein Paketname zum Eintippen – es steht für TCP-Port 22. Zeigt ufw status „inactive“, gibt es nichts zu öffnen, und dieser Schritt tut nichts, was völlig in Ordnung ist.

5. 5Verbinden

   ssh deinbenutzername@SERVER_IP

   Halte deine aktuelle Sitzung (Konsole, oder was dich überhaupt erst auf die Maschine gebracht hat) offen, bis das klappt, falls Schritt 4 irgendwo eine Regel übersehen hat – etwa eine separate Netzwerk-Firewall oder Security Group des Cloud-Anbieters, von der ufw nichts weiß.

ssh, sshd oder ssh.socket: die Ubuntu-Version zählt

Ab 24.04 braucht eine Portänderung oder ein Config-Reload sudo systemctl daemon-reload && sudo systemctl restart ssh.socket statt eines Neustarts von ssh selbst, sonst antwortet still die alte Einstellung weiter. Nur um den Dienst zum ersten Mal zu aktivieren, funktioniert systemctl enable --now ssh auf jeder Version: systemd löst den Alias auf die jeweils zutreffende Einheit auf.

Bestätigen, dass sshd wirklich lauscht

sudo ss -tlnp | grep ssh
sudo sshd -T | grep -i ^port

ss zeigt, was wirklich und gerade jetzt an einem Port gebunden ist, egal was systemctl status behauptet; sshd -T gibt die effektive Konfiguration aus, die sshd nutzen würde – das fängt auch eine zweite, vergessene Port-Zeile in einer Drop-in-Datei unter /etc/ssh/sshd_config.d/ ab, die Port 22 wieder öffnet, obwohl du ihn eigentlich ändern wolltest.

Passwort-Login ist standardmäßig an – abschalten, sobald der Key funktioniert

Eine frische openssh-server-Installation akzeptiert Passwort-Logins, was für die erste Verbindung in Ordnung ist, aber nicht dauerhaft auf einem vom ganzen Internet erreichbaren Server bleiben sollte. Richte zuerst einen Schlüssel ein:

ssh-keygen -t ed25519 -C "du@example"
ssh-copy-id deinbenutzername@SERVER_IP

Dann Passwort-Logins auf dem Server abschalten, in /etc/ssh/sshd_config oder einer Drop-in-Datei:

PasswordAuthentication no

sudo sshd -t && sudo systemctl restart ssh    # 24.04: stattdessen ssh.socket neu starten

Teste den Key-Login in einem neuen Terminal, bevor du das aktuelle schließt – dieselbe Regel wie bei einer Portänderung, aus demselben Grund. Die komplette Absicherung über diese eine Einstellung hinaus, inklusive fail2ban und dem Abschalten des Root-Logins, steht in SSH-Zugriff absichern (engl.).

Installiert und läuft, aber Verbindungen schlagen trotzdem fehl

Ein Hinweis zu WSL und Containern

Alles oben gilt für einen echten Ubuntu-Server oder eine VM. Innerhalb von WSL oder einem Docker-Container funktioniert systemctl womöglich gar nicht, weil keiner der beiden unbedingt systemd als PID 1 ausführt – sudo service ssh start ist dort der Ausweg, und es lohnt sich ohnehin selten, einen SSH-Server in einem Container zu betreiben, da der Host schon einen Zugangsweg bietet.

Häufige Fragen