11. SSH – Asymmetrische Authentifizierung in der Praxis

SSH ist das Werkzeug, mit dem ihr als Fachinformatiker*innen täglich auf Server zugreift. Statt eines Passworts, das abgefangen, erraten oder in Datenlecks gefunden werden kann, setzt ihr auf Schlüsselpaare – asymmetrische Kryptografie direkt in der Praxis. Dieser Block zeigt euch, wie ihr SSH richtig einrichtet und absichert.

Nach diesem Block könnt ihr:

  • den Ablauf der SSH-Schlüsselauthentifizierung erklären (Challenge-Response)
  • ein Ed25519-Schlüsselpaar generieren und auf einen Server übertragen
  • die SSH-Client-Konfiguration (~/.ssh/config) nutzen
  • einen SSH-Server mit sshd_config härten (Passwort-Login deaktivieren, Root-Login verbieten)
  • TOFU (Trust on First Use) erklären und Host-Key-Warnungen richtig einordnen

SSH-Schlüsselauthentifizierung

SSH (Secure Shell) ist das wichtigste Beispiel für asymmetrische Authentifizierung im Alltag der IT. Statt Passwort: Schlüsselpaar.

Client                                  Server
  │  Hat: Private Key                      │  Hat: Public Key des Clients
  │                                        │  (in ~/.ssh/authorized_keys)
  │──── Verbindungsaufbau ────────────────►│
  │                                        │  Schickt zufällige Challenge
  │◄─── Challenge ─────────────────────────│
  │                                        │
  │  Signiert Challenge mit Private Key    │
  │──── Signatur ─────────────────────────►│
  │                                        │  Verifiziert Signatur mit Public Key
  │◄─── Zugang gewährt ────────────────────│  Stimmt → Authentifizierung erfolgr.

SSH-Schlüssel mit OpenSSH

# Ed25519-Schlüsselpaar generieren (empfohlen, modern)
ssh-keygen -t ed25519 -C "max.mustermann@techwerk.de"
# -t:  Schlüsseltyp
# -C:  Kommentar (zur Identifikation des Schlüssels)
# → Speichert nach ~/.ssh/id_ed25519 (privat) und ~/.ssh/id_ed25519.pub (öffentlich)

# Alternativ: RSA mit 4096 Bit
ssh-keygen -t rsa -b 4096 -C "max.mustermann@techwerk.de"

# Public Key auf Server kopieren
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server.techwerk.intern
# → Fügt Public Key zu ~/.ssh/authorized_keys auf dem Server hinzu

# Verbinden mit Schlüssel
ssh -i ~/.ssh/id_ed25519 user@server.techwerk.intern

# Schlüssel-Fingerprint anzeigen
ssh-keygen -l -f ~/.ssh/id_ed25519.pub

# Alle geladenen Schlüssel im SSH-Agent anzeigen
ssh-add -l

Probiert es selbst:

  1. Generiert ein Ed25519-Schlüsselpaar: ssh-keygen -t ed25519 -C "test@schulung"
  2. Schaut euch beide Dateien an: cat ~/.ssh/id_ed25519 und cat ~/.ssh/id_ed25519.pub – was fällt auf?
  3. Prüft den Fingerprint: ssh-keygen -l -f ~/.ssh/id_ed25519.pub
  4. Falls ihr einen Testserver habt: Kopiert den Public Key mit ssh-copy-id und verbindet euch – werdet ihr nach einem Passwort gefragt?
  5. Erstellt einen Eintrag in ~/.ssh/config für den Server und testet die Kurzform

Schlüssel absichern

# Schlüsseldatei darf nur für den Besitzer lesbar sein
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 700 ~/.ssh/

# Passwort eines bestehenden Keys ändern
ssh-keygen -p -f ~/.ssh/id_ed25519

Known Hosts – Serverkennzeichnung beim ersten Verbinden

Beim ersten SSH-Verbindungsaufbau zu einem neuen Server erscheint folgende Meldung:

The authenticity of host 'server.techwerk.intern (10.0.0.5)' can't be established.
ED25519 key fingerprint is SHA256:abc123xyz...
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Was passiert hier: SSH kennt den Server noch nicht und fragt, ob dessen Host-Key vertrauenswürdig ist. Dieses Verfahren heißt TOFU (Trust on First Use) — beim ersten Verbinden wird vertraut, danach gespeichert.

Nach Bestätigung wird der Host-Key in ~/.ssh/known_hosts gespeichert:

# Inhalt der known_hosts anzeigen
cat ~/.ssh/known_hosts
# server.techwerk.intern ED25519 AAAA...

# Host-Key eines Servers prüfen (vor dem Verbinden, per sicherem Kanal vergleichen)
ssh-keyscan server.techwerk.intern 2>/dev/null | ssh-keygen -lf -

# Eintrag eines Servers aus known_hosts entfernen (z.B. nach Neuinstallation)
ssh-keygen -R server.techwerk.intern

