Server und Verbindungen

Ein Server ist ein Host, auf dem Heinzel per SSH arbeitet: mit einem Schlüssel, den Heinzel Pro selbst erzeugt hat, als ein Benutzer, den Sie bestimmen, unter einem Deckel, den Sie setzen.

Einen Server anlegen

Das Formular Server hinzufügen: Wo findet Heinzel den Server (direkt, über VPN, über einen Sprungserver), Hostname oder IP und SSH-Port, der SSH-Benutzer, und die Obergrenze als vier Knöpfe nichts, sieht, arbeitet, ändert allein — Drei Fragen, der Rest kommt später auf der Seite des Servers.

Feld	Bedeutung	Beispiel
Wo findet Heinzel den Server	Direkt aus dem Internet, über eine VPN-Verbindung, oder über einen Ihrer Server als Sprungserver.	Direkt
Hostname oder IP, Port	Ein Name folgt seinem DNS; eine Adresse bleibt, was sie ist. Zwei Server mit derselben Adresse und demselben Port gehen in einem Mandanten nicht.	`web01.example.com`, 22
SSH-Benutzer	Der erste Zugang. `root`, oder ein Benutzer mit sudo ohne Passwort. Weitere Zugänge kommen auf der Serverseite dazu.	`heinzel`
Das Höchste, was irgendjemand hier darf	Der Deckel: `---` sperrt, `r--` nur lesen, `rw-` arbeiten mit Freigabe vor jeder Änderung, `rwx` Heinzel ändert allein. Auf `rwx` hebt ihn nur ein Administrator.	`rw-`
Tags, Beschreibung, Schlüssel	Tags als Wörter oder `schlüssel:wert`; die Serverliste filtert danach, Zeitpläne können Tags statt Server nennen. Der Schlüssel: ein eigener (Standard) oder ein gemeinsamer. Ed25519, auf Wunsch ECDSA oder RSA 4096.	`env:prod role:web`

Den Host vorbereiten

Nach dem Speichern zeigt die Serverseite unter „Schlüssel und Host-Key“ den öffentlichen Schlüssel. Er gehört in die authorized_keys jedes Benutzers, als der Heinzel sich anmelden soll. Drei Wege, je nach System.

Debian, Ubuntu, RHEL, Rocky, Alma, SUSE

# Als root auf dem Host. Die Schlüsselzeile von der Serverseite kopieren.
$ useradd --create-home --shell /bin/bash --comment "Heinzel Pro" heinzel
$ install -d -m 700 -o heinzel -g heinzel /home/heinzel/.ssh
$ echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI… heinzel-pro" \
  > /home/heinzel/.ssh/authorized_keys
$ chown heinzel:heinzel /home/heinzel/.ssh/authorized_keys
$ chmod 600 /home/heinzel/.ssh/authorized_keys
$ echo "heinzel ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/heinzel
$ chmod 440 /etc/sudoers.d/heinzel
$ visudo -c   # prüft die Syntax; ein Tippfehler sperrt sudo für alle

FreeBSD

$ pw useradd heinzel -m -c "Heinzel Pro" -s /bin/sh -G wheel
$ install -d -m 700 -o heinzel -g heinzel /home/heinzel/.ssh
$ echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI… heinzel-pro" \
  > /home/heinzel/.ssh/authorized_keys
$ chown heinzel:heinzel /home/heinzel/.ssh/authorized_keys
$ chmod 600 /home/heinzel/.ssh/authorized_keys
$ pkg install -y sudo
$ echo "heinzel ALL=(ALL) NOPASSWD: ALL" > /usr/local/etc/sudoers.d/heinzel

macOS

Fernanmeldung einschalten (Systemeinstellungen, Allgemein, Teilen, Entfernte Anmeldung), den Schlüssel in die ~/.ssh/authorized_keys eines Administrator-Kontos eintragen und diesem Konto in /etc/sudoers.d/heinzel NOPASSWD geben. Das Regelwerk hat eine eigene Regel für macOS.

Was der Host sonst braucht:

OpenSSH mit Public-Key-Anmeldung; Passwörter benutzt Heinzel Pro nie. Ein Host, der nur Zertifikate annimmt (AuthorizedKeysFile none), lässt sich nicht verwalten.
Für RSA-Schlüssel OpenSSH ab 7.2, weil Heinzel Pro nur mit SHA-2 signiert.
sh, nohup und ein Home-Verzeichnis, in das der Benutzer schreiben darf: Ein Befehl, der etwas ändert, läuft als Job in ~/.heinzel/jobs/ und überlebt so einen Neustart von Heinzel Pro. Fehlt das, läuft er im SSH-Kanal wie ein Lesebefehl.

Testen

Testen auf der Serverseite meldet sich an, speichert den Host-Key, erkennt System, Platten und Laufzeit und holt von da an Last, Speicher, Temperatur und Platten in dem Takt, den Sie der Liste geben, von node_exporter, wo einer läuft, sonst aus /proc und /sys. Ein geänderter Host-Key verweigert künftig die Verbindung, markiert den Server und alarmiert die Administratoren; wurde ein Host neu installiert, drücken Sie „Neuem Host-Key vertrauen“.

Die Serverliste: Suche, der Filter 13 Server sind nicht bereit, der Takt der Aktualisierung, und eine Tabelle mit Host, System, Platten, Auslastung und Zustand je Server — Die Liste der Beispiel GmbH vor dem ersten Test: Jeder Server sagt, was ihm noch fehlt.

Zugänge

Ein Zugang ist ein Benutzer, als der Heinzel sich anmeldet. Ein Server hat einen oder mehrere, etwa root für die Administratoren und deploy ohne sudo für alle anderen. Der Schlüssel des Servers öffnet jeden; tragen Sie ihn in die authorized_keys jedes Benutzers ein. Wer eine Session öffnet, wählt den Zugang, wo es mehr als einen gibt.

Ein Zugang hat einen eigenen Deckel, der nur senkt: root@web1 mit r-- lässt alle als root nur lesen, während sie als deploy arbeiten.
Das Formular eines Servers stellt unter „Strenger auf diesem Server“ eine Zelle der Matrix des Mandanten strenger, nie milder: Auf db02 wartet ein Neustart auf zwei Personen, überall sonst auf eine. Die Matrix steht unter Rechte.
Ein Zugang kann nennen, wer ihn nutzt: niemand angehakt heißt alle, die den Server erreichen; ein Team angehakt heißt nur dieses.
Ohne sudo: Ist der Haken aus, lehnt Heinzel jeden Befehl ab, in dem sudo, doas, su, pkexec oder run0 vorkommt. Ein Netz, keine Wand: Was der Benutzer wirklich darf, sagt die sudoers-Datei des Hosts.
Ein Zugang, den niemand mehr braucht, wird stillgelegt, nicht gelöscht: Alte Sessions zeigen weiter, als wer sie gearbeitet haben.

Schlüssel

Heinzel Pro erzeugt jeden privaten Schlüssel selbst, speichert ihn verschlüsselt und gibt ihn nie heraus. Einen Schlüssel hochladen geht absichtlich nicht: Ein Schlüssel, der auch auf einem Laptop liegt, ließe sich von Heinzel Pro aus nicht zurückziehen, und seine Nutzung wäre nicht von der einer Person zu unterscheiden.

Eigener Schlüssel pro Server (Standard): Ein kompromittierter Host verrät nichts über die anderen.
Gemeinsamer Schlüssel (Verwaltung, SSH-Schlüssel): ein Paar für viele Hosts, damit das Konfigurationsmanagement eine Zeile überall einträgt. Die Rotation behält den alten Schlüssel als „zurückgezogen“, bis jeder Host die neue Zeile hat.
Schlüssel erneuern auf der Serverseite erzeugt ein neues Paar; der alte Schlüssel gilt weiter, bis Sie den neuen eingetragen haben.

Geben Sie jedem Host einen eigenen Benutzer heinzel statt persönlicher Konten: Dann erzählen Host-Logs und Audit-Protokoll dieselbe Geschichte, und das Audit-Protokoll sagt, welcher Mensch was verlangt hat.

