ghostnet.ai/infrastructure
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add: DNS über Pi-Hole LXC. Härtung von CT-105 Wireguard.

Browse Source
This commit is contained in:
spektr
2026-10-05 17:45:38 +02:00
parent 0758813e63
commit b40f726d22
26 changed files with 1014 additions and 158 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/platform/llm-server/host/GNAI-002-INFRA_BaseSystem.md
+159
View File
@@ -0,0 +1,159 @@
# Ghostnet.AI-Host – Basisinstallation
**Dokumenten-ID:** GNAI-002-INFRA
**Titel:** Initialisierung und OS-Installation des KI-Hosts `10.0.0.90`
**Status:** Installationsanleitung mit lesendem Teilabgleich; vollständige Abnahme offen
**Referenzen:** -
---
## Änderungsverlauf
| Datum | Version | Autor | Beschreibung der Änderung |
| --- | --- | --- | --- |
| 2026-08-24 | 1.0 | spektr | Erstellung des Initial-Dokuments (Hardware & OS) |
| 2026-08-24 | 1.1 | spektr | Detaillierung der BIOS-ReBAR-Settings, Netinst-CLI-Schritte, Post-Installation & Abnahmekriterien hinzugefügt. |
| 2026-09-16 | 1.2 | spektr | Benutzer- und Netzwerkaufgaben nach GNAI-003 verlagert; ungesicherte Downloadpfade und Domainvorgabe entfernt. |
| 2026-09-18 | 1.3 | spektr | GPU-Abnahme auf nachweisbare Geräteerkennung begrenzt; Firmwarepaket präzisiert. |
| 2026-09-19 | 1.4 | spektr | Getrennte SSH-Zugänge für `ghost` und `ghost-agent` als erfolgreich getestet übernommen. |
| 2026-09-22 | 1.5 | Codex | In die hostbezogene Struktur `platform/ghostnet-ai/` verschoben und Geltungsbereich präzisiert. |
---
## 1. Zweck und Geltungsbereich
Dieses Dokument beschreibt Hardware, BIOS und Debian-Installation des KI-Servers. Benutzer, statische Netzkonfiguration und SSH-Härtung werden in [GNAI-003](GNAI-003-INFRA_Users.md) eingerichtet. Die Schritte sind eine Anleitung, kein Nachweis ihrer Ausführung auf dem bestehenden Host.
---
## 2. Spezifikationen (Hardware-Konfiguration)
| Komponente | Spezifikation | Bemerkung |
| --- | --- | --- |
| **Gehäuse** | Silverstone SST-RM42-502 | Rackmount / Server-Chassis |
| **Mainboard** | ASRock Z790 PG Lightning | Socket LGA1700 |
| **CPU** | Intel Core i5-13600K | 14 Kerne (6P + 8E) |
| **CPU-Kühler** | Thermalright Peerless Assassin 120 Mini | - |
| **RAM** | Crucial Pro DDR5 RAM 64GB Kit (2x32GB) | Dimm Slot A2 & B2 |
| **PSU** | Corsair RM1200e | 1200W ATX 3.0 |
| **SSD** | 2 TB Samsung 970 EVO Plus | Primäre NVMe (Slot M2_1) |
| **GPU 1** | Sapphire Nitro+ AMD Radeon RX 6900 XT OC 16GB | PCIe Slot 1 (x16) |
| **GPU 2** | Sapphire Nitro+ AMD Radeon RX 6900 XT OC 16GB | PCIe Slot 2 (x8/x4 via PCH) |
### 2.1 BIOS-Konfiguration
Vor der Betriebssystem-Installation sind folgende Schritte im BIOS (Aufrufen via `DEL` oder `F2` beim Booten) durchzuführen:
1. **Firmware-Update (Instant Flash):**
* BIOS-Datei auf einen FAT32-formatierten USB-Stick entpacken.
* Im BIOS navigieren zu: `Tool` -> `Instant Flash`.
* BIOS-Version auf **`19.02`** (oder neuer) aktualisieren.
2. **RAM-Performance:**
* Navigieren zu: `OC Tweaker` -> `DRAM Configuration`.
* **Load XMP Setting:** auf **XMP Profile 1** stellen.
3. **Virtualisierung & PCI-Einstellungen (Wichtig für GPU/ROCm):**
* Navigieren zu: `Advanced` -> `CPU Configuration` -> **Intel Virtualization Technology** -> `Enabled`.
* Navigieren zu: `Advanced` -> `PCI Configuration`:
* **Above 4G Decoding:** `Enabled`
* **Re-Size BAR Support:** `Enabled`; tatsächliche GPU-Zuordnung nach der Installation prüfen. Aus der BIOS-Option allein folgt noch kein nachgewiesener ROCm-Leistungsgewinn.
---
## 3. Installation des Betriebssystems
### 3.1 Vorbereitung des Installationsmediums (am Admin-PC)
1. **Debian ISO herunterladen:** Die gewünschte Debian-Version und die passende `amd64`-Netinst-ISO auf [Debian CD Images](https://cdimage.debian.org/debian-cd/) auswählen. ISO und `SHA512SUMS` aus demselben Release-Verzeichnis herunterladen; Dateinamen nicht aus dieser Anleitung ableiten.
2. **Checksum verifizieren:**
```bash
sha512sum --ignore-missing -c SHA512SUMS
```
Erwartet wird eine `OK`-Zeile für die tatsächlich heruntergeladene ISO. Bei einem Fehler Download und Prüfsummenquelle kontrollieren.
3. **Bootfähigen USB-Stick erstellen:**
* [Ventoy](https://www.ventoy.net) auf dem USB-Stick installieren.
* Die heruntergeladene ISO-Datei direkt per Dateimanager auf die Ventoy-Partition kopieren.
---
### 3.2 Schritt-für-Schritt Installationsanleitung (Debian Netinst)
1. **Booten:**
* USB-Stick einstecken, System starten und per `F11` das Boot-Menü öffnen.
* USB-Stick auswählen -> Im Ventoy-Menü `debian-netinst.iso` wählen -> **Graphical Install** auswählen.
2. **Lokalisierung:**
* **Language:** `German - Deutsch`
* **Land/Territorium:** `Deutschland`
* **Tastaturlayout:** `Deutsch`
3. **Netzwerk & Hostname:**
* **Hostname:** `ghostnet-ki` (auf dem bestehenden KI-Server am 18.09.2026 per `hostnamectl` bestätigt).
* **Domain-Name:** Nur eine tatsächlich konfigurierte lokale Domain eintragen; andernfalls leer lassen. `ghostnet.ki` ist in dieser Dokumentation lediglich ein optionaler SSH-Alias.
* **Netzwerk:** Per DHCP konfigurieren lassen. *(Feste IP wird nach der Installation vergeben).*
4. **Benutzerverwaltung:**
* **Root-Passwort:** Starkes Passwort aus dem Passwort-Manager eintragen.
* **Neuer Benutzer:**
* Vollständiger Name: `Admin`
* Benutzername: vor der Installation festlegen. Der bestehende KI-Server verwendet `ghost` als initiales Administrationskonto; `admin` ist dort nicht vorhanden.
* Passwort: Sicheres Kennwort vergeben.
5. **Partitionierung (Manuell / Geführt):**
* Methode: `Geführt - gesamte Festplatte verwenden`.
* Disk auswählen: `Samsung SSD 970 EVO Plus 2TB`.
* Schema: `Alle Dateien auf eine Partition (für Anfänger empfohlen)`.
* **Wichtig:** Änderungen auf die Festplatte schreiben -> `Ja`.
6. **Paketmanager-Konfiguration:**
* Spiegelserver-Land: `Deutschland`
* `deb.debian.org` wählen.
* HTTP-Proxy: Leer lassen.
7. **Software-Auswahl (Software selection):**
* [_] Debian desktop environment *(ABWÄHLEN)*
* [_] GNOME / KDE / etc. *(ABWÄHLEN)*
* [x] **SSH server** *(AUSWÄHLEN)*
* [x] **standard system utilities** *(AUSWÄHLEN)*
8. **Bootloader (GRUB):**
* GRUB-Bootloader in den primären Laufwerksbereich installieren: `Ja`
* Gerät wählen: `/dev/nvme0n1` (Samsung SSD).
9. **Abschluss:**
* USB-Stick entfernen und auf `Weiter` klicken, um das System neu zu starten.
---
### 3.3 Grundlegende Werkzeuge und Firmware
Für die AMD-GPUs ist in Debian 13 das Paket [`firmware-amd-graphics`](https://packages.debian.org/trixie/firmware-amd-graphics) aus `non-free-firmware` vorgesehen. Das breitere Metapaket `firmware-linux-nonfree` zieht dieses Paket bereits als Abhängigkeit nach sich und wird für diesen Schritt nicht zusätzlich benötigt. Die folgende Anweisung gehört zu einer Neuinstallation oder zum späteren Ansible-Sprint, nicht zu diesem Dokumentationsabgleich:
```bash
# Vorher prüfen, ob die Debian-Paketquellen die Komponente non-free-firmware enthalten.
apt update
apt install -y curl wget git htop tmux pciutils firmware-amd-graphics
```
Für Sudo, Netzwerk und SSH mit [GNAI-003](GNAI-003-INFRA_Users.md) fortfahren. Vor Änderungen auf einem laufenden Host die dort dokumentierte Netzverwaltung prüfen.
---
## 4. Abnahmekriterien
Vor der Übergabe an das KI-Team (Phase 2) muss das System folgende Punkte bestehen:
* **RAM-Check:** `free -h` zeigt mindestens ~62 GB RAM an.
* **GPU-Erkennung:** `lspci -nn | grep -Ei 'vga|display|3d'` listet **zwei** AMD-Grafikgeräte auf. Das genaue Kartenmodell anhand des Hardwareinventars oder der Geräte selbst prüfen; die PCI-Familienkennung allein genügt dafür nicht.
* **Netzwerk:** Der Server ist nach GNAI-003 unter `10.0.0.90` erreichbar. Die getrennten SSH-Zugänge für `ghost` und `ghost-agent` wurden am 19.09.2026 erfolgreich getestet.
* **Storage:** `lsblk -f` zeigt die vorgesehene Partitionierung der 2-TB-SSD; `df -h /` zeigt die nutzbare Dateisystemgröße (in binären Einheiten kleiner als 2 TB).
* **Re-Size BAR:** BIOS-Einstellung und zugewiesene PCIe-BAR-Größen getrennt prüfen; ein bloßer `dmesg | grep -i BAR`-Treffer gilt nicht als Funktions- oder Leistungsnachweis.
---
## 5. Lesender Teilabgleich des bestehenden Hosts am 18.09.2026
Per SSH wurden Debian 13.6, Hostname `ghostnet-ki`, Intel Core i5-13600K, 62 GiB nutzbarer RAM und zwei AMD Navi-21-GPUs mit PCI-ID `1002:73bf` beobachtet. `lsblk` zeigt eine 1,8-TiB-NVMe mit EFI-, ext4-Root- und Swap-Partition; `df -h /` zeigte 1,8 TiB Dateisystemgröße. `lspci` bestätigt die Gerätefamilie, aber weder das genaue Kartenmodell noch ROCm-Funktion und ReBAR-Leistung. BIOS-Version, XMP, Firmwarestand und Restore wurden nicht geprüft.
docs/platform/llm-server/host/GNAI-003-INFRA_Users.md
+206
View File
@@ -0,0 +1,206 @@
# Ghostnet.AI-Host – Benutzer, Netzwerk und SSH
**Dokumenten-ID:** GNAI-003-INFRA
**Titel:** Benutzer-, Netzwerk- und SSH-Sicherheitsarchitektur des KI-Hosts `10.0.0.90`
**Status:** Betriebsanleitung; tatsächliche Netzverwaltung und Konten vor Anwendung prüfen
---
## Änderungsverlauf
| Datum | Version | Autor | Beschreibung der Änderung |
| --- | --- | --- | --- |
| 2026-08-26 | 1.0 | spektr | Erstellung des Dokuments (Benutzer, Netzwerkkonfiguration, SSH-Härtung) |
| 2026-09-15 | 1.1 | spektr | Kontenbestand, DNS-Verwaltung und SSH-Dienstnamen präzisiert; doppelte Basisschritte bereinigt. |
| 2026-09-16 | 1.2 | spektr | Tatsächliche Konten, Gruppen, Netz- und SSH-Konfiguration sowie Grenzen des Login-Tests dokumentiert. |
| 2026-09-18 | 1.3 | spektr | Workstation-spezifische Schlüsselpfade und Host-Fingerprint in den lokalen Arbeitskontext verlagert. |
| 2026-09-19 | 1.4 | spektr | Persönlichen Login `ghost` und Agentenlogin `ghost-agent` als erfolgreich getestet dokumentiert. |
| 2026-09-20 | 1.5 | spektr / Codex | Deployment- und getrennte rootless Workload-Konten mit festen IDs und Zuständigkeiten ergänzt. |
| 2026-09-20 | 1.6 | spektr / Codex | `render`-Mitgliedschaft und geprüfte AMD-Geräterechte der beiden KI-Konten ergänzt. |
| 2026-09-22 | 1.7 | Codex | In die hostbezogene Struktur `platform/ghostnet-ai/` verschoben und Geltungsbereich präzisiert. |
---
## 1. Zweck und Geltungsbereich
Dieses Dokument beschreibt Benutzer, statische IP und SSH des KI-Servers. Der ursprüngliche lesende Kontenabgleich vom 18.09.2026 umfasste `ghost`, `debugofen` und `ghost-agent`; `admin` existiert auf diesem Host nicht. Am 19. und 20.09.2026 kamen der Ansible-Deployment-Account sowie drei gesperrte Workload-Konten hinzu. Die folgenden Befehle sind für Neuinstallation oder gezielte Änderung gedacht und ersetzen keine Prüfung des vorhandenen Systems. Der WireGuard-LXC besitzt ein separates Konto `admin`.
---
## 2. Voraussetzungen & Berechtigungen
* Bereits installiertes Debian-Grundsystem gemäß [GNAI-002](GNAI-002-INFRA_BaseSystem.md).
* Root-Zugriff oder Benutzer mit `sudo`-Rechten.
* Admin-Workstation mit lokal installierter SSH-Suite (`ssh`, `ssh-keygen`); für den bestehenden Host ist die lokale Konsole oder ein bereits berechtigter Zugang zur Schlüsselaufnahme nötig.
---
## 3. Prozessbeschreibung
### 3.1 Benutzerverwaltung & Sudo-Berechtigungen (Server-Seite)
#### 1. Sudo-Paket installieren & prüfen (falls noch nicht geschehen)
Als `root` am Server anmelden:
```bash
su -
apt update && apt install -y sudo
```
#### 2. Benutzer anlegen & Berechtigungen vergeben
Vor dem Anlegen prüfen, ob das Konto bereits existiert (`getent passwd <username>`). Konten und Home-Verzeichnisse nur nach Prüfung ihrer Daten und Berechtigungen entfernen.
Nur bei einer **Neuinstallation** einen vorher festgelegten Administrationsbenutzer anlegen und zur `sudo`-Gruppe hinzufügen. Auf dem bestehenden KI-Server besitzen `ghost` und `debugofen` bereits sudo-Gruppenmitgliedschaft. Das folgende Beispiel mit `ghost` dort nicht ausführen:
```bash
# Nur auf einem neuen System ausführen.
sudo adduser ghost
sudo usermod -aG sudo ghost
```
Weitere Konten nur nach Rollenentscheidung anlegen. Die sudo-Gruppenmitgliedschaft ist pro Konto ausdrücklich festzulegen; auf dem bestehenden Host keine bereits vorhandenen Konten erneut anlegen.
Die folgenden technischen Konten werden ausschließlich durch das
Ansible-Projekt verwaltet:
| Konto | UID/GID | Zweck | interaktiver Login / sudo |
| --- | --- | --- | --- |
| `ansible-deploy` | 1003 | privilegierte Ansible-Ausführung | SSH-Key, gesperrtes Passwort, `NOPASSWD` gemäß eigener sudoers-Regel |
| `gnai-production` | 980 | rootless AI Production | gesperrtes Passwort, `/usr/sbin/nologin`, kein sudo |
| `gnai-testing` | 981 | rootless AI Testing | gesperrtes Passwort, `/usr/sbin/nologin`, kein sudo |
| `gn-encoding` | 982 | rootless CPU-Encoding | gesperrtes Passwort, `/usr/sbin/nologin`, kein sudo |
Die drei Workload-Konten besitzen nicht überlappende SubUID-/SubGID-Bereiche,
eigene Daten- und Podman-Stores sowie persistente systemd-User-Manager. Ihre
rootverwalteten Quadlet-Verzeichnisse liegen unter
`/etc/containers/systemd/users/<UID>`. Direkte SSH-Schlüssel werden dort nicht
hinterlegt. `gnai-production` und `gnai-testing` gehören zusätzlich zur
Gerätegruppe `render`; `gn-encoding` erhält keinen GPU-Zugriff.
---
### 3.2 Statische Netzwerkkonfiguration (Server-Seite)
#### 1. Netzschnittstelle ermitteln & anpassen
Primäre Netzwerkschnittstelle und zuständigen Netzwerkdienst ermitteln (z. B. `enp8s0`):
```bash
ip addr show
systemctl is-active networking NetworkManager systemd-networkd dhcpcd
```
Nur falls `ifupdown` den Host tatsächlich verwaltet, `/etc/network/interfaces` bearbeiten. Bei NetworkManager, systemd-networkd oder dhcpcd deren Konfiguration verwenden; die Schnittstelle darf nicht von mehreren Diensten zugleich verwaltet werden.
```bash
sudo nano /etc/network/interfaces
```
Netzwerkkonfiguration für statische IP eintragen:
```text
# Loopback Interface
auto lo
iface lo inet loopback
# Primary Network Interface
allow-hotplug enp8s0
iface enp8s0 inet static
address 10.0.0.90/24
gateway 10.0.0.1
dns-nameservers 10.0.0.1 1.1.1.1
```
#### 2. DNS-Resolver prüfen
`/etc/resolv.conf` kann von einem Netzwerk- oder Resolverdienst erzeugt werden. Den aktiven Dienst und die wirksamen Nameserver prüfen (`readlink -f /etc/resolv.conf`, `cat /etc/resolv.conf`); Änderungen in dessen Konfiguration vornehmen. Die aktuelle Solladresse des Heimnetz-DNS ist `10.0.0.1`.
#### 3. Netzwerkdienst neustarten & Funktion prüfen
```bash
sudo systemctl restart networking # nur bei ifupdown und mit Konsolenzugang
ip -4 addr
ping -c 4 google.com
```
Vor einem Remote-Neustart einen Rückweg über Konsole/Proxmox sicherstellen. Ein Reboot behebt keine widersprüchliche Netzkonfiguration.
---
### 3.3 SSH-Schlüssel und getrennte Konten
Für persönliche und automatisierte Zugriffe getrennte Konten und klar benannte Schlüsselpaare verwenden. Auf dem bestehenden KI-Server sind `ghost` und `ghost-agent` getrennt; `ghost-agent` hat keine sudo-Gruppenmitgliedschaft. Schlüsseldateien, lokale SSH-Aliase und der auf dieser Workstation bekannte Hostschlüssel-Fingerprint sind nur im lokalen, nicht versionierten Arbeitskontext vermerkt. Private Schlüssel und Passphrasen gehören weder in diese Dokumentation noch in ein Serverinventar. Ein Kommentar wie `@ghostnet-ki` im Public Key ist nur ein Label; die Zuordnung erfolgt über den Schlüsselinhalt und das jeweilige `authorized_keys`.
Neue öffentliche Schlüssel auf dem bestehenden Host über eine bereits berechtigte Sitzung oder die lokale Konsole in das **richtige Konto** unter `~/.ssh/authorized_keys` eintragen; bestehende Schlüssel dabei erhalten. Verzeichnis auf `700`, Datei auf `600` und Eigentümer auf das Zielkonto setzen. Passwort-SSH ist bereits deaktiviert, daher ist `ssh-copy-id` ohne bestehenden Schlüsselzugang hier kein Wiederherstellungsverfahren.
Vor Erstverbindung den Hostschlüssel-Fingerprint aus einer vertrauenswürdigen Konsole abgleichen. Die lokalen SSH-Aliase müssen auf `10.0.0.90`, das jeweils richtige Konto und Schlüsseldatei zeigen; `IdentitiesOnly yes` und strikte Hostschlüsselprüfung verwenden. Die folgenden Beispiele setzen entsprechend eingerichtete Aliase auf der Admin-Workstation voraus:
```bash
ssh ghostnet-ai-ghost 'id -un; hostnamectl --static'
ssh ghostnet-ai-agent 'id -un; hostnamectl --static'
```
Für `ghost` ist auf der aktuellen Workstation eine Passphrase-Eingabe am Terminal erforderlich, sofern der Schlüssel nicht bereits im SSH-Agenten entsperrt wurde. Beide Profile sind getestet: `ghost-agent` wurde am 19.09.2026 erneut technisch geprüft; der Betreiber bestätigte am selben Tag den erfolgreichen interaktiven Login als `ghost`.
---
### 3.4 SSH-Dienst härten (Server-Seite)
Nur auf einem **neu eingerichteten System** nach erfolgreichem SSH-Key-Test die Passwort-Authentifizierung deaktivieren. Auf dem bestehenden KI-Server ist das folgende Drop-in bereits vorhanden; es wurde am 18.09.2026 lesend geprüft.
#### 1. Drop-in-Konfiguration für SSH erstellen
```bash
sudo nano /etc/ssh/sshd_config.d/99-security.conf
```
Den folgenden Inhalt einfügen:
```text
# Root-Login über SSH komplett verbieten
PermitRootLogin no
# Passwort-Authentifizierung deaktivieren (nur SSH-Keys erlauben)
PasswordAuthentication no
KbdInteractiveAuthentication no
# Leere Passwörter verbieten
PermitEmptyPasswords no
# Nur explizite SSH-Key Methoden erlauben
PubkeyAuthentication yes
```
#### 2. SSH-Konfiguration prüfen und Dienst neustarten
> **Achtung:** Die bestehende SSH-Sitzung **nicht** schließen, bevor der Login in einem zweiten Terminalfenster erfolgreich verifiziert wurde!
```bash
# Syntaktische Prüfung der Konfiguration
sudo sshd -t
# Wenn sshd -t keine Fehler ausgibt, Dienst neustarten
sudo systemctl restart ssh
```
---
## 4. Abnahmekriterien (Checkliste für den Junior-Admin)
* [ ] **Benutzerprüfung:** `ghost` und `debugofen` können ihre vorgesehenen sudo-Rechte nutzen; `ghost-agent` bleibt ohne sudo-Zuweisung.
* [x] **Workload-Konten:** `gnai-production`, `gnai-testing` und `gn-encoding` besitzen getrennte rootless Podman-Stores und aktive persistente User-Manager; geprüft am 20.09.2026.
* [x] **GPU-Geräterechte:** Beide KI-Konten können `/dev/kfd`, `/dev/dri/renderD128` und `/dev/dri/renderD129` lesen und schreiben; das Encoding-Konto gehört nicht zu `render`; geprüft am 20.09.2026.
* [ ] **Netzwerk:** Server ist unter der statischen IP `10.0.0.90` erreichbar. Ausgehender Datenverkehr funktioniert (`ping google.com`).
* [x] **SSH-Aliase:** `ghostnet-ai-ghost` meldet `ghost`, `ghostnet-ai-agent` meldet `ghost-agent`. Beide Zugänge wurden am 19.09.2026 bestätigt. Die Passphrase des persönlichen Schlüssels ist keine Server-Passwortanmeldung.
* [ ] **Root-Sperre:** Direct-Login als Root per SSH wird abgelehnt (`ssh root@10.0.0.90` -> *Permission denied*).
* [ ] **Passwort-Sperre:** Login-Versuch ohne hinterlegten SSH-Key wird direkt abgelehnt (keine Passwort-Aufforderung mehr).
---
## 5. Lesender Ist-Abgleich am 18.09.2026
`ghost` (UID 1000) und `debugofen` (UID 1001) gehören zur Gruppe `sudo`; `ghost-agent` (UID 1002) gehört nicht dazu. Der technische Login als `ghost-agent` und der vom Betreiber interaktiv geprüfte Login als `ghost` funktionieren mit ihren jeweils eigenen Schlüsseln. Die Prüfung belegt die Kontentrennung und den Schlüsselzugang, aber keine noch offenen sudo-, Root-Sperr- oder Negativtests.
`enp8s0` hat `10.0.0.90/24`, die Default-Route führt über `10.0.0.1`. `networking` und `ssh` sind aktiv und aktiviert. `/etc/network/interfaces` enthält die statische Konfiguration; `/etc/resolv.conf` nennt `10.0.0.1` und `1.1.1.1` und trägt einen dhcpcd-Generierungskommentar. Ein aktuell laufender `dhcpcd`-Dienst wurde nicht beobachtet; vor Resolveränderungen die tatsächliche Verwaltung erneut prüfen. Das SSH-Drop-in deaktiviert Root-, Passwort- und Keyboard-Interactive-Anmeldung und aktiviert Public-Key-Anmeldung.