Warum ist das sicherheitsrelevant? Ändert sich der Host-Key (z.B. nach Serverneubau oder bei einem MITM-Angriff), warnt SSH mit einer deutlichen Fehlermeldung:

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Diese Warnung nie einfach ignorieren und mit ssh-keygen -R wegklicken, ohne zu wissen warum. Ein geänderter Host-Key nach einer geplanten Serverneubau ist normal – ein geänderter Host-Key auf einem Server, den niemand angefasst hat, ist ein Alarmzeichen. Klärt das zuerst, bevor ihr die alte Zeile in known_hosts löscht.

Im Unternehmensumfeld werden Host-Keys über ein zentrales System verteilt, damit Mitarbeiter nicht bei jedem neuen Server blind bestätigen müssen.

SSH-Client-Konfiguration (~/.ssh/config)

Statt bei jedem Verbinden lange Befehle zu tippen, können Verbindungsprofile definiert werden:

# ~/.ssh/config

Host jumphost
    HostName 203.0.113.10
    User admin
    IdentityFile ~/.ssh/id_ed25519
    Port 2222

Host intern-server
    HostName 10.0.0.50
    User max
    IdentityFile ~/.ssh/id_ed25519
    ProxyJump jumphost          # Verbindung über Jumphost weiterleiten

Host *
    ServerAliveInterval 60      # Keepalive alle 60 Sekunden
    ServerAliveCountMax 3
# Verbinden mit Profil-Alias (statt vollem Befehl)
ssh intern-server
# entspricht: ssh -i ~/.ssh/id_ed25519 -J admin@203.0.113.10:2222 max@10.0.0.50

Typischer Denkfehler

„Ich kann den Private Key auf den Server kopieren, damit er dort auch verfügbar ist.” – Nein! Der Private Key verlässt niemals den Client. Auf den Server kommt ausschließlich der Public Key (in ~/.ssh/authorized_keys). Wer seinen Private Key per E-Mail verschickt oder auf einen Server kopiert, hat das Prinzip der asymmetrischen Authentifizierung nicht verstanden – und gefährdet die Sicherheit aller Systeme, auf denen dieser Key hinterlegt ist.

SSH-Server absichern (sshd_config)

Schlüsselbasierte Authentifizierung nützt wenig, wenn Passwort-Login daneben noch aktiv ist. Ein Angreifer versucht beides – und der schwächere Weg gewinnt. Die Server-Konfiguration liegt unter /etc/ssh/sshd_config. Folgende Einstellungen sind für eine sichere SSH-Konfiguration essenziell:

# /etc/ssh/sshd_config – wichtige Sicherheitseinstellungen

# Passwort-Login deaktivieren – nur Schlüssel erlaubt
PasswordAuthentication no

# Root-Login verbieten – immer mit normalem User + sudo arbeiten
PermitRootLogin no

# Nur bestimmte Benutzer dürfen sich einloggen
AllowUsers max admin

# Leerlauf-Timeout (Verbindung wird nach 5 Minuten ohne Aktivität getrennt)
ClientAliveInterval 300
ClientAliveCountMax 1

# Maximale Fehlversuche beim Login
MaxAuthTries 3
# Konfiguration auf Syntaxfehler prüfen (vor dem Neustart!)
sudo sshd -t

# SSH-Dienst neu starten (Änderungen übernehmen)
sudo systemctl restart sshd

# SSH-Dienst-Status prüfen
sudo systemctl status sshd

Merke: PasswordAuthentication no ist eine der wichtigsten Härtungsmaßnahmen für SSH-Server. Passwort-Logins sind anfällig für Brute-Force — SSH-Schlüssel nicht. Stellt unbedingt sicher, dass euer Schlüssel in ~/.ssh/authorized_keys eingetragen ist, bevor ihr die Sitzung schließt. Sonst sperrt ihr euch selbst aus.

Zusammenfassung

  • SSH-Schlüsselauthentifizierung nutzt Challenge-Response: Der Server schickt eine Zufallszahl, der Client signiert sie mit seinem Private Key
  • Ed25519 ist der empfohlene Schlüsseltyp – schnell, sicher, kurze Schlüssel
  • Der Private Key bleibt immer auf dem Client; nur der Public Key kommt auf den Server
  • TOFU (Trust on First Use): Beim ersten Verbinden wird dem Host-Key vertraut und gespeichert – ändert er sich später, ist das ein Warnsignal
  • Härtung: PasswordAuthentication no und PermitRootLogin no in sshd_config sind Pflicht

Selbsttest

  1. Beschreibt den Authentifizierungsablauf bei SSH in drei Schritten (Challenge → Signatur → Verifikation).
  2. Ein Kollege generiert ein Schlüsselpaar und schickt euch den Private Key per E-Mail. Was ist daran falsch?
  3. Nach einem Serverwechsel erscheint die Warnung „REMOTE HOST IDENTIFICATION HAS CHANGED”. Was prüft ihr, bevor ihr den Eintrag löscht?

Wie geht es weiter?

SSH-Schlüssel sind starke Authentifizierung – aber was, wenn der Private Key gestohlen wird? Ein zweiter, unabhängiger Faktor macht den Unterschied. Block 11 behandelt 2FA und MFA: von TOTP-Apps bis zu phishing-resistenten Hardware-Tokens.