Aufgabe 2 – SSH-Härtung eines Produktionsservers

Aufgaben – Verschlüsselung in der Praxis

Diese Aufgaben orientieren sich am Format und Anforderungsniveau der IHK-Abschlussprüfung für Fachinformatiker. Jede Aufgabe beschreibt eine realistische Arbeitssituation und enthält mehrere Teilaufgaben mit unterschiedlichen Aufgabentypen (Erklären, Auswählen, Planen, Bewerten).

Aufgabe 2 – SSH-Härtung eines Produktionsservers (16 Punkte)

Handlungssituation: Ihr seid als Fachinformatiker*innen bei der Techwerk GmbH tätig. Ein Linux-Produktionsserver (db-prod-01) ist bisher nur per Passwort über SSH erreichbar. Nach einem Sicherheitsaudit sollt ihr die SSH-Authentifizierung auf Schlüsselbasis umstellen und den Server härten.

Teilaufgabe 2a (4 Punkte)

Beschreibt den Authentifizierungsablauf bei der SSH-Schlüsselauthentifizierung. Geht dabei auf folgende Elemente ein:

Wo liegt der Public Key?
Wo liegt der Private Key?
Was passiert bei der Authentifizierung (Challenge/Response)?

Teilaufgabe 2b (2 Punkte)

Ein Kollege generiert ein Schlüsselpaar und schickt euch den Private Key per E-Mail, damit ihr ihn auf dem Server eintragt.

Erklärt, warum dieses Vorgehen falsch ist, und beschreibt das korrekte Vorgehen in einem Satz.

Teilaufgabe 2c (4 Punkte)

Ihr führt folgende Befehle auf dem Client aus:

ssh-keygen -t ed25519 -C "admin@techwerk.de"
ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@db-prod-01

a) Warum wird ed25519 gegenüber rsa mit 2048 Bit empfohlen?

b) Was bewirkt ssh-copy-id konkret auf dem Zielsystem?

Teilaufgabe 2d (4 Punkte)

Nach der Umstellung soll die Passwortanmeldung deaktiviert werden. Ergänzt die fehlenden Werte in der sshd_config:

Parameter	Korrekter Wert	Begründung
`PasswordAuthentication`	???	Passwortanmeldung verbieten
`PermitRootLogin`	???	Direktes Root-Login über SSH verbieten
`PubkeyAuthentication`	???	Schlüsselauthentifizierung explizit erlauben

Teilaufgabe 2e (2 Punkte)

Am nächsten Morgen erscheint folgende Fehlermeldung beim Verbindungsversuch:

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

Nennt zwei mögliche Ursachen für diese Meldung und beschreibt, was vor dem Löschen des alten Eintrags aus known_hosts zu prüfen ist.

Musterlösungen

Aufgabe 2a: Der Public Key liegt auf dem Server in ~/.ssh/authorized_keys. Der Private Key bleibt ausschließlich beim Client (~/.ssh/id_ed25519). Bei der Authentifizierung schickt der Server eine zufällige Challenge. Der Client signiert diese Challenge mit seinem Private Key. Der Server prüft die Signatur mit dem hinterlegten Public Key. Nur wer den passenden Private Key besitzt, kann die Challenge korrekt signieren.

Aufgabe 2b: Das Vorgehen ist falsch, weil der Private Key den Client niemals verlassen darf. Der Kollege muss seinen eigenen Public Key (id_ed25519.pub) übermitteln, der dann auf dem Server in authorized_keys eingetragen wird – nicht den Private Key.

Aufgabe 2c: a) Ed25519 basiert auf Elliptic Curve Cryptography und bietet bei 256-Bit-Schlüsseln ein vergleichbares Sicherheitsniveau wie RSA mit 3000+ Bit, ist schneller bei der Signierung und gilt als sicherer gegenüber bestimmten Seitenkanal-Angriffen. b) ssh-copy-id kopiert den angegebenen Public Key automatisch in die Datei ~/.ssh/authorized_keys auf dem Zielsystem und setzt dabei die korrekten Dateirechte (700 für .ssh, 600 für authorized_keys).

Aufgabe 2d: PasswordAuthentication no / PermitRootLogin no / PubkeyAuthentication yes

Aufgabe 2e: Mögliche Ursachen: (1) Der Server wurde neu aufgesetzt oder das SSH-Host-Keypaar wurde neu generiert. (2) Ein Man-in-the-Middle-Angriff findet statt. Vor dem Löschen des Eintrags muss der korrekte Host-Key-Fingerprint über einen sicheren Kanal verifiziert werden (z. B. Telefonat mit dem Serveradministrator oder Vergleich direkt am Server).