pixel
Select Page

NETWAYS Blog

Wireguard mit dynamischen DNS Namen

Seit einiger Zeit bin ich großer Fan von Wireguard als VPN Lösung um meine Server und Notebooks zu verbinden. Auch Patrick hatte schon mal über DNS Privacy mit Wireguard geschrieben.

Dabei ist mir ein kleines Problem begegnet, Wireguard hat kein automatisches Handling wenn sich Endpoint Adressen über DNS ändern. In meinem Fall verbinde ich:

  • Server im Rechenzentrum mit fester IP Adresse
  • Notebook irgendwo unterwegs, muss sich zu allen anderen Verbinden
  • Server zuhause, Verbindung nur über DynDNS möglich

Auf dem Bild kann man in etwa die aufgebauten Verbindungen erkennen, nun besteht das Hauptproblem darin, dass der Server zuhause nur über die Auflösung des dynamischen DNS Namens erreichbar ist. Wireguard löst DNS Namen nur beim laden der Konfiguration auf. Sollte sich die IP Adresse ändern funktioniert die Verbindung nicht mehr.

Ein Beispiel meiner Konfiguration:

[Interface]
# Notebook
Address = 10.99.0.3/24
PrivateKey = BASE64
ListenPort = 51820

[Peer]
# Server at home
PublicKey = BASE64
AllowedIPs = 10.99.0.1/32
Endpoint = home.example.com:51820

[Peer]
# hosted VM
PublicKey = BASE64
AllowedIPs = 10.99.0.2/32
Endpoint = server.example.com:51820

#[Peer]
## Notebook Entry on other nodes
#PublicKey = BASE64
#AllowedIPs = 10.99.0.3/32
## No endpoint defined for this peer

Nachdem Wireguard noch keine eingebaute Lösung dafür hat, braucht man ein Script, welches DNS Namen neu auflöst und dann anwendet. Ich verwende das Beispielskript reresolve-dns.sh aus den contrib Skripten.

Die Installation ist relativ einfach:

curl -LsS -o /usr/local/bin/wireguard-reresolve-dns https://github.com/WireGuard/wireguard-tools/raw/master/contrib/reresolve-dns/reresolve-dns.sh
chmod 0755 /usr/local/bin/wireguard-reresolve-dns

Im Anschluss kann das Skript manuell oder per Cron (als root) ausgeführt werden:

wireguard-reresolve-dns wg0

Oder was ich bevorzuge, als Systemd Service und Timer wie folgt.

/etc/systemd/system/wireguard-reresolve-dns.service

[Unit]
Description=Wireguard Re-Resolve DNS of endpoints

[Service]
Type=oneshot
ExecStart=/usr/local/bin/wireguard-reresolve-dns wg0

/etc/systemd/system/wireguard-reresolve-dns.timer

[Unit]
Description=Runs Wireguard Re-Resolve DNS every 5 Minutes

[Timer]
OnUnitActiveSec=300s
OnActiveSec=300s

[Install]
WantedBy=multi-user.target

Anschließend muss man den Timer nur aktivieren und kann den Status des Service jederzeit checken:

# systemctl daemon-reload
# systemctl enable wireguard-reresolve-dns.timer
# systemctl status wireguard-reresolve-dns.timer
* wireguard-reresolve-dns.timer - Runs Wireguard Re-Resolve DNS every 5 Minutes
Loaded: loaded (/etc/systemd/system/wireguard-reresolve-dns.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Thu 2021-12-30 15:40:09 CET; 6 days ago
Trigger: Wed 2022-01-05 15:50:48 CET; 3min 1s left
Triggers: * wireguard-reresolve-dns.service

Dec 30 15:40:09 notebook systemd[1]: Started Runs Wireguard Re-Resolve DNS every 5 Minutes.

# systemctl status wireguard-reresolve-dns.service
* wireguard-reresolve-dns.service - Wireguard Re-Resolve DNS of endpoints
Loaded: loaded (/etc/systemd/system/wireguard-reresolve-dns.service; static)
Active: inactive (dead) since Wed 2022-01-05 15:45:48 CET; 2min 1s ago
TriggeredBy: * wireguard-reresolve-dns.timer
Process: 3600033 ExecStart=/usr/local/bin/wireguard-reresolve-dns wg0 (code=exited, status=0/SUCCESS)
Main PID: 3600033 (code=exited, status=0/SUCCESS)
CPU: 17ms

Jan 05 15:45:48 notebook systemd[1]: Starting Wireguard Re-Resolve DNS of endpoints...
Jan 05 15:45:48 notebook systemd[1]: wireguard-reresolve-dns.service: Succeeded.
Jan 05 15:45:48 notebook systemd[1]: Finished Wireguard Re-Resolve DNS of endpoints.

Ich wünsche viel Spaß beim Ausprobieren.

Wer gerne automatisiert, dem kann ich die Ansible Rolle von githubixx empfehlen, so spart man sich das müssige Erstellen und Verteilen von Keys. Leider habe ich noch keine fertige Rolle für reresolve DNS. 😉️

Markus Frosch
Markus Frosch
Principal Consultant

Markus arbeitet bei NETWAYS als Principal Consultant und unterstützt Kunden bei der Implementierung von Nagios, Icinga und anderen Open Source Systems Management Tools. Neben seiner beruflichen Tätigkeit ist Markus aktiver Mitarbeiter im Debian Projekt.

Administrators Toolbox: SSH

SSH

“Secure Shell oder SSH bezeichnet ein kryptographisches Netzwerkprotokoll für den sicheren Betrieb von Netzwerkdiensten über ungesicherte Netzwerke.[1] Häufig wird es verwendet, um lokal eine entfernte Kommandozeile verfügbar zu machen, d. h., auf einer lokalen Konsole werden die Ausgaben der entfernten Konsole ausgegeben, und die lokalen Tastatureingaben werden an den entfernten Rechner gesendet. Genutzt werden kann dies z. B. zur Fernwartung eines in einem entfernten Rechenzentrum stehenden Servers. Die neuere Protokoll-Version SSH-2 bietet weitere Funktionen wie Datenübertragung per SFTP.” [0]

Damit dürfte SSH den meisten Administratoren schon ein Begriff sein, zumindest wenn eine Maschine mit einem Unix im Netzwerk vorhanden war. Falls noch Unklarheit besteht: Wenn gelentlich PuTTY geöffnet wird, wird sehr wahrscheinlich SSH eingesetzt. Die Vorteile von SSH sind schnell benannt, es bietet schnelle, stabile, sichere (authentifiziert und verschlüsselt) und bandbreitensparsame Verbindungen ohne grossen Aufwand dafür betreiben zu müssen. Die Beginne des Protokolls liegen in den 90ern als damit mehrere klassische Unix-Dienste abgelöst wurden und seitdem gibts es nur selten grössere Neuerungen [1]. Dennoch sind einige sehr nützliche Funktionen in SSH recht unbekannt und dem soll hiermit Abhilfe geschaffen werden. Im folgenden gehe ich dabei auf zuerst ein wenig auf die Grundlagen ein und dann auf die etwas weniger bekannten Eigenschaften.

Das erste Mal

Ein typische SSH-Session beginnt mit der Eingabe des ssh-Kommandos und der Zieladdresse, also etwa eines DNS-Namens oder einer IP-Addresse:

# ssh 192.168.178.23

Ohne weitere Angaben wird dabei wird als Loginname der des aktuellen Nutzers verwendet, bei PuTTY wird man beim einwaehlen nach dem Loginnamen gefragt. Beim ersten Mal wird die folgende Meldung bzw. das Aequivalent auf PuTTY erscheinen:

The authenticity of host '192.168.178.23 (192.168.178.23)' can't be established.
ED25519 key fingerprint is SHA256:cBmwx2ZFgoK0EBvWf2CDtiu5a9hoPMn4xH4LjEnPH64.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Es ist an diesem Punkt bereits eine Verbindung zum Zielrechner aufgebaut und der öffentliche Schlüssel des Hosts abgerufen worden. Ohne jetzt auf die Details von asymmetrischer Kryptographie einzugehen zu wollen, muss dieser Mechanismus kurz erlaeutert werden. Bei der Installation erzeugt der SSH-Server ein oder mehrere Schlüsselpaare, ein Paar besteht aus einem öffentlichen und privaten Teil, diese sind mathematisch verbunden. Daten die mit dem öffentlichen Teil verschlüsselt werden sind nur mit dem privaten Teil entschlüsselbar. Mit dem privaten Teil können Daten signiert werden, was mit dem öffentlichen Teil verifiziert werden kann, dass heisst, die gesendeten Daten wurden genau so von etwas versandt, was Zugriff auf den privaten Schlüssel hat (als typischerweise die Person oder Maschine die den Schlüssel besitzt). Ein aehnliches Prinzip kommt auch an vielen Stellen beim Einsatz von TLS zum Tragen, also z.B. beim normalen Besuch einer Website (wenn oben in der Addressleiste des Browsers ein Schlosssymbol ist). Aufgrund eines Systems von Vertrauensankern kann jedoch der Browser schon mehr oder weniger garantieren, dass die Gegenstelle auch die gewünschte ist, ohne den Nutzer nach einer Bestaetigung zu fragen. Dieses Verfahren kommt bei SSH normalerweise NICHT zum Einsatz, dazu aber spaeter mehr.

Mit einem yes oder der Eingabe des Fingerabdrucks des öffentlichen Schlüssel des Ziels kann nun bestaetigt werden, dass man diesen als authentisch annimmt, bei PuTTY gibt es dementsprechende Knöpfe. Anmerkung: Diese Meldung wird, der Erfahrung nach, IMMER und ohne Verifikation ignoriert. Dies ist in einem kontrollierten Netzwerk (zuhause oder vielleicht auch in einem Betrieb) vermutlich unbedenklich, nicht jedoch, wenn die Verbindung nicht der eigenen Kontrolle unterliegt. Ein Angreifer kann sich an dieser Stelle zwischen den Nutzer und das Ziel schalten! Diese Verifikation sollte also mit Bedacht und mittels eines zweiten (gesicherten) Kanals erfolgen. Wenn man zum Beispiel über eine virtuelle serielle Schnittstelle der Virtualisierungssoftware Zugriff auf die Maschine hat, so kann man mit ssh-keygen den Fingerprint ermitteln:

# ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
256 SHA256:cBmwx2ZFgoK0EBvWf2CDtiu5a9hoPMn4xH4LjEnPH64 root@generic-debian11 (ED25519)

Dabei ist zu beachten, dass heutzutage mehrere Schlüsselpaare vorhanden sind und in /etc/ssh/ das passende ausgewaehlt werden muss, hier ist das ED25519, es könnte aber auch z.B. RSA oder ECDSA sein. Dies sind verschieden Algorithmen, was hier erstmal ignoriert wird.

Anschliessend sollte die Passwortabfrage erscheinen bzw. unter PuTTY die Frage nach dem Loginname:

user@192.168.178.23's password:

Nach der Eingabe des Passwortes landet man dann auf der eingestellten Loginshell.

SSH-Schlüssel

Das Passwort jedesmal einzugeben ist natürlich unnötige Arbeit und zudem problematisch, da dann schlussendlich doch schlechte und/oder schon mal benutzte Passwörter verwendet werden. Die Lösung dafür ist recht einfach und schon vorhanden: SSH-Schlüssel. Das klingt ja erstmal wie das Thema weiter oben und tatsaechlich ist es in etwa auch das Gleiche, nur dass wir dieses Mal das Schlüsselpaar für einen Nutzer verwenden. Dafür wird zuerst mal ein Schlüsselpaar erzeugt:

ssh-keygen
Enter file in which to save the key (/home/user/.ssh/id_rsa):

hier kann nun ein gewünschter Dateipfad angegeben werden (alternativ gleich in den Befehl mit der Option -f)

Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Wie die Ausgabe beschreibt, kann hier eine Passphrase gesetzt werden, dies ist natürlich empfehlenswert. Waehrend einer laufenden Nutzersitzung, kann der Schlüssel einem SSH-Agenten hinzugefügt werden, so dass das Passwort nur einmal eingegeben werden muss.

Your identification has been saved in /home/user/.ssh/id_rsa
Your public key has been saved in /home/user/.ssh/id_rsa
The key fingerprint is:
SHA256:NY92co2ANzzBp6P82ILfZpmRALePZJxvU1Yxpt5UgGk user@host
The key's randomart image is:
+---[RSA 3072]----+
|         ..  o=o.|
|      . .o..Eo.o |
|       +.oO+...  |
|        BooOo=   |
|       +S*+=* o  |
|        +.B+     |
|       . = =     |
|      . o.B      |
|       ..+.      |
+----[SHA256]-----+

Der weitere Output zeigt dann noch den Erfolg der Operation an und stellt (aus irgendwelchen Gründen) den Fingerprint graphisch dar. Der Schlüssel kann dann auf die Zielmaschine kopiert werden:

ssh-copy-id -i $PFAD_ZUM_OEFFENTLICHEN_SCHLUESSEL $USER@$ZIEL

(wobei natürlich alle mit $ beginnenden Parameter durch die realen Werte ersetzt werden müssen) und dann benutzt werden mittels:

ssh -i $PFAD_ZUM_PRIVATEN_SCHLUESSEL $USER@$ZIEL

Da der Aufruf immer noch recht lang ist, kann man in einer Konfigurationsdatei ein paar Parameter setzen. Die Standardkonfigurationsdateien auf Unix-Systemen ist vermutlich ~/.ssh/config.

Host bla
    User $USER
    Hostname $ZIEL
    IdentityFile $PFAD_ZUM_PRIVATEN_SCHLUESSEL

Danach ist der Aufruf nur noch ssh bla. In PuTTY ist das Erstellen von Schlüssel und den Konfigurationseintraegen durch Klicken möglich.

Dateitransfer

Es gibt hier verschiedene Möglichkeiten:

1.scp Die Verwendung von scp ist relativ simpel und auch brauchbar für Skripte:

scp $LOKALE_DATEI $ZIELHOST:$ZIELORT_ODER_DATEI
scp $ZIELHOST:DATEI $LOKALE_ZIEL_DATEI

2.sftp Die Verwendung erinnert an die des Kommandos ftp und ist interaktiv, inklusive Verzeichniswechsel usw.

3.sshfs Eine FUSE-Implementierung von einem Dateisystem über SSH.

sshfs $ZIELHOST:$PFAD $LOKALES_VERZEICHNIS

haengt $PFAD des $ZIELHOST im $LOKALES_VERZEICHNIS ein.

Netzwerk

Ein paar sehr nützliche Features sind die Netzwerkoptionen von SSH, z.B.:

ssh -L 5555:bla:80 foo

transportiert alle Anfragen die an den lokalen Port 127.0.0.1:5555 gehen über SSH an den Host foo von wo aus sie über den normalen Netzwerkpfad (ohne SSH-Tunnel) dann auf Port 80 auf bla gehen. Sehr nützlich, wenn man etwa ein nur lokal erreichbares Webinterface besuchen möchte.

ssh -R 5555:localhost:6767 $ZIEL

Das Gegenstück, öffnet auf dem $ZIEL den Port 5555 und leitet in an den lokalen Port 6767 weiter.

ssh -J hop1,hop2 ziel

“Springt” per SSH über hop1 und hop2 zu ziel. Natürlich muss sich der Nutzer auf allen Systemen authentifizieren, aber benötigt keine Shell. Es können damit reine Gateways benutzt werden, die als “Eingangstor” in ein Netzwerk dienen.

ssh -D 6767 $ZIEL

Öffnet eine dynamische Port-Weiterleitung auf $Ziel. Kann auch von Browsern als SOCKS Proxy verwendet werden.

ssh $ZIEL -o "ProxyCommand=nc -X connect -x $PROXYHOST:$PROXYPORT %h %p"

Verbindet sich über den (HTTP-)Proxy $PROXYHOST auf Port $PROXYPORT zum $ZIEL

SSH-Zertifikate

Während die bisherigen Abschnitte SSH-Grundlagen und diverse Nutzungsmöglichkeiten behandelt haben, stellt sich dem interessierten Lesen oder auch dem fortgeschrittenen Nutzer schon die Frage nach der Skalierung solcher Setups. Die Authentizität einer Verbindung ist ja theoretisch durch die Schlüssel sicher gestellt, aber rein praktisch ist da die Problematik, dass man ja erstmal alle Host-Schlüssel in seiner ~/.ssh/known-hosts sammeln muss. Bei großen und dynamischen Umgebungen ein Sysiphos-Unterfangen, dass recht bald in Problemen resultiert. Das gleiche gilt natürlich für die Schlüssel der Nutzer. Da diese lokal für den sshd (den SSH-Daemon) verfügbar sein müssen, müssten potentiell ALLE Schlüssel ALLER Nutzer auf ALLE relevanten Maschinen kopiert und dort natürlich auch aktualisiert werden. Netzwerkdateisysteme sind natürlich ein Aus- oder Umweg, aber bergen das Risiko, dass bei einem Ausfall dieser Infrastruktur der Login überall sonst nicht mehr funktioniert. Naheliegenderweise gibt es dafür zumindest teilweise eine Lösung. In SSH gibt es nämlich auch Komponenten für eine Zertifikatsinfrastruktur. Diese ähnelt ein wenig der von TLS, ist jedoch deutlich rudimentärer und simpler. Dabei lassen sich SSH-Zertifizierungsschlüssel erstellen, die sowohl Host- als auch Nutzerschlüssel signieren können. Ein Nutzer muss dann nur noch dem Zertifizierungsschlüssel vertrauen um einen Host zu verifizieren und ein Host um einen Nutzer zu authentifizieren.

Der Zertifizierungsschlüssel besteht dabei, wie bisher bei den anderen Schlüsseln, auch wieder aus einem Schlüsselpaar:

# ssh-keygen -f ./ca_host_key -t ed25519
Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ./ca_host_key
Your public key has been saved in ./ca_host_key.pub
The key fingerprint is:
SHA256:3UmaB6K4wy/obEBhmeGYWZIKnlvF9emPY8xQgZmygPM user@host
The key's randomart image is:
+--[ED25519 256]--+
|.o* . ..+.       |
|=% . + +. o      |
|O.= o o .+. .    |
|.+ E o .oo * .   |
|. o . ..S.+ +    |
|.. . .  + o.     |
| . .+    * .     |
| .o .o  . .      |
| oo  ..          |
+----[SHA256]-----+

# cat ./ca_host_key.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICCdmjMLjw+WGI+Aj1FUHUCG16daqoyeet+GZWi1O/TS user@example.com

und damit können nun Host- oder Nutzerschlüssel signiert werden. Der Parameter -I enthält dabei die certificate_ID welche im Prinzip frei wählbar ist, aber für diesen Fall (der Host-Zertifikate) auf den eindeutigen Hostnamen gesetzt werden sollte.

# ssh-keygen -s ca_host_key -I testhost.local -h /etc/ssh/ssh_host_ecdsa_key.pub
Signed host key /etc/ssh/ssh_host_ecdsa_key-cert.pub: id "testhost.local" serial 0 valid forever

Dabei wird eine neue Datei host_ecdsa_key-cert.pub erstellt, die den unterschriebenen öffentlichen Schlüssel enthält, das sieht dann ungefähr so aus:

# cat ssh_host_ecdsa_key.pub
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBMuXZN6or69chS+ZT6++P37JeRC5km+cIbzXnfCos9hvJ9jUbB+Becozdcmhfhj6Udg6FfxwDJqc5WaKHA0uErY= root@example.com
# cat ssh_host_ecdsa_key-cert.pub
ecdsa-sha2-nistp256-cert-v01@openssh.com AAAAKGVjZHNhLXNoYTItbmlzdHAyNTYtY2VydC12MDFAb3BlbnNzaC5jb20AAAAgtZ2LJPOCioVR9tG19Zekk3x6qru6bYXCIlMXsKSc43QAAAAIbmlzdHAyNTYAAABBBMuXZN6or69chS+ZT6++P37JeRC5km+cIbzXnfCos9hvJ9jUbB+Becozdcmhfhj6Udg6FfxwDJqc5WaKHA0uErYAAAAAAAAAAAAAAAIAAAAOdGVzdGhvc3QubG9jYWwAAAAAAAAAAAAAAAD//////////wAAAAAAAAAAAAAAAAAAADMAAAALc3NoLWVkMjU1MTkAAAAgIJ2aMwuPD5YYj4CPUVQdQIbXp1qqjJ5634ZlaLU79NIAAABTAAAAC3NzaC1lZDI1NTE5AAAAQFgq6IqNBRjJrysFdBHHceU83AXF0Vg13uq17ZJXn2hk98H6rRnLCV8XvOtRd9o1bxtc8xQ7Poigw4wuRbMjigY= root@testhost.local

Nun fehlt nur noch ein Eintrag in die known_hosts Datei:

@cert-authority *.example.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICCdmjMLjw+WGI+Aj1FUHUCG16daqoyeet+GZWi1O/TS

Damit werden alle Host-Schlüssel akzeptiert, die von einem Host mit dem Namensmuster *.example.com kommen und mit dem Zertifizierungsschlüssel signiert sind.

Dasselbe lässt sich prinzipiell gleichartig auf Nutzerschlüssel übertragen, auf ein Beispiel wird hier nun verzichtet um diese Vorstellung hier knapp zu halten. Jedoch gibt es den einen oder anderen Punkt, der erwähnt werden sollte: Da es sich hier nicht um TLS handelt und die ganze Struktur sehr viel schmaller ist, ist das Widerrufen von Schlüsseln anderst gelöst. Es gibt keine zentrale Stelle die Revocation Lists führt, die abgefragt werden können. Eine solche Liste muss sich lokal auf der Maschine befinden, also etwa mit Ansible, Puppet, Salt, Chef… plaziert und aktualisiert werden. Dies ist natürlich gerade für Nutzerschlüssel zu empfehlen. Zusätzlich sollte erwähnt werden, dass es durchaus die Möglichkeit gibt, das System zu erweitern und eigene Erweiterungen zu erstellen, beispielsweise mit der AuthorizedKeysCommand-Direktive in der sshd-Konfiguration die einem erlaubt ein eigenes Programm zu erstellen/verwenden um die Nutzer zu authentifizieren und damit wiederum eine Anbindung an Datenbanken oder Netzwerkdienste.

Rekapitulation

SSH als Protokoll und mit den gängigen FOSS-Implementierungen ist ein sehr mächtiges Werkzeug für den Umgang mit vernetzten Computern und leider, zumindest in meiner Wahrnehmung, unterschätzt. Nicht nur lassen sich enorm viele Aufgaben damit erledigen, es ist dabei auch flexibel, schnell und ressourcensparend. Etwas, was in einer Zeit der eher penetranten, langsamen Anwendungen als Abwechslung doch mal wieder angenehm ist. Die Netzwerk-Tricks erlauben das sinnvolle Arbeiten, auch in Umgebungen mit eher kreativen Firewall-Regeln und mit ein wenig Einrichtung ist der Zugriff auf entfernte Rechner kaum noch von dem auf den eigenen, lokalen zu unterscheiden (ich würde zu eine Shell-Prompt raten, die dies farblich hervorhebt, es kann leicht zu Verwirrungen kommen). Mit ein bisschen zusätzlicher Arbeit kann das System auch gut skaliert werden. Und das schönste: Es ist schon da! Die Chancen sind gut, dass es bereits auf jedem Linux-System im Netzwerk vorhanden ist (und auf dem meisten aktiv) und auf jedem anderen Unix-System ist es sehr sicher verfügbar. Sogar auf den Windows-Systemen ist relativ einfach zu installeren (Microsoft bietet einfach auch OpenSSH als Dienst zur Installation an). Es lohnt sich hier auf jeden Fall mal ein wenig Zeit in das Setup zu investieren um die Arbeit ein wenig angenehmer und flüssiger zu gestalten und ich hoffe, dass dieser Artikel ein paar Anstösse in diese Richtung gegeben hat.

Danksagung

An dieser Stelle möchte ich kurz Dank ausrichten an das Entwicklungsteam von OpenSSH die das Protokoll und die wohl populärste Implementierung warten und stetig weiterentwickeln und etwas gebaut haben, was mir und vielen anderen den sinnvollen Umgang mit vernetzten Computern ermöglichen. Zusätzlich vielen Leuten im Internet die mir mit vielen Beispielen, Anleitungen und Erklärungen geholfen haben an diesen Punkt zu kommen, was sonst so nicht ohne weiteres möglich gewesen wäre.

Quellen

  • https://de.wikipedia.org/wiki/Secure_Shell
  • https://www.openssh.com/history.html
  • https://www.openssh.com/
  • https://wiki.archlinux.org/title/OpenSSH
  • https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/s1-ssh-configuration
  • https://wiki.debian.org/SSH
Lorenz Kästle
Lorenz Kästle
Consultant

Lorenz hat seinen Bachelor der Informatik an der FAU gemacht und sich zuletzt mit Betriebssystemen dort beschäftigt. In seiner Freizeit beschäftigt er sich ein wenig mit XMPP und der Programmiersprache Erlang.

Windows 11 Release und was ihr wissen müsst!

 

Windows 11 steht vor der Tür! Seit dem 5. Oktober wird auf ausgewählten Systemen das Upgrade des neuen Betriebssystems angeboten. Ein neues Design sowie weitere Features erleichtern euch die Bedienung und Anpassung eures Systems. Ein Schelm wer die Ähnlichkeit zu MacOs erkennt. Vom neuen Startmenü über Updates zu Microsoft Teams bis hin zu der nativen Unterstützung von Android Apps bietet Windows 11 noch eine Vielzahl an Neuerungen wobei einige Features erst später implementiert werden sollen. Wer bereits vor einigen Wochen eine Preview von Windows 11 geladen hat, wird wohl gemerkt haben, dass die Systemanforderungen auf neuere Systemhardware zielt. Die wichtigsten Anforderungen auf einen Blick:

  • Prozessor: 1 Gigahertz (GHz) oder schneller mit 2 oder mehr Kernen auf einem kompatiblen 64-Bit-Prozessor oder SoC (System on a Chip)
  • RAM: 4 Gigabyte (GB)
  • Speicher 64 GB oder größeres Speichergerät
  • Systemfirmware UEFI, aktiviert für sicheren Start
  • TPM Trusted Platform Module (TPM) Version 2.0
  • Grafikkarte Kompatibel mit DirectX 12 oder höher mit WDDM 2.0-Treiber
  • Außerdem wird eine Internetverbindung mit einem Microsoft-Konto vorausgesetzt

Die komplette Liste der Systemanforderungen und Features seht ihr hier: Windows 11-Spezifikationen, -Funktionen und -Computeranforderungen

 

Features für Entwickler

Windows 11 bietet den neuen PWABuilder3, bei dem Entwickler in kürzester Zeit eine PWA aus ihrer Web-App erstellen können. Für die Erstellung hybrider Webanwendungen, stellt Windows 11 die WebView2-Runtime zur Verfügung. Das Windows Terminal und die neuen Microsoft Edge DevTools können weiterhin verwendet werden, da sie jetzt in Windows 11 enthalten sind. Die Windows App SDK macht es einfacher, Windows 11 Features für Apps zu integrieren. Entwickler können mit dem neuen ARM64 Emulation Compatible ABI Apps erstellen, die nativ unter Windows auf ARM laufen, unabhängig davon, ob als Win32, Universal Windows App oder ein anderes App-Framework.

 

Neuerungen für Gaming-Enthusiasten

Mit der Xbox-Technologie gibt es nun auch AutoHDR für Titel, die DirectX 11 oder DirectX 12 verwenden, selbst wenn diese die HDR-Ausgabe nicht unterstützen. Ebenfalls kommen neue Features wie DirectStorage (auch für Windows 10 verfügbar), die eine mindestens 1 TB große NVMe-SSD voraussetzen, um Ladezeiten zu verkürzen und schneller ins Spielgeschehen eintreten zu können. Bei DirectStorage werden die Daten der schnellen NVMe-SSD direkt an den RAM weitergegeben, so wie es bereits bei der Xbox Series X|S der Fall ist.

 

Weitere Features die zu erwähnen sind, ist die Integration von Microsoft Teams, das ein neues Design erhält und nun wie bei macOS direkt auf der Taskleiste liegt. Zusätzlich können Widgets die wir noch von Windows Vista kennen auch an der Taskleiste fixiert und abgerufen werden.

 

Für alle die noch nicht updaten können oder wollen: Windows 10 wird nach aktuellen Angaben von Microsoft bis 14. Oktober 2025 supported wobei man hier von einem “Retirement Date” spricht.

Aleksander Arsenovic
Aleksander Arsenovic
Junior Consultant

Aleksander macht eine Ausbildung zum Fachinformatiker für Systemintegration in unserem Professional Service. Wenn er nicht bei NETWAYS ist, schraubt er an seinem Desktop-PC rum und übertaktet seine Hardware. Er ist immer für eine gute Konversation zu haben.

Standards vs. Apps

Apps

Eine haeufig gehoertes Thema fuer Absprachen dieser Tage ist gern mal
der Abgleich der Kommunikationsapps um eine gemeinsame Teilmenge zu
finden, die man dann in Zukunft verwenden koennte. Das Ergebnis ist dann,
abhaengig von der Gruppengroessee und der Interessenlage der Beteiligten
verschieden zufriedenstellend und kann durchaus zu der Installation
von Apps fuehren.

Chatapps

Man koennte sich natuerlich an der Stelle dann auch die Frage stellen,
warum es das braucht, warum ein Telegramm nicht mit einem Signal, iMessage,
Snapchat oder [beliebige Chatapp hier einfuegen] reden kann. Es waere ja irgendwo
schon gemuetlicher nur eine App zu haben. Von der Funktionalitaet sind
solche eher selten und in wenigen Punkten unterschiedlich.
Und die Antwort darauf kann schlechterdings eine technische
sein, Protokolle fuer solche Zwecke gibt es und eine “Uebersetzungs”-Schicht
einzubauen waere vermutlich ein vertretbarer Aufwand.
Es wuerden sicherlich ein paar Sachen nicht ueber verschiedene Dienste
hinweg funktionieren, aber 1:1-Chats und Gruppen waeren ja schon ausreichend.

Die naechste Option waere ja dann, wenn die Firmen hinter den Apps schon nicht miteinander
reden wollen, dass man auf seinem Geraet nur eine App installiert, die sich dann
mit allen diesen Diensten verbindet und das vermischt. Etwas frei zitiert:

“One App to rule them all, one app to bind them,…”
– Inschrift auf dem einen Ring, stark verfaelscht

Ein erstrebenswertes Ziel, wuerde es doch ebenefalls den Aufwand reduzieren (ganz zu schweigen
von Speicherplatz und Datenvolumen). Aber auch das ist nicht gaengig.

Angesichts der finanzstarken Lage vieler Betreiber solche Apps scheint es
mir unwahrscheinlich, dass solche Themen an einem “Koennen” scheitert.
Ein Erklaerungsansatz fuehrt diesen Zustand auf das Geschaeftsmodell zurueck,
das viele der Betreiber fahren.
So wird bei der Benutzung des Dienstes und durch die Apps oft das Verhalten
der Benutzer:innen ausgespaeht und dieser Datensatz direkt oder indirekt an die Kund:innen
verkauft. Der Kundenstamm rekrutiert sich dann aus den ueblichen Werbeleuten,
Quacksalbern, Propagandisten, Lobbyisten und Meinungsmachern (Mehrfachnennung moeglich,
Redundanz wahrscheinlich).
Interaktion fuer Leute ausserhalb des eigenen Systems zu erlauben wuerde
das Risiko der Reduktion der eigenen “Datenernte” beherbergen, da Personen
ausserhalb des Systems sich nicht die App installieren muessten, um mit einem Gegenueber innerhalb des Systems
zu kommunizieren und es wuerden vielleicht sogar welche die App entfernen.
Es waere also fundamental geschaeftsgefaehrdend, ein “offeneres” System zu bauen.

Videochats

Obwohl es schon vor 2020 diverse Videokommunikationssysteme gab, ist deren
Bedeutung stark angestiegen. Die Gruende dafuer sind offensichtlich, doch wie ist
denn der Zustand diese Oekosystems dieser Tage?
Das traurige Bild, dass sich einem bei der Betrachtung bietet, ist wiederum
das der verschiedenen Apps, die nicht miteinander interagieren.
Jetzt stellt sich bei verschiedenen Personenkreisen immer wieder die Frage,
ob man denn Zoom-, Teams-, Hangouts- oder sonst irgendein Meeting hat.
Dafuer gibt es dann jeweils eine dazugehoerige App oder man hofft, dass es noch
in einem von drei verschiedenen Browsern mit allen Funktionen laeuft.
Mit Glueck und am zweiten Vollmondtag in geradzahligen Monaten trifft das sogar zu.

Aber auch hier ist die gewuenschte Funktionalitaet sehr klar umrissen und wird von
allen abgedeckt. Es sollen n Teilnehmer 1 bis (n-1) Video- und Audiostreams bekommen
und auf der Seite ist ein Chatfenster.
Das klingt wiederrum technisch ueberschaubar, aber dennoch kann ich nicht mit
einem Teams-Client in ein Zoom-Meeting.
Das Szenario aehnelt somit in wesentlichen Punkten dem Zustand der Messenger,
der weiter oben beschrieben wurde.

Und damit kommt hier die rhetorische Frage, die zum naechsten Abschnitt ueberleitet:
Ginge das denn auch anders? Und wenn ja, wo?

Telefon

Als Gegenbeispiel kann hier die Telefonie dienen, ein Gespraech quer ueber den
Globus mit einer beliebigen Person ist recht leicht denkbar, soweit
diese auch ueber einen Telefonanschluss (oder heutzutage vielleicht eher einen Handyvertrag)
verfuegt. Dabei muss man nicht nach dem speziellen Dienstanbieter fragen, auch der Hersteller
des Geraetes interessiert wenig, wichtig ist einzig die Nummer.
Selbstverstaendlich gibt es da einige Einschraenkungen, wie etwa die Kosten und diverse
Altlasten, aber das ist in einem System, das deutlich aelter als die meisten Benutzer ist,
kaum verwunderlich. Verschiedenste Protokolle und Standards werden kombiniert um am
Ende das Gespraech zwischen zwei (oder mehr) Personen zu ermoeglichen.

Internet

Auch das Internet selbst ist ein Netzwerk von vielen verschieden Teilnehmern, die
ueber standardisierte Schnittstellen Daten austauschen und viele verschiedene Medien und
Uebertragungsvarianten kombinieren.
Es gibt kein Instagram-, kein Youtube- und kein TikTok-Internet, auch wenn es von
vielen hauptsaechlich dafuer verwendet wird.
Gemeinsame Standards schaffen eine Basis, die dies ermoeglicht.

Auch hier bietet es sich an, einen Blick auf das Geschaeftsmodel zu werfen,
Internet- und Telefonieanbieter verkaufen Zugaenge zu einem Netzwerk, beziehungsweise,
sie vermieten sie, da es meistens eher ein Abonnementmodel ist.
Es ist damit leicht vorstellbar, dass ein anbietendes Unternehmen dann ein gesteigertes Interesse daran
hat, den bestmoeglichen Zugriff auf das restliche Netzwerk zu bieten.
Soweit zumindest Theorie, in der Praxis ist das mit den Internetanbietern eine etwas
durchwachsenere Erfahrung.
So moechte sich etwa mindestens eine der groesseren Anbieter hierzulande den Zugang zu seinen
Kunden teuer bezahlen lassen und ist deshalb weniger auf gute Vernetzung bedacht als darauf
viel Geld dafuer einzustecken. Leidtragenden sind hierbei die Kleinkunden, die als
Verhandlungsmasse dienen. Dass das Geld dann auch nicht wirklich in das System reinvestiert
wird um zukunftsfaehige Verbindungen zu schaffen kommt dazu.
Aber das ist ein System von falschen Anreizen und hier nicht direkt Thema.

In Summe kann man heutzutage mit standardisierten Netzwerkprotokollen (UDP, TCP, HTTP, IMAP,…)
Daten zu fast beliebigen Punkten auf dem Globus schicken. Welches Programm ich dafuer verwende
ist dafuer (abgesehen natuerlich von der implementierten Funktionalitaet) irrelevant.

Standards

Es gibt viele verschiedene Formen von Standards, die ich hier, im Sinne des Artikels, in zwei
Gruppen teilen will.
Da sind zum einen Standards die eine oder mehre bestimmte Eigenschaften sicherstellen|definieren
um einen gewissen Zweck zu erreichen. Ungluecklicherweise ist diese Definition sehr vage,
deshalb moechte sie kurz ein wenig ausfuehren und Beispiele anbringen.
So gibt es etwa eine Klassifizierung fuer LASER (DIN EN 60825-1) die Laserquellen und -anlagen
nach ihrem Gefaehrdungspotential einteilen. Dann gibt es Richtlinien/Regularien, welche Klasse
in welcher Situation erlaubt ist und man kann beim Bau von entsprechenden Anlagen dann Massnahmen
oder Mechanismen einsetzen die zur Erreichung der geplanten Klasse dienlich sind (etwa Schutzvorrichten verbauen oder
Schutzkleidung vorschreiben).
Aehnliche Regelungen gibt es fuer alle moeglichen Arten von gesundheitlichen Gefahren, wie etwa im Brandschutz,
Laermbelastung, Luftverschmutzung, Arbeitszeiten und vielem mehr.

Die Art von Standards, um die es hier aber eigentlich geht, sind die Definitionen von Schnittstellen.
Sie stellen eine Art “passive Kommunikation” dar. Eine Schnittstellendefinition sagt mir, wie meine
Gegenseite in relevanten Punkten aussieht und zwar so, dass die genaue Implementierung nicht relevant
fuer meine Seite ist.
Ein greifbares Beispiel sind zum Beispiel metrische Gewinde (z.B. DIN ISO 1502:1996-12), ein M10er
Schraube wird immer in ein M10er Gewinde passen (solange beide innerhalb der Toleranzen sind), ohne,
dass sich der Hersteller der Schrauben und die Person, die das Gewinde bohrt, jemals persoenlich
absprechen muessten.
Diese Art von Standard gibt es, selbstverstaendlich, auch im Bereich der elektronischen Kommunikation oder Informationstechnik.
So sind etwa bei der IETF wichtige Protokolle standardisiert (IP, TCP, …) oder von der ITU die eher physikalischen
Schnittstellen normiert.

Diese Standards werden teilweise von mehr oder weniger offiziellen Stellen erstellt und betreut, teilweise von
von anderen Organisationen (etwa die Mediawiki-API von der Wikimedia-Gesellschaft, die Linux-API von der Linux Foundation oder
zahlreiche andere Projekte aus dem Bereich Open Source und der freien Software).
Dabei gibt es viele verschiedene Variante und Unterschiede, aber einer der wesentlichen ist, wie der Zugang zu dem
Standard geregelt ist. Waehrend etwa die RFCs frei und offen zugaenglich sind (also auch kostenfrei), sind DIN-Normen
zu erwerben, was ein gewisses Hindernis fuer Umsetzung darstellt.

Ein Standard erfordert natuerlich auch gewisse Zugestaendnisse, so ist etwa die Bereitstellung einer oeffentlichen
API bei einem Programm oder einem Dienst nicht wirklich nuetzlich, wenn sich diese API in kurzen Zeitraeumen
haeufig aendert. Das Erstellen von Drittanbietersoftware wird dadurch aufwaendiger und es erfordert haeufiger Updates
beim Benutzer. Eine Schnittstelle ist also auch ein zusaetzlicher Aufwand und eine Verantwortlichkeit gegenueber
Nutzern.
Dies hat natuerlich auch Nachteile, so koennen neue Features nicht leichtfertig eingebaut werden oder alte
Fehler nicht sofort oder auf beliebige Art und Weise behoben werden.
Ein Beispiel dafuer ist etwa Email, ein System, dass in einer anderen Zeit erdacht wurde und an vielen
Stellen Probleme hat. So waeren etwas Privatsphaere-foerdernde Verschluesselung, eine technisch
saubere und verifizierbare Signatur und andere Erweiterungen oder
Aenderungen durchaus technisch moeglich (moderne Messenger leben das ja teilweise vor), aber durch die Notwendigkeit
des Erhalts einer minimalen gemeinsamen Basis rottet das System auf einem Stand von vor fast 30 Jahren dahin.
Auf der positiven Seite kann man auch noch Mails schreiben indem man eine direkte Netzwerkverbindung zu einem
freundlichen Mailserver aufmacht (und schnell tippen kann).
Diese Problematik fuehrt teilweise zur Abkehr von offenen Standards, etwa beim Messenger “Signal”. Dort wird
auf ein zentralisiertes System gesetzt statt auf eine foerderiertes um den Stand aller
Teilnehmer einigermassen gleich zu halten und gleichzeitig neue Features implementieren zu koennen.

Der Punkt

Nach der langen Einleitung kommen wir nun endlich zum wirklichen Punkt des Artikels.
Im ersten Teil duerfte vermutlich das Wort App ins Auge gefallen sein.
Viele Dienste sind heutzutage mit einer eigenen App verbunden. Dies hat sich soweit
durchgesetzt, dass man bei irgendeinem neuen Dienst inzwischen sofort gefragt wird, was man
installieren muss.
Und dies oft ohne technische Notwendigkeit.

Man ist inzwischen daran gewoehnt, dass man sich fuer einen Dienst eine neue App installieren muss,
die dann froehlich das Addresbuch oder das Nutzungsverhalten irgendwo ins Internet laedt.
Daran ist man gewoehnt.
Der Hersteller der App jederzeit Einschraenkungen einfuehren, etwa Features entfernen, die Funktionalitaet
veraendern oder andere beliebige Masnahmen vornehmen.
So koennen etwa auch bestimmten Inhalte mehr oder weniger effektiv verboten werden.
Auch daran ist man gewoehnt.
Man ist nicht nur der Willkuerlichkeit ausgeliefert, es geht auch viel Potential verloren. So kann es innerhalb
einer Firma leicht zu einer gemeinsamen Perspektive kommen, die nicht unbedingt der der Nutzer entspricht.
Manchmal braucht es die Perspektive von Aussenstehenden um die Probleme zu identifizieren (und zu beheben).
Dies ist nicht moeglich, wenn sich Aussenstehende nicht mit den Moeglichkeiten auseinander setzen koennen
oder nicht duerfen.
Auch daran hat man sich mittlerweile gewoehnt.

Durch diese geschlossenen Oekosysteme entsteht auch gesamtgesellschaftlicher Schaden und neue Risiken.
So sind bereits einige Monopolisten entstanden, die man in bestimmten Bereichen fast nicht umgehen kann.
Ein Unternehmen oder eine Behoerde ohne Microsoft-Komponenten ist kaum denkbar, eine Kommunikation mit Menschen
ohne Whatsapp ist zumindest schwieriger.
Fuer viele proprietaere Softwareloesungen gibt es keine Dokumentation der Datenformate, so dass ein Wechsel
des Systems zwischen prohibitiv teuer und kaum moeglich rangiert.
Teilweise laesst sich auch ein altes System oder ein Teil davon nicht an ein Neues anbinden, weil keine Schnittstellen
existieren oder die vorhandenen nicht dokumentiert sind. Eine entsprechende Anekdote eine Systems, dass ausgemustert
werden musste, weil einige Teile davon veraltet waren, duerften die meisten inzwischen kennen.
Der entsprechende Mehraufwand schlaegt sich natuerlich in unnoetigen Kosten, Muell und verschwendeter Zeit nieder.
Auch aus dem Blickpunkt der Softwaresicherheit ist eine solche Monokultur durchaus bedenklich, wie die
Windows-Sicherheitsluecken der letzten Jahre gezeigt haben. Bei einer standardisierten Schnittstelle mit
verschiedenen Implementierungen gibt es zumindest eine gute Wahrscheinlichkeit, dass nur eine Implementierung
betroffen ist und damit der Schaden durch einen Angreifer reduziert wird.

Schluss

Meiner Meinung nach, brauchen wir fuer die Zukunft in unserer digitalen Welt wieder mehr
Standards (oder zumindest die staerkere Implementierung derselben) und mehr Fokus auf Protokolle, statt dem Fokus auf eine “App”.
Statt hunderte und tausende Male das gleiche neu und ein wenig anders zu implementieren und zwar meistens halbgar,
koennte festgelegt werden was da im Grunde passiert und es in Standards und Protokollbeschreibungen zusammenfassen.
Die Analyse und die Motivation fuer den Status Quo habe ich hier kaum bis gar nicht vorgenommen,
diese kommt vielleicht nochmal in einem weiteren Artikel, aber ich halte ihn, kurz gefasst, fuer ein Resultat
dieses Wirtschaftssystems.
In einer digitalen Welt, in der Konzerne auf eine Monopolstellung hinarbeiten und die meisten Gelder fuer
Konsumentensoftware und -dienste aus Werbeeinnahmen stammen, ist eine Verbesserung nicht so leicht denkbar.
Ganz allgemein ist ein Fokus auf Gewinnmaximierung vermutlich nicht die beste Zielsetzung aus Perspektive der
Softwareanwender.

Fuer die nachhaltigere, resilientere und vielfaeltigere Gesellschaft die fuer die Zukunft
gebraucht und teils gewollt wird, muss auch das digitale Oekosystem angepasst werden.
In dem jetzigen Zustand wirkt es eher unzureichend und zu stark auf Interessen Einzelner
fokussiert.

Ich habe versucht viel in diesen Text hineinzubringen, was vielleicht eher schlecht als recht dort
Platz gefunden hat. Ueber Kritik, Verbesserungen und vielleicht auch Gegenmeinungen wuerde ich mich
sehr freuen.
Fuer die Kuerze und die daraus folgenden Unvollstaendigkeiten moechte ich mich entschuldigen.

Wer sich fuer die hier angesprochenen Themengebiete interessiert, kann auch noch einen Blick auf folgende Themen werfen:

  • XMPP, ein vergleichsweise frueher Ansatz fuer einen sich fortentwickelnden Standard fuer allgemeine Chatdienste, nicht so haeufig zu sehen, aber vermutlich haben Sie es schon mal verwendet
  • Matrix, aehnlich zu XMPP aber juenger. Ebenfalls chatten in einem foerderierten Netzwerk
  • Fediverse, ein Ansatz fuer soziale Netzwerke, ebenfalls foerderiert, beinhaltet z.b. Mastodon (Microblogging wie Twitter), Peertube (Video-Plattform wie Youtube) und diverse andere Dienste und Protokolle
Lorenz Kästle
Lorenz Kästle
Consultant

Lorenz hat seinen Bachelor der Informatik an der FAU gemacht und sich zuletzt mit Betriebssystemen dort beschäftigt. In seiner Freizeit beschäftigt er sich ein wenig mit XMPP und der Programmiersprache Erlang.

Redis Eviction Policies

After install Redis you don’t have any settings configured to control memory consumption. In Production this brings OOM to the arena which leads into a broken applications.

First thingy what users do is to configure MaxMemory config setting (like me of course ;-)). In combination with a noeviction policy (which is also the default) the documentation says:

