Aufgabe 05 - Schlüssel statt Passwort

Aufgabe 05 - Schlüssel statt Passwort

Worum geht es?

Sie schließen den Zugang zu Ihrem Server: Anmeldung nur noch über Schlüssel, keine Passwörter, kein root von außen (siehe Kapitel Server aufsetzen und härten). Der lehrreiche Teil ist nicht das Ändern der Konfiguration, sondern der Nachweis, dass sie tatsächlich wirkt. Die häufigste Härtung dieses Kapitels ist eine, die auf dem Papier steht und nichts bewirkt.

Was Sie dafür brauchen

• Kapitel Server aufsetzen und härten, Abschnitte Zugang über SSH und SSH abschließen.
• Ihren Server aus Aufgabe 04, ein Terminal und das Repository aus Aufgabe 03.
• Den Zugang zur Notfallkonsole Ihres Anbieters. Suchen Sie ihn heraus, bevor Sie beginnen.

Welche Kompetenzen Sie erwerben und zeigen

• Sie erzeugen ein SSH-Schlüsselpaar, hinterlegen den öffentlichen Teil und prüfen den Fingerprint des Servers.
• Sie härten den SSH-Zugang und weisen die Wirkung jeder Maßnahme mit einer Gegenprobe nach.
• Sie unterscheiden den beabsichtigten Zustand einer Konfiguration vom tatsächlich wirksamen.

Pädagogische Einordnung

• Reproduktion: Schlüssel erzeugen, hinterlegen und die Konfiguration nach Vorlage anpassen (Teil A).
• Reorganisation und Transfer: die Härtung durchführen, ohne sich dabei auszusperren (Teil B).
• Reflexion, Problemlösung und Urteilsbildung: die Wirkung belegen und Maßnahmen bewerten (Teil C).

Zwei Sitzungen, immer

Beim Ändern der SSH-Konfiguration bleibt die bestehende Sitzung offen, und die neue Konfiguration wird in einem zweiten Fenster getestet. Wer sich mit nur einer Verbindung aussperrt, kommt nicht mehr hinein. Legen Sie vor Teil B einen Snapshot an.

Arbeitsaufträge

Die Übung ist auf etwa zwei Stunden ausgelegt.

Teil A - Schlüssel und Identität

1. Erzeugen Sie auf Ihrem eigenen Rechner ein Schlüsselpaar mit ssh-keygen -t ed25519 -C "<YOUR_EMAIL@ADDRESS>" und vergeben Sie eine Passphrase. Notieren Sie die Namen der beiden entstandenen Dateien und dahinter, welche davon Ihren Rechner niemals verlässt.

2. Erklären Sie in drei bis vier Sätzen, wogegen die Passphrase schützt. Gehen Sie dabei von diesem Fall aus: Jemand nimmt Ihr Notebook an sich und liest die Datei mit dem privaten Schlüssel. Nennen Sie am Ende einen Fall, gegen den die Passphrase nichts ausrichtet.

3. Bringen Sie den öffentlichen Schlüssel mit ssh-copy-id auf den Server. Sehen Sie sich danach auf dem Server die Datei ~/.ssh/authorized_keys an und notieren Sie mit ls -la die Rechte der Datei und des Verzeichnisses ~/.ssh.

4. Vergleichen Sie den Fingerprint, den SSH beim ersten Verbindungsaufbau anzeigt, mit dem in der Cloud-Oberfläche Ihres Anbieters. Notieren Sie beide und erklären Sie in zwei Sätzen, wogegen diese Prüfung schützt.

5. Legen Sie in ~/.ssh/config einen Eintrag an, sodass ssh <name> für die Verbindung genügt. Notieren Sie den Eintrag mit allen vier Zeilen.

Teil B - Den Zugang abschließen

1. Legen Sie einen Snapshot Ihres Servers an. Notieren Sie Datum und Bezeichnung in docs/betrieb.md.

2. Legen Sie eine Arbeitskennung an und geben Sie ihr sudo-Rechte:

   sudo adduser deploy
   sudo usermod -aG sudo deploy

   Hinterlegen Sie Ihren öffentlichen Schlüssel auch für diese Kennung und melden Sie sich damit testweise an. Gehen Sie erst weiter, wenn das funktioniert.

