SSH Setup

1. Vorbereitung und Grundprinzip

Empfohlener Ablauf:

1. Über die STRATO-VNC-Konsole auf den Server zugreifen.
2. Temporär den SSH-Login per Benutzername und Passwort erlauben.
3. Einen normalen Benutzer mit sudo-Rechten anlegen.
4. SSH-Schlüssel erzeugen und den Public Key in authorized_keys hinterlegen.
5. Den Public-Key-Login in einer zweiten Sitzung testen.
6. Passwort- und Root-Login deaktivieren.

sudo apt update

sudo apt full-upgrade -y

sudo apt install -y openssh-server sudo nano vim

2. Zugriff über die STRATO-VNC-Konsole

Die VNC-Konsole im STRATO-Kundenbereich funktioniert unabhängig von einer fehlerhaften SSH-Konfiguration und ist deshalb der wichtigste Notfallzugang.

Die aktuelle SSH-Konfiguration vor Änderungen sichern:

sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

3. Editor-Grundlagen: nano und vim

nano zeigt die wichtigsten Tastenkombinationen permanent am unteren Bildschirmrand an und eignet sich für schnelle, kleine Änderungen. vim ist auf praktisch jedem Linux-System vorinstalliert (auch wenn eine SSH-Verbindung mal nicht klappt und nur die VNC-Konsole bleibt) und lohnt sich, weil er auch ohne Maus und Copy & Paste zuverlässig funktioniert.

Die drei Modi von vim

Anders als nano arbeitet vim modal – Tasten haben je nach Modus unterschiedliche Bedeutung:

• Normalmodus – Startzustand nach dem Öffnen. Hier navigiert man und ruft Befehle auf, es wird nichts eingegeben.
• Einfügemodus (Insert) – wird über i, a oder o aus dem Normalmodus gestartet, hier wird wie gewohnt Text getippt.
• Kommandozeilenmodus – über : aus dem Normalmodus erreichbar, für Speichern, Suchen/Ersetzen und Beenden.

sudo vim /etc/ssh/sshd_config
# Im Normalmodus:
#   /PasswordAuthentication   Enter   → springt zur Zeile
#   :s/PasswordAuthentication yes/PasswordAuthentication no/   Enter   → ersetzt nur in dieser Zeile
#   :wq   Enter   → speichern und beenden

4. Passwort-Login vorübergehend erlauben

Öffne die Hauptkonfiguration mit dem Editor deiner Wahl:

sudo nano /etc/ssh/sshd_config

# oder:
sudo vim /etc/ssh/sshd_config

Für die Übergangsphase sollten mindestens diese Werte gelten:

PasswordAuthentication yes
PubkeyAuthentication yes
PermitRootLogin no
KbdInteractiveAuthentication no
UsePAM yes

Was diese und weitere Direktiven bedeuten: siehe sshd_config-Referenz.

sudo grep -RniE '^(PasswordAuthentication|PubkeyAuthentication|PermitRootLogin|KbdInteractiveAuthentication)' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/ 2>/dev/null

sudo sshd -T | grep -E 'passwordauthentication|pubkeyauthentication|permitrootlogin|kbdinteractiveauthentication'

Vor dem Neustart immer die Syntax testen:

sudo sshd -t

sudo systemctl reload ssh

# Falls reload nicht funktioniert:
sudo systemctl restart ssh

5. Normalen Benutzer anlegen

sudo adduser USERNAME

sudo usermod -aG sudo USERNAME

id USERNAME

Ein direktes Arbeiten als root sollte vermieden werden – der Benutzer kann administrative Befehle später bei Bedarf mit sudo ausführen.

6. SSH-Schlüssel erzeugen

Empfohlen: Schlüssel lokal erzeugen

ssh-keygen -t ed25519 -a 100 -C "USERNAME@strato-vps"

Falls RSA zwingend erforderlich ist, mindestens 3072 Bit verwenden:

ssh-keygen -t rsa -b 4096 -o -a 100 -C "USERNAME@strato-vps"

ed25519 oder RSA – worin liegt der Unterschied?

Beide Verfahren erzeugen ein asymmetrisches Schlüsselpaar, unterscheiden sich aber im zugrunde liegenden mathematischen Verfahren – und dadurch in Schlüssellänge, Geschwindigkeit und Sicherheitsniveau:

Übergangslösung: Schlüssel auf dem VPS erzeugen

sudo -iu USERNAME

mkdir -p ~/.ssh

chmod 700 ~/.ssh

ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519

7. Public Key hinterlegen

Der Inhalt der Datei mit der Endung .pub gehört in ~/.ssh/authorized_keys des Zielbenutzers.

sudo -iu USERNAME

mkdir -p ~/.ssh

chmod 700 ~/.ssh

nano ~/.ssh/authorized_keys
# oder: vim ~/.ssh/authorized_keys

chmod 600 ~/.ssh/authorized_keys

chown -R USERNAME:USERNAME ~/.ssh

Bei lokal erzeugtem Schlüssel ist alternativ ssh-copy-id bequem:

ssh-copy-id -i ~/.ssh/id_ed25519.pub USERNAME@SERVER-IP

Dateien per scp übertragen

ssh-copy-id ist praktisch für genau einen Public Key. Für alle anderen Dateien – z. B. wenn ssh-copy-id lokal nicht verfügbar ist (etwa unter Windows) oder wenn Konfigurationen, Backups oder Projektdateien übertragen werden sollen – eignet sich scp. Es nutzt dieselbe Authentifizierung wie ssh, also ebenfalls den hinterlegten Public Key.

# Einzelne Datei hochladen:
scp -i ~/.ssh/id_ed25519 ./lokale-datei.txt USERNAME@SERVER-IP:/home/USERNAME/

# Ganzen Ordner hochladen (rekursiv, -r):
scp -r -i ~/.ssh/id_ed25519 ./lokaler-ordner USERNAME@SERVER-IP:/home/USERNAME/

# Einzelne Datei herunterladen:
scp -i ~/.ssh/id_ed25519 USERNAME@SERVER-IP:/home/USERNAME/entfernte-datei.txt ./

# Ganzen Ordner herunterladen (rekursiv, -r):
scp -r -i ~/.ssh/id_ed25519 USERNAME@SERVER-IP:/home/USERNAME/entfernter-ordner ./

Läuft sshd nicht auf Port 22, muss der Port bei scp mit großem -P angegeben werden (bei ssh dagegen kleines -p):

scp -P 2222 -i ~/.ssh/id_ed25519 ./lokale-datei.txt USERNAME@SERVER-IP:~/

8. Public-Key-Login testen

Den Test in einem neuen Terminal durchführen:

ssh -i ~/.ssh/id_ed25519 USERNAME@SERVER-IP

Für eine ausführliche Fehlerausgabe:

ssh -vvv -i ~/.ssh/id_ed25519 USERNAME@SERVER-IP

9. SSH wieder auf Public Key absichern

In /etc/ssh/sshd_config beziehungsweise einer eigenen Datei unter /etc/ssh/sshd_config.d/ setzen:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
PermitEmptyPasswords no
MaxAuthTries 3
X11Forwarding no

Optional kann der SSH-Zugriff auf bestimmte Benutzer begrenzt werden:

AllowUsers USERNAME

Danach erneut prüfen und neu laden:

sudo sshd -t

sudo sshd -T | grep -E 'passwordauthentication|pubkeyauthentication|permitrootlogin|kbdinteractiveauthentication'

sudo systemctl reload ssh

sudo systemctl status ssh --no-pager

10. sshd_config-Referenz: die wichtigsten Direktiven

Übersicht der praxisrelevanten Direktiven aus /etc/ssh/sshd_config über die bereits gesetzten Werte hinaus. Nicht gesetzte Direktiven verwenden den in sshd einkompilierten Standardwert – maßgeblich ist immer sudo sshd -T.

11. Public und Private Key per Fingerprint vergleichen

Aus einem privaten Schlüssel lässt sich der zugehörige Public Key ableiten – so lassen sich beide Dateien vergleichen, ohne den privaten Schlüssel offenzulegen.

ssh-keygen -lf ~/.ssh/id_ed25519.pub

ssh-keygen -y -f ~/.ssh/id_ed25519 | ssh-keygen -lf -

Für RSA entsprechend:

ssh-keygen -lf ~/.ssh/id_rsa.pub

ssh-keygen -y -f ~/.ssh/id_rsa | ssh-keygen -lf -

Fingerprint eines Eintrags in authorized_keys prüfen

ssh-keygen -lf ~/.ssh/authorized_keys

12. Häufige Fehler und Diagnose

Dateirechte prüfen

namei -l /home/USERNAME/.ssh/authorized_keys

sudo chmod 700 /home/USERNAME/.ssh

sudo chmod 600 /home/USERNAME/.ssh/authorized_keys

sudo chown -R USERNAME:USERNAME /home/USERNAME/.ssh

SSH-Protokoll ansehen

sudo journalctl -u ssh -n 100 --no-pager

sudo journalctl -u ssh -f

Port und Dienst prüfen

sudo ss -tulpn | grep ssh

sudo systemctl status ssh --no-pager

Host-Key-Warnung nach Neuinstallation

Wurde der VPS neu installiert und behält dieselbe IP-Adresse, kann der lokal gespeicherte Host-Key veraltet sein. Den Eintrag nur nach bewusster Prüfung entfernen:

ssh-keygen -R SERVER-IP

Serverseitige Host-Key-Fingerprints anzeigen:

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

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

13. Abschluss-Checkliste

• Systempakete aktualisiert
• Normaler Benutzer mit sudo angelegt
• Public-Key-Login getestet
• Privater Schlüssel sicher gespeichert
• PasswordAuthentication no
• PermitRootLogin no
• sshd -t ohne Fehler
• VNC-Notfallzugang bekannt
• SSH-Port in Firewall freigegeben
• Backup der ursprünglichen Konfiguration vorhanden