[…] return errors when the memory limit was reached and the client is trying to execute commands that could result in more memory to be used (most write commands, but DEL and a few more exceptions).

The bad news is, you’ll have a broken application again. Most web apps just use Redis as an uncontrolled cache data sink and left over to you how to handle it. For 99.9% of the use-cases you just need to configure a cache policy, or in Redis-speech, an Eviction Policy, which means:

maxmemory 128mb
maxmemory-policy allkeys-lru
maxmemory-samples 10

1. You allow roughly 128MB of memory for Redis
2. Redis tries to remove the less recently used (LRU) keys first
3. Because LRU is not a exact LRU algo, you use 10 samples to help the algorithm to find the items

Try to explain by counters:

Icinga Redis Plugin Output:

Above is a icinga redis check plugin output. Which shows a roundabout memory use of 108% – which is more than the configured 128M 100% base.

Grafana Graph (Telegraf Redis Input Plugin)

Here is the config change made on the 02/04 down to 128M MaxMemory and the LRU Eviction Policy. The memory footprint stays the same. The change is more granular if you zoom in:

If the allkeys-lru does not work for you, give the documentation a try. There is a lot you can do to keep your applications up and running and make Redis a fluently easy dependency.

Marius Hein
Marius Hein
Head of ITSM

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert und viele Jahre in der Softwareentwicklung gearbeitet. Mittlerweile ist er Herr über die interne IT und als Leiter von ITSM zuständig für die technische Schnittmenge der Abteilungen der NETWAYS Gruppe. Wenn er nicht gerade IPv6 IPSec Tunnel bohrt, sitzt er daheim am Schlagzeug und treibt seine Nachbarn in den Wahnsinn.