Im Artikel SSH-Keys mit Yubikey habe ich erläutert, wie man einen Yubikey als SSH-Key nutzen kann. Doch Yubikeys sind nicht ganz billig und die meisten Geräte heutzutage bieten mit TPM1 eine kostengünstige Alternative.
So gut wie jede*r mit ein klein wenig Interesse an IT wird über Fälle gelesen haben, bei denen geheime Schlüssel versehentlich öffentlich gemacht wurden. Oft passiert dies, indem irgendwelche Git-Repositories öffentlich zugänglich gemacht werden. Es gibt z.B. zahlreiche Sammlungen sog. dotfiles1, die das Verzeichnis .ssh beinhalten. Dort liegen auch oft auch die geheimen Schlüssel für den Zugang zu diversen Systemen.
Dies kann man effektiv verhindern, indem diese Schlüssel nicht auf der Festplatte sondern in besonders gesicherten Bereichen abgelegt werden. Dies kann z.B. ein Yubikey2 sein. Wer keinen Yubikey hat, aber einen Rechner mit TPM Chip, kann sich auch gern den Artikel SSH-Keys mit TPM anschauen.
Anleitungen wie man sich Zertifikate mit letsencrypt1 erstellen lassen kann, gibt es viele. Wenn es um Wildcard-Zertifikate geht, werden die Anleitungen schon etwas weniger. Wenn doch, nutzen diese meist US-Anbieter wie Cloudflare.
Ich möchte hier einmal zeigen, wie das alles mit Hetzner2 funktioniert.
Das Verfahren ist übrigens auch sehr gut für Intranetserver geeignet, da letsencrypt hierbei keine HTTP-Verbindung zu den Servern aufbauen muss, um die Zertifikatsanforderung zu verifizieren.
Ich hatte diesen Artikel bei der Einrichtung des Blogs geschrieben und ihn beim Aufräumen der Testeinträge mitgelöscht. Leider hatte ich zu diesem Zeitpunkt noch keine Versionierung eingerichtet. Ich habe mich daher entschlossen den Artikel einmal von OpenAI/ChatGPT neu erstellen zu lassen. Das Ergebnis kann sich durchaus sehen lassen.
Ich habe folgenden Prompt verwendet:
Schreibe einen Artikel, der die Funktion und Einrichtung von Wireguard unter Linux (Server und Client) beschreibt. Zeige jeweils beispielhafte Konfigurationsdateien und nutze Preshared Keys. Erkläre zudem die nötigen Einstellungen (iptables und sysctl) zum Forwarden von Traffic und binde diese in die Wireguard Konfigurationsdatei ein (postup/postdown). Erkläre jede Zeile der Konfigurationsdateien im Detail.
Das Ergebnis war ok, man hätte eine funktionierende Konfiguration erhalten. Allerdings hat ChatGPT eine separate Konfiguration für iptables erzeugt (/etc/iptables/rules.v4). Dies war anders gefordert, daher habe ich ChatGPT gebeten den Artikel erneut zu schreiben:
Die iptables Befehle sollen in die Wireguard Konfigurationsdateien übernommen werden. Schreibe den Artikel neu.
Das hat OpenAI so umgesetzt, die Postup/Postdown Befehle für iptables aber auch in die Client-Konfigurationsdatei geschrieben, was natürlich komplett sinnlos ist. Daher habe ich OpenAI erneut gebeten den Artikel neu zu verfassen:
Die iptables Befehle sind nur in der Server Konfigurationsdatei sinnvoll. Schreibe den Artikel neu.
Das Einzige was nun noch fehlte, waren die Preshared Keys:
Das ist gut, es fehlen aber die Preshared Keys. Schreibe den Artikel neu.
ChatGPT hat daraufhin zwar die Konfigurationseinträge in die beiden Konfigurationsateien aufgenommen, aber den Befehl zum Erzeugen des Preshared Keys nicht erwähnt.
Es fehlt der Befehl zum Erzeugen des Preshared Keys. Schreibe den Artikel neu.
Das Ergebnis ist der folgende Artikel. Sein einziges Manko ist vielleicht noch die Erklärung des Unterschieds des AllowedIPs Eintrags zwischen Server und Client. Auf Serverseite legt AllowedIPs die IP-Adresse des Clients fest, nutzt also das Subnet /32. Auf dem Client gibt AllowedIPs die Subnets an, die vom Wireguard-Server geroutet werden sollen. Gibt man hier z.B. 0.0.0.0/0 an, wird der gesamte Traffic über das VPN geleitet.
Ich habe ChatGPT daher gebeten, diesen Unterschied separat zu erläutern:
Erläutere den Unterschied der AllowedIPs Konfigurationsanweisung zwischen Client und Server.
Das Ergebnis habe ich als Hinweis unter das Fazit des eigentlichen Artikels angehängt.
Als ich das erste Mal auf Tools wie Home Assistant1 (HA) gestoßen bin, dachte ich mir: Ja, so eine gemeinsame Oberfläche für meinen Smarthome-Geräte-Zoo ist ja an sich ganz nett. Aber so wirklich brauche ich das nicht. Der zweite Gedanke war dann jedoch, damit kann ich meine Geräte ja vermutlich untereinander in einer Art und Weise verknüpfen, die vorher nicht möglich erschien. Und richtig. Home Assistant bildet eine Umgebung, in der Geräte verschiedenster Hersteller ihre Statusinformationen austauschen und auf diese reagieren können. Das klingt banal, eröffnet aber wirklich ganz neue Sichtweisen.
Ich kenne eine ganze Reihe von IT-Leuten, die täglich SSH nutzen. Doch die wenigsten nutzen eine ~/.ssh/config1. Dabei ist sie ein durchaus mächtiges Werkzeug und kann den SSH-Workflow stark vereinfachen und bereichern.
Der Markt für smarte Steckdosen ist riesig. Viele Produkte sind jedoch kurzlebig und natürlich setzt jeder Hersteller auf eine eigene App, meistens inkl. Cloudanbindung. Das ist nicht nur aus Datenschutzgründen unschön, es nervt auch einfach, denn meistens sind die Apps nicht besonders gut gemacht. Und allein sich zu merken, welche Steckdose welche App nutzt ist schon Grund genug es anders machen zu wollen.
Ich kann mich an wenige Webdienste erinnern, die so verheißungsvoll gestartet sind und am Ende so enttäuschend waren, wie IFTTT1 (If This Than That). Die Idee war brilliant. Mit einfachsten "Wenn" => "Dann" Verknüpfungen kann man unterschiedlichste Geräte und Dienste miteinander Verknüpfen. Und das funktioniert auch heute noch wunderbar. Allerdings ist die Webseite irgendwie in die Jahre gekommen und der ganze Workflow fühlt sich an vielen Stellen etwas hakelig an. Und mit den Jahren sind auch irgendwie die Ideen gewachsen, was man mit einem solchen Tool alles machen könnte. Leider ist IFTTT da aber nie so richtig mitgewachsen. Ja, es sind etwas komplexere Möglichkeiten der Verknüpfung hinzugekommen, aber das konnte dennoch nicht so wirklich mit den Ideen mithalten. Die Anzahl der verfügbaren Hardware- und Webserviceintegration ist zwar über die Jahre immer weiter gewachsen, aber vieles davon gibt es nur auf dem US-Markt und/oder orientiert sich sehr an kommerziellen Produkten.
Das kostenlose Paket wurde mit der Zeit immer weiter eingedampft, bis man irgendwann kaum noch etwas sinnvolles damit tun konnte, dafür wurden die Preise für die kostenpflichtigen Pakete erhöht. Und auch wenn diese unterm Strich noch in Ordnung sind, habe ich mich irgendwann nach Alternativen umgeschaut und bin auf Huginn2 gestoßen.
Nachdem wir die Datenerfassung mit Prometheus bewerkstelligt haben, ist es nun natürlich sinnvoll auch eine Datenvisualisierung einzurichten. Hier kommt Grafana1 ins Spiel.
Prometheus1 sammelt Metriken von verschiedenen Quellen und bietet leistungsstarke Funktionen zur Analyse und Visualisierung dieser Metriken. Prometheus ermöglicht das Erkennen von Anomalien, das Überwachen von Service-Level-Agreements (SLAs) und das Generieren von Warnungen bei Abweichungen. Es bietet eine flexible Abfragesprache namens PromQL, zur Abfrage von Metriken und zur Durchführung komplexer Auswertungen. Es ist in der Cloud-Native- und DevOps-Welt weit verbreitet und wird häufig mit anderen Tools wie Grafana zur Visualisierung verwendet.