Erste SSH-Verbindung und SSH-Key einrichten

Warum SSH-Keys statt Passwort

Passwort-Logins haben drei Probleme, die Keys lösen:

• Brute-Force-Angriffe. Jeder von außen erreichbare SSH-Port wird permanent abgeklopft. Ein 8-Zeichen-Passwort fällt in Stunden, ein 12-Zeichen-Passwort in Tagen — Keys sind kryptographisch unangreifbar in jeder vertretbaren Zeit.
• Phishing und Tippspuren. Passwörter werden mitgeschrieben (Keylogger), abgegriffen (Phishing) oder im Terminal-Verlauf gespeichert. Keys werden nie übertragen — die Authentifizierung funktioniert per Challenge-Response, der private Schlüssel verlässt deinen Rechner nicht.
• Skalierung. Auf 20 Servern 20 verschiedene Passwörter pflegen ist unrealistisch — am Ende hat man überall dasselbe. Mit einem SSH-Key authentifiziert man sich auf allen Servern, der Zugang lässt sich pro Server individuell entziehen.

Best Practice: Nach erfolgreicher Key-Einrichtung deaktiviert man PasswordAuthentication in der sshd_config komplett. Das Wie steht im nächsten Kapitel (SSH-Hardening). Dieser Artikel kümmert sich erst einmal darum, dass der Key überhaupt funktioniert.

Schlüssel-Algorithmus wählen

OpenSSH unterstützt mehrere Algorithmen — drei sind in der Praxis relevant:

Praktische Konsequenz: ed25519 verwenden. Vorteile:

• Schnell zu erzeugen und zu verifizieren (keine Sekunden-Wartezeit wie bei RSA-4096).
• Sehr kurzer Public Key (~80 Zeichen statt ~750 bei RSA-4096) — passt in eine Zeile, leichter zu kopieren.
• Standardmäßig unterstützt von OpenSSH ≥ 6.5 (2014). Auch alle modernen Provider-Panels (Hetzner, Hostinger, Linode, Vultr, OVH …) akzeptieren ed25519 ohne Probleme.

RSA-4096 nur wenn man auf ein altes Gerät zugreifen muss, das ed25519 nicht spricht — z. B. ein Embedded-System oder ein sehr alter Router.

Schlüsselpaar erzeugen

Auf deinem lokalen Rechner (nicht auf dem Server!) erzeugst du das Schlüsselpaar mit ssh-keygen:

ssh-keygen -t ed25519 -C "max@beispielmail.de"

Erklärung der Parameter:

• -t ed25519 — Algorithmus.
• -C "max@beispielmail.de" — Kommentar, landet am Ende des Public Keys. Hilft später beim Identifizieren („welcher Key gehört zu welchem Rechner/Account?”). Üblich: E-Mail oder <benutzer>@<rechnername>.

ssh-keygen fragt nach:

1. Speicherort (Default: ~/.ssh/id_ed25519). Mit Enter bestätigen oder einen aussagekräftigen Pfad angeben, falls du mehrere Keys verwaltest — z. B. ~/.ssh/id_ed25519_privat und ~/.ssh/id_ed25519_arbeit.
2. Passphrase (optional, aber empfohlen — siehe Abschnitt 4).

Nach dem Lauf existieren zwei Dateien:

~/.ssh/id_ed25519        ← privater Schlüssel — niemals weitergeben
~/.ssh/id_ed25519.pub    ← öffentlicher Schlüssel — geht auf den Server

Privater Schlüssel verlässt deinen Rechner nicht. Wenn dich jemand bittet, ihn zu mailen oder hochzuladen, ist das immer ein Fehler oder ein Angriff. Geteilt wird ausschließlich die .pub-Datei.

Passphrase und ssh-agent

Beim Erzeugen fragt ssh-keygen nach einer Passphrase. Diese verschlüsselt den privaten Schlüssel auf der Festplatte — wer die Datei stiehlt, kann sie ohne Passphrase nicht nutzen.

Empfehlung: Passphrase setzen. Damit du sie nicht bei jeder SSH-Verbindung eingeben musst, kommt der ssh-agent ins Spiel: er hält den entschlüsselten Key im RAM, einmal pro Session.

ssh-add ~/.ssh/id_ed25519

Der ssh-agent läuft auf den meisten Desktops automatisch. Falls nicht (typisch unter minimalem Linux), startet ihn:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Auf macOS integriert sich der ssh-agent mit dem Keychain — die Passphrase wird einmal eingegeben und für alle weiteren Sessions gespeichert.

Kein Passphrase setzen ist eine bewusste Entscheidung — sinnvoll z. B. bei automatisierten CI/CD-Keys, die ein Skript ohne Interaktion nutzen muss. Privat und für Admin-Zugänge: immer Passphrase.

Public Key auf den Server bringen

Es gibt drei Wege, den Public Key auf den Server zu bekommen — der erste ist der sauberste.

Variante 1 — beim Provider hinterlegen (empfohlen)

Praktisch jeder VPS-Anbieter erlaubt, einen oder mehrere SSH-Keys im Web-Panel zu hinterlegen. Wenn du beim Bestellen oder vor dem ersten Boot deinen Public Key dort einträgst, ist er bereits beim ersten Server-Start in /root/.ssh/authorized_keys (bzw. dem Default-User) eingetragen — du kannst dich direkt per Key verbinden, ohne je ein Passwort zu sehen.

Dafür kopierst du den Inhalt der Public-Key-Datei in die Zwischenablage:

cat ~/.ssh/id_ed25519.pub