Viele Server auf einmal

Server, Importieren nimmt eine Hostliste, eine CSV, die Host-Blöcke einer ssh_config oder ein Ansible-Inventar. Es wird nichts kontaktiert: Die Server werden angelegt, und ein Skript, das die Seite danach anbietet, bringt die Schlüssel mit Ihrem eigenen Zugang auf die Hosts.

# Eine Zeile je Host, als [user@]host[:port]
deploy@web1.example.com:2222
web2.example.com
db1.example.com

# Oder als CSV: hostname,port,user,description
web01.example.com,22,heinzel,Webserver Kundenportal
web02.example.com,22,heinzel,Webserver Kundenportal
db01.example.com,22,root,PostgreSQL primär

Das Formular Server importieren: ein Textfeld für Hosts mit dem Beispiel deploy@web1.example.com:2222, die Erklärung der vier Formate und die Wahl zwischen einem eigenen Schlüssel für jeden Server und einem gemeinsamen — Der Import. Darunter wählen Sie, ob jeder Server einen eigenen Schlüssel bekommt.

Für ein Skript oder eine Pipeline gibt es dasselbe als POST /api/v1/<mandant>/servers; siehe API.

Hinter einem Sprungserver

Nimmt ein Host SSH nur von einem Bastion-Host an, legen Sie den Bastion-Host als Server an und nennen ihn beim Ziel unter „Über einen Sprungserver“. Heinzel verbindet sich mit dem Schlüssel und dem gespeicherten Host-Key des Bastion-Hosts dorthin, tunnelt weiter und meldet sich am Ziel mit dessen eigenem Schlüssel an. Der Bastion-Host muss TCP-Weiterleitung erlauben (AllowTcpForwarding yes in seiner sshd_config, die Vorgabe); unterstützt wird ein Sprung.

Server ohne öffentliche Adresse: VPN

Hinter dem Router zu Hause, im Büronetz, in einer Cloud ohne öffentliche IP: Eine VPN-Verbindung ist ein WireGuard-Tunnel zwischen Heinzel Pro und Ihrem Netz. Durch ihn meldet sich Heinzel per SSH an, mit demselben Schlüssel und Host-Key wie überall. Administratoren legen Verbindungen unter Verwaltung, VPN an. Drei Wege:

	Weg 1: Ihr Server verbindet sich mit Heinzel	Weg 2: Heinzel verbindet sich mit Ihrem Router	Weg 3: Heinzel als Gerät in Ihrem Tailscale-Netz
Passt	immer, auch ohne öffentliche IP (DS-Lite, CGNAT, Mobilfunk)	wenn der Router WireGuard anbietet und aus dem Internet erreichbar ist	wenn Sie Tailscale oder Headscale schon nutzen
Sie brauchen	ein Terminal auf einer Linux-Maschine im Netz und `sudo`	die Konfigurationsdatei des Routers	einen Auth-Key aus der Admin-Konsole
Am Router	nichts	ein neues WireGuard-Gerät	nichts

Weg 1, Schritt für Schritt

Verbindung anlegen. VPN, Neue VPN-Verbindung, „Mein Server verbindet sich mit Heinzel“, ein Name, speichern.

WireGuard installieren.

$ sudo apt install wireguard          # Debian, Ubuntu
$ sudo dnf install wireguard-tools    # Fedora, RHEL, Alma, Rocky

Den Block einfügen. Die Seite der Verbindung zeigt einen Block zum Kopieren. Im Terminal der Maschine eingefügt, speichert er /etc/wireguard/heinzel.conf und startet den Tunnel, jetzt und nach jedem Neustart. Der Block enthält den Schlüssel der Verbindung; behandeln Sie ihn wie ein Passwort.
Warten, bis „verbunden“ steht. Meist binnen zehn Sekunden; die Seite aktualisiert sich selbst.
„Diese Maschine als Server hinzufügen“. Adresse und Verbindung sind eingetragen. Weiter wie bei jedem Server: Schlüssel eintragen, testen.