3. Sichern Sie den Ausgangszustand mit diesem Befehl und heben Sie die Ausgabe auf. Sie ist das „Vorher” Ihres Nachweises und lässt sich später nicht rekonstruieren:

   sudo sshd -T | grep -Ei "permitrootlogin|passwordauth|kbdinteractive"

4. Setzen Sie in /etc/ssh/sshd_config diese fünf Einstellungen: PermitRootLogin no, PasswordAuthentication no, KbdInteractiveAuthentication no, PubkeyAuthentication yes und AllowUsers deploy.

5. Sehen Sie in das Verzeichnis /etc/ssh/sshd_config.d/. Auf Cloud-Images von Ubuntu liegt dort oft eine Datei wie 50-cloud-init.conf, die PasswordAuthentication yes enthält und die Hauptdatei überstimmt. Notieren Sie, ob es eine solche Datei gibt, was darin steht und wie Sie damit umgegangen sind.

6. Prüfen und übernehmen Sie die Konfiguration in einem Zug mit sudo sshd -t && sudo systemctl reload ssh. Melden Sie sich danach im zweiten Fenster neu an. Erst wenn das gelingt, schließen Sie die erste Sitzung.

Teil C - Nachweisen und bewerten

1. Rufen Sie den Befehl aus Teil B Punkt 3 erneut auf. Diese Ausgabe ist das „Nachher”.

2. Führen Sie drei Gegenproben durch und notieren Sie zu jeder den Befehl und die vollständige Antwort des Servers:

   • Passwortanmeldung erzwingen: ssh -o PubkeyAuthentication=no deploy@<server>
   • Anmeldung als root: ssh root@<server>
   • Anmeldung unter einer Kennung, die nicht in AllowUsers steht.

3. Schreiben Sie den Eintrag in docs/haertung.md nach dem Muster des Kapitels, mit Überschrift, Datum, Vorher, Maßnahme, Nachher und Gegenprobe.

4. Erklären Sie in drei bis vier Sätzen den Unterschied zwischen der Ausgabe von sshd -T und dem Inhalt von sshd_config. Beantworten Sie dabei, warum nur die erste als Nachweis taugt.

5. Kopieren Sie die geänderten Dateien aus /etc/ssh/ ins Repository und committen Sie sie.

6. Sehen Sie nach 24 Betriebsstunden ins Log. Notieren Sie aus sudo journalctl -u ssh --since "24 hours ago" | grep -i failed und sudo lastb | head -20 die Anzahl der Versuche und die fünf am häufigsten probierten Kennungen.

7. Beurteilen Sie in fünf bis sechs Sätzen, was die abgeschaltete Passwortanmeldung an diesen Zahlen ändert und was sie am Risiko ändert. Die beiden Antworten fallen unterschiedlich aus.

8. Ein häufiger Rat lautet, den SSH-Port von 22 auf einen anderen zu legen. Beurteilen Sie diesen Rat in drei bis vier Sätzen: Was ändert sich messbar an Ihrem Log, was ändert sich am Aufwand für einen Angreifer, und wie müssten Sie die Maßnahme in docs/haertung.md benennen, damit die Beschreibung ehrlich ist?

Wissenscheck

1. Welcher Teil des Schlüsselpaars liegt wo, und warum darf der private Teil den eigenen Rechner nie verlassen?
2. Wozu fragt SSH beim ersten Verbindungsaufbau nach dem Fingerprint, und was bewirkt ein unbesehenes „yes”?
3. Warum reicht PasswordAuthentication no allein nicht aus?
4. Warum können Dateien in sshd_config.d/ die Hauptkonfiguration aushebeln?
5. Was zeigt sshd -T, was sshd_config nicht zeigt?
6. Warum ist PermitRootLogin no auch dann sinnvoll, wenn ohnehin nur Schlüssel erlaubt sind?
7. Warum ist eine Härtungsmaßnahme ohne Gegenprobe im Zweifel nicht vorhanden?

Abgabe

Der Server ist ausschließlich per Schlüssel unter der Arbeitskennung erreichbar. In docs/haertung.md steht der vollständige Eintrag mit Vorher, Maßnahme, Nachher und den drei Gegenproben. In docs/betrieb.md stehen der Snapshot und alle Eingriffe dieser Übung. Die geänderten Dateien aus /etc/ssh/ liegen im Repository. Die Logzahlen und die Beurteilungen aus Teil C stehen in protokoll.md.