Ausgabe sieht so aus (eine Zeile):

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIM3xQ8...rB7p max@beispielmail.de

Diese Zeile fügst du komplett ins Provider-Panel ein.

Variante 2 — ssh-copy-id nach Passwort-Login

Wenn der Provider beim Bestellen ein Server-Passwort vergeben hat und keinen Key-Upload anbietet, ist der schnellste Weg:

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@203.0.113.42

ssh-copy-id verbindet sich einmal per Passwort, hängt deinen Public Key an ~/.ssh/authorized_keys an und setzt korrekte Dateirechte. Danach geht jede weitere Verbindung per Key.

Variante 3 — manuell

Wenn ssh-copy-id nicht verfügbar ist (selten, aber möglich auf Minimal-Systemen):

cat ~/.ssh/id_ed25519.pub | ssh root@203.0.113.42 \
    "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"

Funktional identisch — Key wird angehängt, Rechte gesetzt.

Erstverbindung und Host-Fingerprint

Beim ersten Verbinden zeigt SSH einen Fingerprint des Server-Schlüssels und fragt, ob du ihm vertraust:

The authenticity of host '203.0.113.42 (203.0.113.42)' can't be established.
ED25519 key fingerprint is SHA256:xKr7xC9wQ...uPq8.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Dieser Fingerprint identifiziert den Server eindeutig. Wenn du blind „yes” tippst, vertraust du jedem, der zu dem Zeitpunkt unter dieser IP antwortet — Man-in-the-Middle-Angriffe könnten damit unbemerkt bleiben.

Korrekt verifizieren: den Server-Fingerprint aus einer anderen Quelle prüfen — typischerweise aus dem Provider-Panel (viele Anbieter zeigen die Server-Fingerprints in der Server-Detail-Ansicht) oder direkt über die Server-Konsole (KVM-over-IP / Web-Console) per:

for f in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -lf "$f"; done

Wenn der angezeigte Fingerprint mit dem von SSH gemeldeten übereinstimmt, mit yes bestätigen. Der Fingerprint wird dann in ~/.ssh/known_hosts gespeichert — bei künftigen Verbindungen prüft SSH automatisch und meldet, falls sich der Fingerprint ändert (was ein Hinweis auf Reinstallation oder Angriff wäre).

~/.ssh/config — Aliases statt langer Befehle

Statt jedes Mal ssh -i ~/.ssh/id_ed25519 max@203.0.113.42 -p 22 zu tippen, hinterlege Aliases in ~/.ssh/config:

Host webserver
    HostName 203.0.113.42
    User max
    IdentityFile ~/.ssh/id_ed25519
    Port 22

Host db
    HostName 203.0.113.43
    User max
    IdentityFile ~/.ssh/id_ed25519

# Globale Defaults für alle Hosts
Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
    HashKnownHosts yes

Jetzt reicht:

ssh webserver

Die Host *-Sektion definiert globale Defaults. ServerAliveInterval 60 schickt alle 60 Sekunden ein Keep-Alive — verhindert, dass Firewalls die Verbindung als idle killen.

Tipp: Auch Tools wie scp, rsync und git (für SSH-Remotes) lesen ~/.ssh/config. Mit dem Alias funktionieren scp datei.txt webserver:/tmp/ und git clone webserver:/repo.git automatisch.

Dateirechte

OpenSSH ist bei Dateirechten strikt — zu offene Rechte führen zu schwer verständlichen Fehlern wie Permissions 0644 for '~/.ssh/id_ed25519' are too open. Korrekte Werte:

Korrigieren bei Bedarf:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519 ~/.ssh/authorized_keys ~/.ssh/config

Sicherheits-Checkliste

Bevor du Punkt für Punkt zum nächsten Bootstrap-Schritt gehst:

• Privater Schlüssel nie weitergegeben, kopiert oder hochgeladen
• Passphrase auf dem privaten Schlüssel gesetzt (oder bewusste Ausnahme dokumentiert)
• Public Key auf dem Server eingetragen, Login per Key erfolgreich getestet
• Host-Fingerprint beim ersten Verbinden gegen eine zweite Quelle verifiziert
• Dateirechte in ~/.ssh/ korrekt (700 / 600)
• ~/.ssh/config-Alias angelegt
• Bei mehreren Geräten: separate Keys pro Gerät, keine Key-Datei weiterkopieren — kompromittiertes Gerät lässt sich dann gezielt aussperren

Häufiger Anti-Pattern: denselben privaten Schlüssel auf Laptop, Desktop und Server liegen lassen, weil “der Schlüssel ja schon einmal funktioniert”. Damit ist jede Geräte-Kompromittierung gleich eine Komplett-Kompromittierung. Pro Gerät einen eigenen Schlüssel — alle Public Keys werden auf dem Server in authorized_keys gesammelt.

Verwandte Artikel

• Linux für den eigenen Server wählen — der Schritt davor
• SSH-Hardening — Passwort-Login deaktivieren, Port-Wechsel, fail2ban-Basics — direkt anschließend
• User und sudo anlegen — sobald der Key-Login funktioniert, Root-Zugang ablösen
• Linux-Doku: SSH-Konfiguration — Tiefen-Doku zu sshd_config und ssh_config

Externe Quellen

• OpenSSH Manpages — Referenz für ssh, ssh-keygen, sshd
• ssh.com — Public Key Authentication Explained — Hintergrund zur Funktionsweise
• Mozilla OpenSSH Guidelines — Best Practices für sichere SSH-Konfiguration
• Daniel J. Bernstein — Curve25519 — kryptographischer Hintergrund von ed25519