Ein ganzes Netz über eine Maschine: Geräte ohne WireGuard (ein NAS, ein Switch) erreicht Heinzel über eine Linux-Maschine im selben Netz, die immer an ist. Tragen Sie beim Anlegen das Netz ein, etwa 192.168.1.0/24; der Block richtet die Weiterleitung mit ein. Abschalten geht jederzeit auf Ihrer Seite: sudo systemctl disable --now wg-quick@heinzel

Weg 2

Legen Sie Heinzel am Router an wie einen Laptop, als neues WireGuard-Gerät, und fügen Sie die Konfigurationsdatei, die der Router dann anbietet, unter „Heinzel verbindet sich mit meinem VPN-Router“ ein. FRITZ!Box: Internet, Freigaben, VPN (WireGuard), Verbindung hinzufügen, Einzelgerät verbinden, Einstellungen herunterladen; die Box braucht eine MyFRITZ!-Adresse und eine öffentliche IP, an einem DS-Lite-Anschluss nehmen Sie Weg 1. Server legen Sie mit ihrer Adresse im Heimnetz an, etwa 192.168.178.20, und wählen die Verbindung.

Weg 3

In der Tailscale-Konsole einen Auth-Key erzeugen (nicht „Ephemeral“, mit einem Tag wie tag:heinzel, damit das Gerät nicht abläuft), in Heinzel unter „Meine Server sind in einem Tailscale-Netz“ eintragen, für Headscale dazu die Adresse des Control-Servers. Heinzel tritt als Gerät heinzel bei, benutzt den Schlüssel einmal und vergisst ihn. Erlauben Sie dem Gerät in den Zugriffsregeln nur die betreuten Server auf deren SSH-Port, und legen Sie die Server mit ihrer Tailscale-Adresse (100.…) oder ihrem Namen an. Tailscale SSH wird nicht benutzt; Heinzel meldet sich am gewöhnlichen sshd an.

Die Seite einer VPN-Verbindung in Heinzel Pro mit dem Status verbunden und dem Block zum Einfügen auf dem Server — Eine Verbindung nach Weg 1, verbunden.

Was Heinzel über einen Server weiß

Gedächtnis (Serverseite, „Was Heinzel weiß“): Betriebssystem, Dienste, Pfade, Eigenheiten. Heinzel aktualisiert es nach der Arbeit; Sie können es bearbeiten. Jede Session liest es zuerst.
Journal: jede Änderung auf dem Server mit ihrem Befehl, dazu Ihre Notizen von Hand („Kunde will keine Neustarts dienstags“).
Übergabe: eine Markdown-Datei mit allem, was über den Server gespeichert ist, für die Kollegin, die ihn übernimmt. Kein Modell schreibt sie.
Übergabenotizen auf dem Host: eine Zeile im Systemjournal des Hosts nach jeder Änderung, für alle mit Shell-Zugang und für eine zweite Heinzel-Instanz. Zwei Häkchen im Serverformular (hinterlassen, lesen), beide anfangs an. Wortlaut unter Einstellungen, Richtlinie.

$ journalctl -t heinzel
heinzel: [Anna Berg/root] nginx auf 1.28.0 aktualisiert, weil die alte Version eine Sicherheitslücke hatte
         https://app.heinzel-pro.de/beispiel/sessions/0199e2c4-…

Einen Host sperren, ohne Heinzel Pro zu öffnen

Wer root auf einem Host ist, hält Heinzel mit einer Datei zurück, die auch das offene Heinzel beachtet:

# /etc/heinzel.conf
allow_changes = false
reason = Datenbank-Migration bis 20.10.

Vor jedem ändernden Befehl liest Heinzel Pro die Datei. Nur eine fehlende Datei oder allow_changes = true lässt die Änderung durch; alles andere verweigert sie mit dem Grund des Besitzers am Befehl. Lesen läuft weiter. Der Classifier sperrt jeden Befehl, der die Datei schreibt oder löscht, also hebt nur der Besitzer die Sperre auf.