Florian WildeandClaude Opus 5.5
70a3cd2d28
- Woche 13 Linux-Grundlagen (B3, A6, LF9) - Woche 14 Betrieb und Ueberwachung (A8, A5, LF11) - Woche 15 Serviceanfragen bearbeiten (A1, A2, A5, LF6) - Woche 16 Vorbereitung auf Teil 1 (C3, C4, A10, LF2, LF5) 12 Handouts, 36 Merkkarten, 4 Praxisaufgaben, 3 Checklisten, 2 Lernzielkontrollen und eine Probepruefung Teil 1 (90 Minuten, 100 Punkte, eine durchgehende Fallsituation). Alle Rechenbeispiele nachgerechnet. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
64 lines
4.0 KiB
Markdown
64 lines
4.0 KiB
Markdown
---
|
||
id: S8
|
||
titel: Linux – Pakete, Dienste und Fernzugang per SSH
|
||
block: system
|
||
woche: 13
|
||
worum: Ein Linux-Server wird über drei Werkzeuge betrieben – den Paketmanager, systemd und SSH. Wer die drei beherrscht, kann fast jeden Server pflegen.
|
||
rahmenplan: [B3, A6, A8]
|
||
lernfeld: LF9
|
||
merksatz: apt für Software, systemctl für Dienste, journalctl für Protokolle, SSH nur mit Schlüssel. Zweite Sitzung offen lassen, bevor man den Zugang ändert.
|
||
karten:
|
||
- frage: Was ist der Unterschied zwischen systemctl start und systemctl enable?
|
||
antwort: start startet den Dienst jetzt, enable sorgt dafür, dass er bei jedem Systemstart mitstartet. systemctl enable --now erledigt beides auf einmal.
|
||
- frage: Warum meldet man sich per SSH mit Schlüssel statt mit Passwort an?
|
||
antwort: Ein Schlüssel lässt sich nicht erraten und nicht durch Durchprobieren knacken, und der private Teil verlässt nie den eigenen Rechner. Danach kann die Anmeldung per Passwort am Server ganz abgeschaltet werden.
|
||
- frage: Warum lässt man beim Ändern der SSH-Konfiguration eine zweite Sitzung offen?
|
||
antwort: Weil man sich mit einem Fehler in der Konfiguration aussperren kann. Die offene Sitzung bleibt bestehen, und man kann den Fehler darüber beheben, bevor man sie schließt.
|
||
---
|
||
|
||
## Das Wesentliche
|
||
|
||
- **Pakete (Debian, Ubuntu):** `sudo apt update` holt die Paketlisten, `sudo apt upgrade`
|
||
spielt Aktualisierungen ein, `sudo apt install nginx` installiert. Sicherheitsupdates lassen
|
||
sich mit `unattended-upgrades` automatisch einspielen.
|
||
- **Software nur aus den Paketquellen**, nicht per heruntergeladenem Skript, wenn es sich
|
||
vermeiden lässt. Was der Paketmanager kennt, aktualisiert er auch.
|
||
- **Dienste mit systemd:** `systemctl status nginx` zeigt Zustand und letzte
|
||
Protokollzeilen, `start`, `stop`, `restart` steuern, `enable` startet ihn beim Hochfahren mit.
|
||
- **Protokolle:** `journalctl -u nginx` für einen Dienst, `-f` zum Mitlesen, `-b` seit dem
|
||
letzten Start, `--since "1 hour ago"` für einen Zeitraum, `-p err` nur Fehler.
|
||
- **SSH-Schlüssel:** Auf dem eigenen Rechner `ssh-keygen -t ed25519` erzeugen, mit
|
||
`ssh-copy-id benutzer@server` hinterlegen. Der private Schlüssel bleibt beim Benutzer und
|
||
bekommt eine Passphrase.
|
||
- **SSH absichern** in `/etc/ssh/sshd_config`: `PermitRootLogin no`,
|
||
`PasswordAuthentication no`. Danach `sudo systemctl reload ssh` – und **in einer zweiten
|
||
Sitzung testen**, bevor die erste geschlossen wird.
|
||
- **Firewall:** `sudo ufw allow OpenSSH`, danach nur die Dienste freigeben, die gebraucht
|
||
werden, und `sudo ufw enable`. Mit `ss -tlnp` prüfen, was tatsächlich lauscht.
|
||
- **Neustart nach Kernel-Updates:** Ob einer nötig ist, zeigt unter Debian und Ubuntu die
|
||
Datei `/var/run/reboot-required`.
|
||
|
||
## Übersicht
|
||
|
||
| Aufgabe | Befehl |
|
||
|---|---|
|
||
| Aktualisieren | `sudo apt update && sudo apt upgrade` |
|
||
| Dienst starten und dauerhaft einschalten | `sudo systemctl enable --now nginx` |
|
||
| Läuft der Dienst? | `systemctl status nginx` |
|
||
| Warum startet er nicht? | `journalctl -u nginx -b --no-pager \| tail -n 30` |
|
||
| Schlüssel erzeugen und hinterlegen | `ssh-keygen -t ed25519` und `ssh-copy-id anna@srv-web-01` |
|
||
| Firewall-Zustand | `sudo ufw status verbose` |
|
||
|
||
## Prüfungsfrage
|
||
|
||
**Frage:** Ein frisch installierter Linux-Server soll per SSH verwaltet werden. Beschreiben Sie
|
||
die Schritte, mit denen Sie den Zugang absichern, in der richtigen Reihenfolge.
|
||
|
||
**Antwort:** (1) Einen persönlichen Benutzer mit `sudo`-Recht anlegen, damit nicht als root
|
||
gearbeitet wird. (2) Auf dem eigenen Rechner ein Schlüsselpaar erzeugen und den öffentlichen
|
||
Schlüssel mit `ssh-copy-id` für diesen Benutzer hinterlegen. (3) Die Anmeldung mit dem Schlüssel
|
||
testen. (4) In `sshd_config` die direkte Anmeldung als root und die Anmeldung per Passwort
|
||
abschalten und den Dienst neu laden. (5) In einer zweiten Sitzung prüfen, dass die Anmeldung
|
||
weiterhin funktioniert, bevor die erste geschlossen wird. (6) Die Firewall so einrichten, dass
|
||
SSH nur aus dem Verwaltungsnetz erreichbar ist, und automatische Sicherheitsupdates einschalten.
|