SSH unter Ubuntu aktivieren: OpenSSH Server installieren

SSH unter Ubuntu aktivieren: installieren, starten, Firewall öffnen

SSH kommt unter Ubuntu aus dem Paket openssh-server. Ubuntu Server bietet die Installation während des Setups an, und nahezu jedes Cloud- oder VPS-Image lauscht bereits ab Werk; Ubuntu Desktop installiert den Server gar nicht.

1. openssh-server installieren

sudo apt update
sudo apt install -y openssh-server

Ist das Paket bereits vorhanden, meldet apt das und ändert nichts. Die Installation registriert zugleich ein UFW-Anwendungsprofil namens OpenSSH, das in Schritt 3 verwendet wird.

2. Dienst aktivieren und starten

sudo systemctl enable --now ssh
systemctl status ssh

Unter Ubuntu heißt die Unit ssh; sshd ist ein Alias. enable --now startet den Daemon sofort und bei jedem Boot. Seit Ubuntu 22.10 läuft sshd socket-aktiviert: ssh.socket belegt Port 22 und startet ssh.service bei der ersten eingehenden Verbindung. Ein Status inactive (dead) mit TriggeredBy: ssh.socket direkt nach der Installation ist also normal: Der Port ist offen. Den größeren Zusammenhang zeigt Dienste mit systemctl auflisten.

3. SSH durch UFW erlauben

Ubuntu liefert UFW deaktiviert aus. Wenn Sie die Firewall einschalten, erlauben Sie SSH zuerst; die Firewall vor der Regel zu aktivieren ist der Klassiker, um sich selbst von einem entfernten Rechner auszusperren.

sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status

ufw allow OpenSSH nutzt das Anwendungsprofil und öffnet 22/tcp. Verschieben Sie sshd später, erlauben Sie den neuen Port mit sudo ufw allow 2222/tcp und löschen Sie die alte Regel. Die Adresse des Servers finden Sie mit hostname -I.

Von Windows, macOS oder Linux verbinden

Jedes aktuelle Desktop-Betriebssystem bringt einen OpenSSH-Client mit, und die Syntax ist überall identisch:

ssh username@SERVER_IP
ssh -p 2222 username@SERVER_IP      # non-default port

• Windows 10 und 11: PowerShell oder Windows Terminal öffnen und den Befehl eingeben; der OpenSSH-Client gehört seit 2018 (Version 1809) zum Lieferumfang von Windows. Wird ssh nicht erkannt, fügen Sie ihn unter Einstellungen > Apps > Optionale Features hinzu.
• macOS: Terminal, derselbe Befehl.
• Linux: ein beliebiges Terminal; openssh-client ist unter Ubuntu standardmäßig installiert.

Bestätigen Sie bei der ersten Verbindung den Fingerprint des Server-Hostkeys mit yes; er landet in ~/.ssh/known_hosts, und Sie werden gewarnt, falls er sich jemals ändert. Danach geben Sie das Kontopasswort ein. Der nächste Abschnitt ersetzt es durch einen Schlüssel.

Auf schlüsselbasierte Authentifizierung umstellen

Passwortanmeldungen sind das, was Botnetze rund um die Uhr durchprobieren; Schlüssel machen diese Versuche sinnlos. Erzeugen Sie ein Ed25519-Schlüsselpaar auf Ihrem eigenen Rechner, niemals auf dem Server:

ssh-keygen -t ed25519 -C "laptop-2026"

Übernehmen Sie den Standardpfad (~/.ssh/id_ed25519) und setzen Sie eine Passphrase; sie verschlüsselt den privaten Schlüssel auf der Platte, und ein SSH-Agent sorgt dafür, dass Sie sie nur einmal pro Sitzung eingeben. Nur die .pub-Datei verlässt jemals Ihren Rechner.

Den öffentlichen Schlüssel auf den Server kopieren

Unter macOS und Linux erledigt ssh-copy-id das in einem Schritt (mit Ihrem Passwort ein letztes Mal):

ssh-copy-id -i ~/.ssh/id_ed25519.pub username@SERVER_IP

