SSH-Zugang für vServer und Cloud-VPS
SSH-Keys sind ein wichtiger Bestandteil für den sicheren Zugang zu Deiner virtuellen Maschine. Im Gegensatz zu Passwörtern bieten SSH-Keys ein höheres Maß an Sicherheit. SSH-Keys bestehen aus einer Kombination von öffentlichen und privaten Schlüsseln, die eine sicherere Authentifizierung ermöglichen, die aufgrund der Länge der kryptografischen Schlüssel mit Brute-Force-Attacken nicht erraten werden können. Darüber hinaus ist der Login in den Root-Account per Passwort z.B. bei Ubuntu Server standardmäßig deaktiviert. Daher führen wir Dich in diesem Leitfaden Schritt für Schritt durch den Prozess, um SSH-Keys für den Zugriff auf Deine virtuelle Maschine zu nutzen.
Zugriff per SSH-Keys
Um ein neues Image auf einer virtuellen Maschine zu installieren und SSH-Keys darauf hinzuzufügen öffne die Konsole Deiner virtuellen Maschine und wähle den "Rebuild"-Tab. Hier kannst Du ein Image auswählen, beispielsweise Ubuntu Server in einer aktuellen Version. Klicke anschließend auf den Link "SSH-Key hinzufügen", um einen SSH-Key hinzuzufügen, sofern Du noch keinen SSH-Key angelegt hast. Füge Deinen SSH-Key in das bereitgestellte Feld ein. Falls Du noch keinen SSH-Key hast haben wir einen Leitfaden zur Erstellung von SSH-Keys.
Markiere die SSH-Keys, welche Zugriff auf die virtuelle Maschine haben sollen und starte den Rebuild.
Achtung: Bei diesem Prozess werden alle Daten auf der Festplatte Deiner virtuellen Maschine durch eine neue Installation ersetzt.
Nach dem Abschluss der Neuinstallation kannst Du eine SSH-Sitzung zum Server aufbauen ohne ein Passwort verwenden zu müssen.
Zugriff per root-Passwort
Wenn Du Root-Zugang per Passwort benötigst, richte ihn über die VNC-Konsole ein. Halte die Konsole während der gesamten Änderung geöffnet.
- Setze in der Verwaltung über Root-Passwort setzen ein starkes Passwort und melde Dich in der Konsole als
rootan. - Prüfe
/etc/ssh/sshd_configund die dort eingebundenen Dateien, insbesondere/etc/ssh/sshd_config.d/*.conf. Für die gewünschte Anmeldung müssen die wirksamen Werte lauten:
PermitRootLogin yes
PasswordAuthentication yes
OpenSSH verwendet für viele Optionen den zuerst gelesenen Wert. Eine früh eingebundene Datei kann deshalb Vorrang vor einer späteren Einstellung in der Hauptdatei haben. Auch Match-Blöcke oder AuthenticationMethods können den Zugang weiter einschränken. Ändere die maßgebliche Einstellung; füge nicht lediglich eine widersprechende Zeile am Dateiende hinzu.
Prüfe als Root die Syntax und die wirksamen Werte:
/usr/sbin/sshd -t
/usr/sbin/sshd -T | grep -E 'permitrootlogin|passwordauthentication|authenticationmethods'
Bei Match-Regeln prüfst Du zusätzlich die Werte für die konkrete Verbindung mit sshd -T -C user=root,addr=<Deine-Client-IP>,host=<Dein-Client-Hostname>; ersetze die Platzhalter.
Nur nach erfolgreicher Prüfung lädst Du den Dienst neu. Unter Ubuntu heißt er üblicherweise ssh, auf anderen Distributionen häufig sshd:
systemctl reload ssh
Teste die Anmeldung in einer zweiten Verbindung, bevor Du die Konsole schließt. Falls sie scheitert, prüfe das SSH-Journal und die weiteren Zugangsregeln. Für den dauerhaften Zugriff empfehlen wir SSH-Keys.
SSH ist nicht erreichbar
Wenn SSH nicht erreichbar ist, prüfe zuerst die einfachen Ursachen:
- Läuft die VM?
- Verwendest Du die richtige IP-Adresse oder den richtigen
trafficplex.cloud-Hostnamen? - Ist der SSH-Dienst im Betriebssystem aktiv?
- Blockiert die Firewall im Betriebssystem Port 22 oder Deinen geänderten SSH-Port?
- Verwendest Du den richtigen Benutzer und den richtigen privaten Schlüssel?
Wenn Du Dich durch eine Firewall-Regel ausgesperrt hast, öffne die VNC-Konsole in der Verwaltung. Dort kannst Du Dich lokal anmelden und die Regel korrigieren, zum Beispiel bei ufw:
ufw status verbose
ufw allow OpenSSH
SSH-Host-Keys prüfen
Beim ersten SSH-Login zeigt Dein SSH-Client den Fingerprint des Servers an. Dieser Fingerprint schützt davor, versehentlich mit einem falschen System verbunden zu werden.
Wenn Du eine VM neu installierst oder per Rebuild ersetzt, ändern sich die Host-Keys. Dein lokaler SSH-Client kann dann eine Warnung wie REMOTE HOST IDENTIFICATION HAS CHANGED anzeigen. Entferne in diesem Fall nur dann den alten Eintrag aus known_hosts, wenn Du bewusst ein Rebuild oder eine Neuinstallation durchgeführt hast.
Root-Login per Passwort wieder deaktivieren
Wenn Du Root-Login per Passwort nur zur Reparatur aktiviert hast, ändere danach die wirksame Einstellung wieder auf:
PermitRootLogin prohibit-password
Damit bleibt Root-Zugang mit einem SSH-Key möglich, Passwort- und interaktive Passwortanmeldung für Root werden ausgeschlossen. Wenn alle benötigten Benutzer nachweislich per SSH-Key erreichbar sind, kannst Du zusätzlich Passwortanmeldungen für alle Benutzer abschalten:
PasswordAuthentication no
KbdInteractiveAuthentication no
Beachte auch hierbei die Reihenfolge eingebundener Dateien und mögliche Match-Regeln wie oben beschrieben. Prüfe die Syntax mit /usr/sbin/sshd -t und die wirksamen Werte mit /usr/sbin/sshd -T, bevor Du systemctl reload ssh (bzw. sshd) ausführst. Halte eine aktive Sitzung oder die VNC-Konsole offen und teste den Schlüsselzugang in einer zweiten Verbindung.