Die Windows-Variante von OpenSSH enthält kein ssh-copy-id; schieben Sie den Schlüssel stattdessen per Pipe aus PowerShell hinüber:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh username@SERVER_IP "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Beide Wege hängen den Schlüssel an die ~/.ssh/authorized_keys des jeweiligen Benutzers an. Die Rechte sind entscheidend: sshd ignoriert die Datei stillschweigend, wenn ~/.ssh nicht Modus 700 hat oder authorized_keys für andere als den Eigentümer schreibbar ist. In einem neuen Terminal sollte ssh username@SERVER_IP Sie jetzt ohne Kontopasswort anmelden. Fassen Sie den nächsten Abschnitt nicht an, bevor das funktioniert.

sshd_config härten: keine Passwörter, kein root, Benutzer auf Positivliste

Lassen Sie Ihre laufende Sitzung während der Bearbeitung offen; falls die neue Konfiguration etwas zerschießt, ist sie Ihr Weg zurück. /etc/ssh/sshd_config beginnt mit Include /etc/ssh/sshd_config.d/*.conf, und sshd behält für jedes Schlüsselwort den ersten gelesenen Wert. Ein Drop-in schlägt also alles, was weiter unten in der Hauptdatei steht. Cloud-Images liefern zudem oft /etc/ssh/sshd_config.d/50-cloud-init.conf mit PasswordAuthentication yes mit; deshalb scheint das Bearbeiten der Hauptdatei so oft wirkungslos. Die Lösung ist ein Drop-in, dessen Name zuerst einsortiert wird:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

Fügen Sie Folgendes ein und ersetzen Sie username durch Ihren eigenen Login:

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
AllowUsers username
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no
ClientAliveInterval 300
ClientAliveCountMax 2

PermitRootLogin no setzt voraus, dass Sie ein unprivilegiertes Konto mit sudo-Rechten haben. Haben Sie bisher als root gearbeitet, legen Sie einen sudo-Benutzer unter Linux an und kopieren Sie Ihren Schlüssel dorthin, bevor Sie die Datei anwenden. Prüfen Sie danach die Syntax, laden Sie neu und sehen Sie sich die Werte an, die sshd nach dem Zusammenführen aller Includes tatsächlich verwendet. Genau das gibt sshd -T aus:

sudo sshd -t
sudo systemctl reload ssh
sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin|allowusers|port'

Öffnen Sie ein zweites Terminal und melden Sie sich mit Ihrem Schlüssel an, bevor Sie das erste schließen. Was die einzelnen Direktiven bewirken:

Keepalive hat auch eine Client-Seite: ServerAliveInterval 60 in ~/.ssh/config auf Ihrem eigenen Rechner verhindert, dass NAT-Router untätige Sitzungen kappen.

Den SSH-Port zu ändern ist keine Sicherheit

sshd von Port 22 wegzuschieben ist ein beliebter Ratschlag. Was es bringt, sind weniger Log-Zeilen. Massen-Scanner tasten alle 65.535 Ports ab und finden sshd binnen Stunden auf 2222; wer es gezielt auf Sie abgesehen hat, findet ihn mit nmap in Sekunden. Schlüssel, kein root-Login, eine Positivliste und fail2ban sind die Sicherheit; der Port ist Kosmetik. Auf einem stark besuchten Server hält er das Authentifizierungs-Log lesbar, nur zählen Sie ihn niemals als Verteidigungsschicht.

Wenn Sie ihn dennoch ändern, halten Sie diese Reihenfolge ein: neuen Port in UFW öffnen, Port ändern, neu starten, aus einem zweiten Terminal testen, dann die alte Regel entfernen. Kommentieren Sie #Port 22 in /etc/ssh/sshd_config aus, setzen Sie den neuen Port und dann:

sudo ufw allow 2222/tcp
sudo sshd -t
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket    # Ubuntu 22.10 and later
sudo systemctl restart ssh           # Ubuntu 22.04 and earlier

Bei socket-aktivierten Releases entscheidet die Socket-Unit und nicht sshd, welcher Port gebunden wird; Ubuntu liefert einen systemd-Generator mit, der Port beim daemon-reload aus der sshd-Konfiguration liest und ssh.socket anpasst. Bestätigen Sie das mit sudo ss -tlnp | grep sshd. Die Anleitung zum Prüfen offener Ports unter Linux erklärt die Ausgabe. Hängt sshd hartnäckig weiter auf 22, deaktivieren Sie die Socket-Aktivierung und lassen Sie den Dienst den Port selbst binden: sudo systemctl disable --now ssh.socket && sudo systemctl enable --now ssh.service. Sobald ssh -p 2222 aus einem frischen Terminal funktioniert, führen Sie sudo ufw delete allow OpenSSH aus.

fail2ban ergänzen und Zwei-Faktor-Authentifizierung erwägen

Mit deaktivierten Passwörtern kann Brute Force nicht mehr erfolgreich sein, doch jeder Versuch kostet weiterhin einen Fork und eine Log-Zeile. fail2ban beobachtet das Authentifizierungs-Log und sperrt Adressen, die wiederholt scheitern:

sudo apt install -y fail2ban
sudo nano /etc/fail2ban/jail.local

Schreiben Sie das in die Datei:

[sshd]
enabled = true
port = ssh
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Bearbeiten Sie niemals jail.conf; sie wird bei Upgrades ersetzt, und jail.local überschreibt sie. port = ssh wird über /etc/services aufgelöst, schreiben Sie also port = 2222, wenn Sie den Daemon verschoben haben. backend = systemd liest das Journal direkt und funktioniert unabhängig davon, ob Ihr Image /var/log/auth.log schreibt. fail2ban-client status sshd listet gesperrte Adressen; sudo fail2ban-client set sshd unbanip 203.0.113.7 gibt eine wieder frei. Standardmäßig werden die Regeln von fail2ban vor denen von UFW ausgewertet, beide koexistieren also problemlos.

Zwei-Faktor-Authentifizierung

Wo Schlüssel plus Passphrase nicht genügen, ergänzt libpam-google-authenticator einen zeitbasierten Code zusätzlich zum Schlüssel: installieren, google-authenticator als Login-Benutzer ausführen, auth required pam_google_authenticator.so in /etc/pam.d/sshd eintragen (und dort die Zeile @include common-auth auskommentieren), dann in sshd KbdInteractiveAuthentication yes und AuthenticationMethods publickey,keyboard-interactive setzen. Ein echter Gewinn gegen einen gestohlenen Laptop — und eine Sache mehr, die man verlieren kann: Bewahren Sie die Notfallcodes nicht auf dem Server auf.

Fehlersuche: connection refused, timed out, permission denied

Connection refused

Der Server hat geantwortet, aber auf diesem Port lauscht nichts: sshd ist gestoppt, an anderer Stelle gebunden, oder Sie haben den falschen Port getippt. Führen Sie über die Konsole des Anbieters systemctl status ssh und sudo ss -tlnp | grep ssh aus. Ein Syntaxfehler verhindert den Start von sshd komplett; sudo sshd -t nennt die fehlerhafte Zeile und journalctl -u ssh -n 50 zeigt den letzten Start.

Connection timed out

Pakete werden verworfen statt abgewiesen, was fast immer eine Firewall bedeutet: UFW ohne Allow-Regel (sudo ufw status verbose), eine Security Group im Panel des Anbieters oder Ihr eigenes Netz, das ausgehend Port 22 blockiert. Ein Handy-Hotspot schließt das aus. ssh -v username@SERVER_IP zeigt, wo der Handshake hängen bleibt.

Permission denied (publickey)

Der Server ist erreichbar und weist Sie ab. Prüfen Sie der Reihe nach: den Benutzernamen, ob die authorized_keys dieses Benutzers den angebotenen Schlüssel enthält (ssh -i ~/.ssh/id_ed25519 -v erzwingt einen bestimmten Schlüssel), die Rechte auf ~/.ssh und ob der Login in AllowUsers fehlt. Auf dem Server nennt journalctl -u ssh -n 30 den Grund; Authentication refused: bad ownership or modes ist das oben beschriebene Rechteproblem.

Hostkey-Warnung

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED nach einer Neuinstallation ist zu erwarten: ssh-keygen -R SERVER_IP ausführen und erneut verbinden. Haben Sie nichts neu installiert, klären Sie die Ursache, bevor Sie irgendwo ein Passwort eingeben. Komplett ausgesperrt? Die Konsole des Anbieters ist der Weg zurück.

All das setzt eine Maschine voraus, auf der Sie root sind und es sich leisten können, sshd zu zerschießen und über eine Konsole zu reparieren. Ein Linux VPS von rdp.monster ist genau diese Maschine: voller Root-Zugriff, dedizierte CPU und RAM, unbegrenzte Bandbreite (Fair Use), kein KYC, Zahlung in Krypto oder Fiat, ab $8.99 pro Monat, und der Server ist rund 10 Sekunden nach Zahlungsbestätigung online. Das ist reichlich Zeit, die Schlüssel zu hinterlegen, bevor der erste Scanner Port 22 findet.

Häufig gestellte Fragen

Ist SSH unter Ubuntu standardmäßig aktiviert?

Ubuntu Desktop nicht; Ubuntu Server und die meisten Cloud-Images schon.

Ubuntu Desktop installiert nur den SSH-Client, es lauscht also nichts auf Port 22, bis Sie sudo apt install openssh-server ausführen. Ubuntu Server fragt während der Installation, ob der OpenSSH-Server eingerichtet werden soll, und kann dabei gleich Ihre Schlüssel von GitHub oder Launchpad importieren. Cloud- und VPS-Images bringen openssh-server fast immer installiert, aktiviert und verbindungsbereit mit, weil der Anbieter Ihnen die Maschine sonst gar nicht übergeben könnte. Prüfen Sie es mit systemctl status ssh.

Wie prüfe ich, ob SSH unter Ubuntu läuft?

systemctl status ssh ausführen und danach mit ss prüfen, ob Port 22 lauscht.

systemctl status ssh zeigt, ob der Dienst aktiv oder aktiviert ist. Da Ubuntu 22.10 und neuer Socket-Aktivierung nutzen, kann der Dienst völlig zu Recht inactive (dead) mit TriggeredBy: ssh.socket melden, solange niemand verbunden ist. Zuverlässiger ist deshalb sudo ss -tlnp | grep ssh: eine Zeile mit 0.0.0.0:22 oder [::]:22 bedeutet, dass SSH lauscht. Von einem anderen Rechner bestätigt ssh -v username@SERVER_IP das Ganze von Ende zu Ende.

Ist es sicher, SSH auf Port 22 zu lassen?

Ja, sofern Passwörter deaktiviert sind und Schlüssel genutzt werden; die Portnummer schützt nicht.

Port 22 zieht permanent automatisierte Anmeldeversuche an, doch gegen einen Server mit PasswordAuthentication no und einem Schlüsselpaar können diese Versuche nicht erfolgreich sein, und fail2ban beseitigt den Großteil des Rauschens. sshd auf 2222 oder 22222 zu verschieben verbirgt ihn nur vor den trägsten Scannern; Portscanner wie nmap und masscan finden ihn in Minuten, und weltweite Indizes listen ihn ohnehin. Behandeln Sie einen abweichenden Port als Maßnahme zur Log-Hygiene, nicht als Sicherheitskontrolle, und verzichten Sie nie auf Schlüssel, weil Sie den Port geändert haben.

Was ist der Unterschied zwischen ssh und sshd unter Ubuntu?

ssh ist das Client-Programm, sshd der Server-Daemon, dessen Ubuntu-Unit ssh heißt, mit sshd als Alias.

ssh ist der Client, den Sie auf Ihrem Laptop starten, um eine Verbindung zu öffnen; er stammt aus dem Paket openssh-client. sshd ist der Daemon, der auf dem Server antwortet, aus openssh-server, konfiguriert in /etc/ssh/sshd_config (der Client liest ssh_config). Ubuntu und Debian nennen die systemd-Unit ssh.service und deklarieren sshd.service als Alias, deshalb bewirken systemctl restart ssh und systemctl restart sshd dasselbe; unter Fedora, RHEL und Arch heißt die Unit schlicht sshd.