NETWAYS Blog

Linux Monitoring mit Icinga – so löst du bekannte Probleme

von Lorenz Kästle | Jun 5, 2023 | NETWAYS, Monitoring & Observability

This entry is part 5 of 5 in the series Icinga. Einfach. Erklärt.

Beim Betrieb von Computerinfrastrukturen treten früher oder später Probleme auf. Typischerweise schon bei der Einrichtung und später bei Änderungen, aber auch im “Normalbetrieb”. Die Ursachen dafür sind entweder extern, intern oder eine Mischung aus beidem. Zu regelmäßig auftretenden externen Ursachen zählen zum Beispiel eine Änderung des Kontextes der Maschinen, wie etwa ein Strom- und/oder Netzwerkausfall oder Updates, die etwas am äußeren Verhalten eines Programmes ändern.
Aber auch schlicht der Fortlauf der Zeit muss hier erwähnt werden. Eine tragische und unaufhaltsame Gewissheit, die durchaus technische Bedeutung hat, etwa in der Gültigkeit von Zertifikaten oder Problemen mit der Zeitsynchronisation.

Intern können Probleme durch eine bestehende Fehlkonfiguration entstehen. Dieser Begriff ist jedoch etwas Vorsicht zu genießen, da es durchaus Szenarien gibt, in denen eine bestimmte Konfiguration zum Zeitpunkt der Entstehung durchaus richtig und angemessen war. Oftmals zeigt sich erst im Verlauf von Monaten oder Jahren oder durch Änderung des Kontextes, dass die damals „richtigen“ Einstellungen problematisch sind.

An dieser Stelle tritt Monitoring auf den Plan und nimmt seinen Platz in einer gut geplanten IT-Infrastruktur ein. Enterprise-Monitoringlösungen wie Icinga versuchen bei der Voraussage, Entdeckung und Behebung von Problemen zu helfen. Um dir einen guten und vielfältigen Eindruck von den Möglichkeiten eines gut eingerichteten Monitoringtools zu geben, gehe ich in diesem Blogpost auf einige klassische und häufige Probleme, speziell im Kontext von Linux (und damit häufig auch anderen unixoiden Betriebssystemen) ein.

Im Laufe meines Beitrags werde ich regelmäßig auf die Monitoring Plugins eingehen, da diese beim Erkennen von Problemen eine wichtige Rolle spielen. Diese Zusammenstellung an Plugins ist neben Icinga auch für den Einsatz mit anderen Monitoring-Systemen geeignet, solange diese die Monitoring Plugins unterstützen.

Gängige Probleme auf Linux-Maschinen und Monitoringlösungen mit Icinga

Dateisysteme erreichen die Kapazitätsgrenzen

Ein nicht sehr häufiges (bezogen auf die Auftretenswahrscheinlichkeit), aber fatales Problem ist ganz klassisch, dass im Betrieb ein Dateisystem bis an die Kapazitätsgrenzen vollläuft. Dies führt üblicherweise dazu, dass das System seinen Betrieb ganz oder teilweise einstellt, jedoch ist das Fehlerbild potenziell auf den ersten Blick nicht offensichtlich. Beispielsweise können Programme keine großen Dateien mehr anlegen, beziehungsweise wird das Schreiben derselben abgebrochen, aber kleine, temporäre Dateien sind vielleicht (für den Moment) noch möglich.
Das führt je nach betrachteter Software und deren Fehlerbehandlung dazu, dass erst mal noch alles in Ordnung erscheint. Ein Webdienst wird weiterhin ansprechbar sein und kleine Abfragen durchaus beantworten, dann aber bei anderen (bei denen dann versucht wird größere Dateien zu schreiben) die Bearbeitung abbrechen und nur noch Fehler ausgeben, aber nicht vollständig abstürzen.

Ein anderes Beispiel ist eine Datenbank, die zwar noch lesende Zugriffe durchführen kann, aber eben keine Schreibenden. In diesen Fällen wird ein einfacher Test auf die Funktionalität des Dienstes (das init-System des Systems bescheinigt, dass der Dienst läuft; entsprechende Anfragen auf bestimmten Ports werden noch angenommen) ein positives Ergebnis bescheinigen. Trotzdem ist die eigentliche Hauptfunktionalität nicht mehr gegeben.

In einem typischen Szenario, in dem die Checks für das System lokal (oder aus der Ferne über gängige Transportwege wie SSH) ausgeführt werden, ist die klassische und gängigste Wahl beim Monitoring mit Icinga check_disk ( aus den Monitoring Plugins (Debian- und Suse-artige Distributionen) bzw. nagios-plugins (RedHat-Familie)). Zwar ist die Benutzung teilweise etwas ungewöhnlich (Stichwort Gruppierung), aber für unkomplizierte Dateisystem-Setups (und damit die häufigsten) durchaus noch ausreichend.

Ein typischer Aufruf könnte etwa so aussehen:

# ./plugins/check_disk -w 2% -c 1% \
    -X none -X tmpfs -X fuse.portal -X fuse.gvfsd-fuse \
    -X sysfs -X proc -X squashfs -X devtmpfs
DISK OK - free space: / 32892MiB (58% inode=83%); /boot 257MiB (57% inode=99%); /var 147782MiB (65% inode=92%); /home 154929MiB (34% inode=96%); /boot/efi 503MiB (98% inode=-);| /=24961351680B;61414781747;62041463193;0;62668144640 /boot=197132288B;482974105;487902412;0;492830720 /var=83065044992B;245826626519;248335061483;0;250843496448 /home=314740572160B;492755872645;497783993794;0;502812114944 /boot/efi=7340032B;524078284;529426022;0;534773760

# ./plugins/check_disk -w 2% -c 1% -N ext2 -N ext4
DISK OK - free space: / 32892MiB (58% inode=83%); /boot 257MiB (57% inode=99%); /var 147782MiB (65% inode=92%); /home 154935MiB (34% inode=96%);| /=24961351680B;61414781747;62041463193;0;62668144640 /boot=197132288B;482974105;487902412;0;492830720 /var=83065044992B;245826626519;248335061483;0;250843496448 /home=314734280704B;492755872645;497783993794;0;502812114944

In diesem Beispiel werden die Grenzwerte für Dateisysteme so gesetzt, dass der Warnzustand bei weniger als zwei Prozent freiem Speicherplatz und der Kritische bei weniger als einem Prozent auftritt. Die Sammlung an -X-Parametern (beziehungsweise das komplementäre -N) schließt diverse Dateisystemtypen aus, die nicht geprüft werden sollen. Die von mir in diesem Beispiel ausgeschlossenen Dateisystemtypen fallen nicht unter die Kategorie, die man hier im Auge hat. Hierbei handelt es sich um Dateisysteme die meine Dateien persistent auf magnetische Platten oder Halbleiterspeicher fixieren.

Alternativ können check_disk gezielt ein oder mehrere Befestigungspunkte übergeben werden:

./plugins/check_disk -w 2% -c 1% -p /home -p /boot
DISK OK - free space: /home 154935MiB (34% inode=96%); /boot 257MiB (57% inode=99%);| /home=314733232128B;492755872645;497783993794;0;502812114944 /boot=197132288B;482974105;487902412;0;492830720

Zur Feinjustierung existieren noch mehr Optionen, ein check_disk --help kann sehr hilfreich sein. Das Setzen von Grenzwerten für die Benutzung von Inodes mittels -W und -K ist leider ein viel zu häufig vergessenes Problem. Ein Mangel an freien Inodes bietet ein sehr ähnliches Bild wie eine Mangel an freiem Platz, jedoch ist es weniger offensichtlich (und tritt auch deutlich seltener auf).

Alternativen zu check_disk sind diverse andere Monitoring Plugins, wie etwa disk_usage der Linuxfabrik. Damit wird zu großen Teilen dieselbe Problematik abgedeckt. Weiterhin gibt es Plugins, die Rand- oder Sonderfälle behandeln, die außerhalb des Funktionsumfangs der klassischen Plugins liegen.
Sonderfälle dieser Art wären etwa kompliziertere Setups mit Dateisystemen mit einer größeren Menge an Funktionen wie etwas btrfs, xfs oder zfs. Hier ist eine einfache Aussage, wie die von mir bereits betrachtete “Wie viel Platz ist frei/belegt?” nicht so einfach zu treffen. Als wäre das noch nicht genug, gibt es hierbei noch die Problematik von Netzwerk- und verteilten Dateisystemen, die auch etwas komplexer ist.

TLDR

Mindestens das root-Dateisystemen sollte mit check_disk oder etwas Ähnlichem überwacht werden, als Checkintervall reichen fünf Minuten locker aus. Zusätzliche Dateisysteme für das Persistieren von Daten sollten äquivalent überwacht werden. Auch sollte überwacht werden, ob noch genügend Inodes frei sind.

Swapping

Swap-Speicher ist ein Bereich im Langzeitspeicher, der zur Auslagerung von Arbeitsspeicherinhalten dienen kann (Stichwort “Auslagerungsdatei” unter Windows). In Zeiten von sehr limitierter Arbeitsspeicherkapazität eine nützliche Funktion, um kurzfristige Kapazitätsengpässe handhaben zu können, ohne Nutzerprogrammen den angeforderten Speicher zu verweigern. Zusätzlich dient der Swap-Bereich heutzutage oft als Speicherort für Arbeitsspeicherinhalte, wenn eine Maschine in einen Ruhezustand versetzt und der (physikalische) Arbeitsspeicher ebenfalls außer Betrieb geht (Stichwort: “Hibernation”).

Diese Möglichkeiten kommen natürlich mit einem Preis. Festspeicher (“long term storage”) ist immer noch um Größenordnungen langsamer als Arbeitsspeicher (der wiederum deutlich langsamer als die
Speicher (“L*-Caches”) in der CPU ist). Die Auslagerung von aktiv genutzten Arbeitsspeicherinhalten kann dazu führen, dass ein System langsam bis an die Grenze der Benutzbarkeit gebracht wird. Das ist bei einem PC störend und frustrierend, kann jedoch bei Produktivmaschinen teilweise noch schlimmere Konsequenzen haben.
Eine Maschine, die ohnehin gerade unter Last steht, weil sie zum Beispiel sehr viele Abfragen erhält, wird, wenn das Swapping beginnt, sehr viel langsamer werden, was dann die Belastung typischerweise nicht senkt. Es sollte deshalb sichergestellt sein, dass die Nutzung von Swapspeicher (im Normalbetrieb) sowohl in Hinsicht der Quantität (Prozent an freiem/benutzten Speicher) als auch im zeitlichen Rahmen begrenzt ist.

Klassisch bietet sich hier check_swap (wiederum Monitoring Plugins|nagios-plugins) an, beispielsweise:

# ./plugins/check_swap -w 60% -c 20%
SWAP OK - 100% free (36863MB out of 36863MB) |swap=38653657088B;23192194200;7730731400;0;38653657088

In diesem Beispiel wird getestet, ob weniger als 60 Prozent des Swapspeichers frei ist (Grenzwert für WARNING) bzw. 20 Prozent (Grenzwert für CRITICAL). Eine temporär hohe Nutzung mag (je nach Szenario) durchaus erlaubt sein, aber längerfristig dürfte dies ein Problem darstellen.
Als groben Richtwert könnte man vielleicht fünfzehn Minuten anlegen, nach denen jemand alarmiert werden sollte. Das Checkintervall dürfte mit ein, zwei oder drei Minuten ausreichend bedient sein.

Wie hoch ist die Systemlast?

Ganz generell sind Systemressourcen limitiert, seien es CPU-Zeit, Speicher, andere Prozessoren und natürlich die ganzen Schnittstellen dazwischen. Manchmal lässt sich nicht oder nur schlecht an einzelnen kleinen Metriken ablesen, wenn ein Engpass besteht, zumindest wenn die Werte nur eine Teilmenge aller Werte darstellen und die wichtigen Metriken nicht enthalten sind. In unixoiden Systemen gibt es aus diesen und anderen Gründen die load-Metrik, die zwar die Details vermissen lässt, aber zuverlässig einen Indikator für ein Problem liefert.

Händisch kann die load mit dem Programm uptime (beispielsweise) abgerufen werden:

# uptime
 12:21:58 up  1:25,  1 user,  load average: 0.40, 0.38, 0.23

Die load besteht hier aus den drei Zahlenwerten 0.40,0.38 und 0.23, mit einem Aggregatswert über eine Minute, fünf Minuten und fünfzehn Minuten.

Alternativ direkt aus dem Proc-Dateisystem:

# cat /proc/loadavg
0.00 0.06 0.12 1/1316 27272

Und in “proc (5)” findet sich dann auch eine Erklärung der Zahlen.

Wer sich jetzt nicht jedes Mal die Arbeit machen will, diese Werte mit einem händisch eingegebenen Befehl aufzurufen und auszulesen, kann auf eine automatisierte Überwachung durch Check-Plugins, in diesem Fall check_load (Monitoring Plugins|nagios-plugins) setzen. Die Grenzwerte sind in diesem Fall etwas schwierig zu bestimmen, da die “zu hohe Last” stark vom Kontext abhängt.
Generell lässt sich sagen, dass eine load von eins fast der Idealwert ist, da sich damit (im Durchschnitt) immer ein Prozess in der Warteschlange befindet.

Für Werte größer als eins wird die Beurteilung schwieriger. Die Zahlenwerte aus meinem Beispiel stammen von einem Laptop ohne größere Aktivitäten (nur zwei Webbrowser). Für eine größere Maschine, etwa einen Datenbankserver mit 16 (oder mehr) CPU-Kernen, kann ein Wert von 40 auch normal sein und durchaus noch einen akzeptablen Betriebszustand darstellen. Die Option -r für check_load dividiert die load-Werte durch die Anzahl der CPU-Kerne, um eine gewisse “Normalisierung” der Werte zu erreichen, die meistens angemessen ist.

Ein angemessenes Monitoring wäre ein Checkintervall von einer bis drei Minuten mit Benachrichtigung nach fünfzehn Minuten. Als Grenzwerte wären 3,3,3 für WARNING und 5,5,5 für CRITICAL als einigermaßen konservative Einschätzung angemessen.

Ausfälle von Services (systemd) und Prozessen

In den meisten Fällen stellen Maschinen Dienste für Menschen oder andere Maschinen bereit und es ist normalerweise von gesteigertem Interesse, ob dieser Dienst auch läuft. In den meisten Linux-Distributionen ist systemd als Event- und Servicemanager im Einsatz und sollte dazu benutzt werden, durchgängig laufende Programme zu verwalten.

Mittels check_systemd lässt sich ermitteln, ob Dienste (bzw. generalisiert, systemd-units) in einem fehlerhaften Zustand sind oder nicht.

Dazu ein Beispiel mit dem SSH-Serverdienst (openssh):

# ./check_systemd.py -u ssh
SYSTEMD OK - ssh.service: active | count_units=490 data_source=cli startup_time=6.193;60;120 units_activating=8 units_active=332 units_failed=2 units_inactive=148

Im Hintergrund sind Dienste am Ende aber auch “nur” Prozesse und du möchtest potenziell diverse Eigenschaften von Prozessen überprüfen (etwa CPU-Nutzungszeit (in Prozent), oder die Größe des benutzten Speicherbereichs). Erste Anlaufstelle ist für mich check_procs.

Beispielsweise kannst du damit überprüfen, ob Zombieprozesse vorhanden sind:

# ./plugins/check_procs -s Z -w 1
PROCS OK: 0 processes with STATE = Z | procs=0;1;;0;

Ein weiterer Anwendungsfall ist die Überprüfung aller Prozesse, die mehr als zwei Prozent der CPU-Zeit verschlingen:

# ./plugins/check_procs --metric CPU -w 2
CPU WARNING: 1 warn out of 310 processes | procs=310;;;0; procs_warn=1;;;0; procs_crit=0;;;0;

Dateieigenschaften – warum Probleme auftreten können

An vielen Stellen muss überprüft werden, ob eine oder mehrere Dateien vorhanden sind und/oder bestimmte Eigenschaften aufweisen, beispielsweise ob sie älter oder jünger als ein gewisses (relatives) Datum sind, größer oder kleiner als ein Grenzwert sind oder bestimmte Berechtigungen haben. Die Ergebnisse einer solchen Überprüfung können als Indikator für ein Problem in einem Programm dienen, etwa, dass Dateien in einem Spooler-Verzeichnis nicht schnell genug abgeholt werden.

Glücklicherweise ist das ein Bereich, der sich relativ einfach durch selbstgeschriebene, auf den Nutzungsfall abgestimmte Skripte abdecken lässt. Wenn man den passenden find Befehl zusammengebaut hat, kann man nach den Monitoring Plugins Guidelines dann ein Monitoring Plugin bauen, dass den eigenen Spezialfall abdeckt.

Für etwas generellere Fälle gibt es mit check_file_age aber bereits eine Option, die zumindest das Überprüfen auf Alter und Größe erlaubt.

# ./plugins-scripts/check_file_age -f plugins-scripts/check_file_age -w 300:30000000 -c 1: -W 1:300
FILE_AGE WARNING: plugins-scripts/check_file_age is 516096 seconds old and 5193 bytes | age=516096s;300:30000000;1: size=5193B;1:300;0:;0

In diesem Beispiel sollte die Datei plugin-scripts/check_file_age älter als eine Sekunde sein (kritische Bedingung), zwischen 300 und 30000000 Sekunden alt (Bedingung für den WARNING-Zustand) und zwischen einem und 300 Bytes gross (zweite Bedingung für WARNING).

Für alle die es etwas vielfältiger mögen, wären die Monitoring Plugins der Linuxfabrik, die mit file beginnen, eine Option.

Schlusswort

Die angesprochenen Probleme sind natürlich nur ein kleiner Teil der möglichen Problemstellungen, mit denen man als Systemadministrator konfrontiert wird. Zudem habe ich mich für diesen Beitrag auch ausschließlich auf Themen innerhalb einer Maschine limitiert. Die Thematik der Netzwerkproblembehandlung hätte den Rahmen mehr als gesprengt, bietet aber ein gutes Thema für weitere Blogposts.

Ich hoffe, ich konnte anhand meiner gewählten Beispiele verdeutlichen, welche Möglichkeiten der Einsatz von Monitoringlösungen wie Icinga bietet, besonders dann, wenn du ein Unix-basiertes Rechner- oder Servernetz betreibst. Und auch wenn ich mich im Rahmen dieses Posts auf die Ausführung der Checks über die Konsole beschränkt habe, lass dich davon bitte nicht abschrecken. Natürlich können all diese Eingaben auch (bis zu einem gewissen Punkt) mit der grafischen Lösung Icinga Director und die Weboberfläche Icinga Web durchgeführt werden.

Falls du und dein Unternehmen jetzt noch Hilfe bei der Einrichtung und Konfiguration von Icinga benötigt, lass es uns einfach wissen!

In der Zwischenzeit, bleibt zu hoffen dass diese Lektüre jemandem geholfen hat und wenn (aber auch wenn nicht), dann würde sich der Autor über Kommentare freuen.

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.

Lies mehr von Lorenz und triff unser Team

Prometheus jetzt verfügbar

von Lorenz Kästle | Dez 22, 2022 | NETWAYS, Prometheus

Vielleicht dürfte dem einen oder anderen regelmässigen Besucher schon aufgefallen sein,
dass Prometheus in unser Produktportfolio aufgenommen wurde. Als Ergänzung zu den anderen Monitoringanwendungen
(Icinga2, ElasticStack, Graylog) bietet es eine gute Ergänzung für bestimmte Anwendungsszenarien die sonst
noch nicht oder nicht ideal abgedeckt werden konnten.

Die Installation ist zwar bei Prometheus prinzipiell sehr einfach (das statisch gelinkte Binary an den richtigen Ort kopieren und ausführen), aber das ist typischerweise nicht die beliebteste Art und Weise Software zu installieren,
schliesslich müssen dann Updates immer wieder mit dem gleichen Prozedere ausgebracht werden. Das wäre ja an sich nicht weiter schwierig zu automatisieren, aber wofür das Rad neu erfinden, das ist schliesslich die Aufgabe eines Paketmanagers.

Aus diesem Grund sind jetzt in den Netways Repositories Pakete für RHEL- und Debianartige Linux-Distributionen verfügbar. Für Debian(artige) gibt es Prometheus zwar schon paketiert aus den offizielen Quellen, aber aus Gründen der Konsequenz haben wir diese in der gleichen Version wie die RHEL-Pakete nochmals gebaut.

Das Prometheus entspricht eins zu eins dem Build der von Prometheus auch auf Github verfügbar ist.

Wir wünschen fröhliche Installation und wer noch Bugs/Probleme find, ~~darf sie beh~~ möchte uns darauf aufmerksam machen 🙂

Lorenz Kästle

Consultant

Lies mehr von Lorenz und triff unser Team

OSMC 2022 | Recap Day 3

von Lorenz Kästle | Nov 16, 2022 | Events, OSMC

The third and last day of the OSMC 2022 has come to an end. Once again it looks like there is not enough time for all the talks be heard and all the conversations to be had. But waiting until everyone is bored would likely be worse. I visited some of the talks of this day, which I would like to mention. This is, by no means, a testimony to the quality or ingenuity of those or other talks, I haven’t seen, but rather a consequence of personal interest and limited time. Here is what I learned:

In 60 Minuten zum IoT Projekt auf der Basis von ThingsBoard

The biggest german railway company, the Deutsche Bahn, is, as are probably most railway companies, not know for the quick adaption of new trends or their cutting edge technology. This is in many cases, not the worst thing, since this lets the technologies hypes die down until they do something actually useful. Transporting people and cargo across great distances at high speed is not a field for ill-conceived
expermentation.

Nonetheless at some point, newer technological developments carry the possibility of improving the current situation. And the increasing maturity of IoT (“Internet of Things”) things led to an interest in the possibilities in the big world of managing a railway infrastructure. The amount of mobile and non mobile machinery and other assets is stunning and the maintenance or even keeping inventory is a rather complex task.

The increase of availability and ease of use of small sensor and networking devices can help here to create a more accurate picture of the individual systems. An example for this, mentioned in the talk by Holger Koch from DB Systel, is the observation of the amount of dust in the air in switch systems which are using electric relays. Measuring the amount of dust in the air allows a prediction of the need for maintenance to avoid errors. Complementary, unnecessary maintenance cycles can be avoided.

Many maintenance processes are on a fixed schedule and done to a specification which was developed at one point in time and is probably rather conservative. Acquisition of fine granular, new data could allow to analyze and improve those processes.

Holger presented here his experimental setup, which he uses to develop and discover these technologies. A collection of tried and tested components and a platform called ThingsBoard gives a stable basis, which takes care of a lot of the basic components like communications and the integration of and in other platforms. The platform uses some kind of open core model and should cover the use cases of most people in most situations.

Intermission – The Ignite Talks

The Ignite talks are, with their duration of only five minutes, easy to appreciate. The short duration forces the speakers to provide only a broad overview, which might interest even people foreign to the topic or very short little things, which might help for a specific problem. After a delicious lunch we’ve had the pleasure to listen to the Ignites „The O11y toolkit“ given by Julien Pivotto and „Event Driven Ansible“ by Sebastian Gumprich.

The O11y toolkit

The O11y toolkit is a practical toolkit for using Prometheus to make usage easier for people who prefer WebUI and APIs.

Event Driven Ansible

Ansible is push based, but what if one could let it trigger automatically based on some event. There is a way now and here one got a
short introduction into Event Driven Ansible.

Thruk3 – A Fresh Look

Sven Nierlein presented the newest version of the Thruk web interface to a crowd of happy users (or at least interested people). Thruk bundles multiple monitoring systems with the same interface together to present the user a unified interface. The main focus of the new version is mostly a revised look and feel. Some usage patterns and styles currently present in the web were differing increasingly from what Thruk presented before and while users were quite happy with the functionality, the interface was, to use a quote here, “ugly”.

The new interface looks quite modern and reworking it, was a chance taken to make the usage more intuitive and add some little changes to present better, more and|or better information or remove some unnecessary hurdles. For example, the introduction of a “copy to clipboard” button was not a huge change, but removes unnecessary time used for selecting and copying text and also the small error potential of not selecting correctly. So, a lot of “quality of life” fixes were introduced and can now be used, since the update is released and ready
for the rollout.

While this years OSMC has come to an end, I am already looking forward to next year! If you are interested in any of the above mentioned talks or would like to know what other talks were presented: Our conference Archives with all the recordings, slides and pictures will be released soon. Stay tuned!

Lorenz Kästle

Consultant

Lies mehr von Lorenz und triff unser Team

Skalierungseffekte von freier Software

von Lorenz Kästle | Jun 30, 2022 | NETWAYS, Technology

Ein beliebtes Argument für den Einsatz von quelloffener (und idealerweise freier) Software ist, dass sie billiger wäre als eine vergleichbare proprietäre Lösung. Diese Annahme erscheint intuitiv richtig, schließlich ist diese Software oft einfach auffindbar und kostet erstmal überhaupt nichts. Seien es Programme zur Bildbearbeitung (gimp, inkscape), Browser (firefox), anständige Emailprogramme (thunderbird, Instant-Messaging-/Chat-Clients (conversations, matrix clients, gajim), Instant-Messagin-/Chat-Server (ejabberd, matrix server oder ganze Betriebssysteme (debian, ubuntu, Arch Linux) (was eigentlich unvorstellbar ist, wenn man den Aufwand der Entwicklung und Wartung in Betracht zieht).

Trotz allem ist natürlich nicht zu übersehen, dass proprietäre Software ein sehr schweren Standpunkt hat, allen voran natürlich das Betriebssystem auf den meisten Desktop-Computern, das immer noch Windows ist. Außerdem gibts es natürlich noch Hunderte und Tausende von Anwendungen, die proprietär sind, aber weniger bekannt sind, vor allem Fachanwendungen, aber auch die kleinen Programme auf den mobilen Endgeräten. Im Folgenden möchte ich deshalb auf ein paar Gedanken meinerseitz eingehen, warum dies so ist, was ich daran kritisieren möchte und was potentielle Lösungsansätze sind.

Der Grundgedanke für diesen Artikel, ist die Idee, dass freie Software sehr gut skaliert. Damit ist erstmal nicht gemeint, dass diese zwangsläufig sehr gut mit großer Last zurechtkommt, sondern dass bei vielen Projekten eine steigende Nutzerzahl mit einer steigenden Qualität der Software korreliert. Mag ein Projekt von ein oder zwei motivierten Personen gestartet werden, kann sich bei ein paar Tausend regelmässigen Nutzern vielleicht die eine oder andere mit entsprechenden Programmierkrenntnissen finden, die wieder etwas beiträgt. Und selbst, wenn es nur fünf oder zehn Personen sind, so ist dort bereits sehr viel Potential vorhanden, falls die Beteiligten motiviert sind, was sie bei einer freiwilligen und oft ehrenahmtlichen Teilnahme dann typischerweise auch sind.

Das heißt natürlich nicht, dass beliebte Projekte endlos größer und immer besser werden, zahlreiche Beispiele belegen das Gegenteil. Schließlich sind auch FOSS-Projekte immer nur Gruppierungen von Menschen, bei denen es leicht zu Problemen kommen kann, zu Streit oder Zwists oder es ändern sich einfach die Umstände, manchen verlieren über Zeit das Interesse, es stehen die benötigten Ressourcen nicht mehr zur Verfügung oder der ursprüngliche Anwendungsfall für die Software schwindet. Nichtsdestotrotz würde ich behaupten, dass, für gewisse Voraussetzungen, ein freies Modell für Software erkennbar vorteilhaft ist.

Warum sind nun noch soviele proprietäre Komponenten vorhanden? Meine Theorie an dieser Stelle ist, dass es schwierig ist, in dieser Gesellschaftsform, damit Geld zu machen und auch wenn das Ziel der meisten Menschen nicht das reich werden ist, so ist natürlich trotzdem immer die Frage im Raum, von was denn die Miete bezahlt werden soll und natürlich auch die Frage ob man Zeit und Motivation hat, die Probleme anderer Leute (oder auch nur die eigenen) zu lösen.

Bei proprietärer Software ist das Modell noch relativ einfach, man verkauft die Software in diskreten Einheiten als Produkt (klassisch wie bei Brot, Tomaten oder Baggern), Abomodell mit zeitbegrenzten Lizenzen oder in diversen anderen abgestuften Modellen, bei denen Geld für weitere Komponenten oder spezielle Features verlangt wird. Alle diese Einnahmemodelle sind meistens für FOSS nicht anwendbar; zwar spricht nichts dagegen auch hier die Software als Produkt zu verkaufen, aber es fällt schon schwerer, wenn die meisten Leute nach kurzer Suche die kostenlose Version im Internet finden, die sich ja nicht verhindern lässt (und auch nicht soll). Bei verschiedenen großen Projekten ist das teilweise kein Problem, so wird die Entwicklung des Linux-Kernels finanziell von großen Firmen getragen, deren Produkte wiederum darauf basieren. Zwar wären vermutlich weder HP, IBM, Intel, NEC, Google, Oracle, Cisco, Huawei oder gar Microsoft auf die Idee gekommen, etwas zu starten, was der Konkurrenz oder gar einfach der Menschheit an sich etwas hilft und was ohne größere Hindernisse von jeder (mit einem Computer) benutzt werden kann, aber konfrontiert mit der Option einen toten Gaul zu starten (und damit haben die Firmen durchaus Erfahrung, Microsoft Google) oder mit knirschenden Zähnen trotzdem noch Geld zu machen, war dann die Wahl einfach.

Für FOSS-Software, die auch in Unternehmen (offensichtlich) wichtig ist, gibt es durchaus die Möglichkeit Consulting oder Support hust anzubieten, aber dies ist für Software für Privatpersonen schwierig, aber auch für die Komponenten die die Infrastruktur weiter hinten bereitstellen, etwa für die dann benutzten Bibliotheken und Werkzeuge. Während man für den Fall der Privatsoftware hauptsächlich auf Enthusiasten zurückgreifen kann oder muss, gibt es bei wichtigen Bibliotheken fast nur die Hoffnung, dass Personen in Firmen dafür abgestellt werden oder Institutionen wie die Apache Software Foundation hier unterstützen. Dies ist zwar nicht direkt das Szenario der Tragik der Allmende, aber eine gewisse Verwandschaft lässt sich schwer leugnen.

Warum sollte das nun eigentlich jemanden interessieren oder etwas vulgärer formuliert: Was geht mich das an? Durch diese Mechanismen, die sicherlich jemand schöner und präziser formuliert hat, werden riesige Mengen an Ressourcen verschwendet. Wobei Ressourcen hier hauptsächlich menschliche Zeit, Nerven und Privatspäre sind. Zusätzlich wird hierbei soviel Potential für eine tatsächlich bessere Zukunft verbrannt, dass bei einer Spekulation über die verlorenen Möglichkeiten die Tränen kommen. Dieser Punkt bedarf wohl ein wenig der Erläuterung, deshalb möchte ich mit einem Beispiel fortfahren:

Beispiel Videokonferenzen

Gerade im Zug der aktuellen Pandemie haben Videokonferenzlösungen riesigen Zulauf erhalten, mittlerweile dürfte fast jede mal irgendein Zoom, Webex, Teams oder etwas in der Form kennen gelernt haben, typischerweise mehrere davon und natürlich mit allen tollen Problemen, inklusive katastrophalem Datenschutz, Sicherheitslücken und vielem mehr. Das Problem daran ist, dass alle diese Systemen nur okayish funktionieren, alle nicht miteinander reden und einem komplett sinnbefreite Hürden in den Weg legen. Ich möchte hier deshalb ein utopisches Gegenszenario formulieren:

Ich habe einen Client (ein Programm) auf dem Computer für Videokonferenzen, ich bekomme einen Link für eine Videokonferenz, der auf irgendeinen Server zeigt, dann fragt es mich nach einem Passwort, einer Nutzername/Passwort-Kombination oder sonst einer Authentifizierung, falls diese denn überhaupt nötig sein sollte. Wenn ich eine Videokonferenz eröffnen wollte, würde ich dort einen Knopf finden und einen Link erhalten, den ich über die üblichen Kanäle (Email, Messenger) dann einer mehreren Personen senden kann und fertig. Das Programm kann mein Video- und Audiosignal aufnehmen, konvertieren und senden, sowie die der anderen Teilnehmer empfangen und darstellen. Dazu kommt ein simpler Chat-Mechanismus und vielleicht Spielereien wie Notizen oder so. Damit wäre dann der allergrößte Teil all dieser anderen System abgedeckt. Im Hintergrund spricht es SIP (ein Protokoll ursprünglich von 1996) und vielleicht noch XMPP für den Chat oder so. Alles kein Hexenwerk, da die Protokolle und Bibliotheken teilweise schon seit Jahrzehnten vorhanden sind und die ganzen, oben erwähnten, Implementationen vermutlich genau diese Techniken ohnehin verwenden(!). Das Programm verfügt über vernünftige Hardware-Beschleunigung, damit ich meinen Computer und den Laubbläser vor dem Fenster noch unterscheiden kann und ist idealerweise kein verkleideter Browser, der nach dem Prinzip “Leerer Speicher ist verchwendeter Speicher” arbeitet.

Nun gut, mag sich die geneigte Leserin denken, die bis hier durchgehalten hat, denken, das klingt doch ganz gut, warum haben wir das denn nicht und meine Antwort wäre lapidar: Es lässt sich mit sinnvollen Dingen einfach schwer Geld machen. Mit den Ressourcen von Microsoft, Google, Cisco und all den anderen Anbietern zusammen wäre so ein Projekt durchaus leicht machbar, man könnte ein sinnvolles Prozedere ausarbeiten für die Protokollverhandlungen, für Erweiterungen, für Best Practices, ein paar hochbezahlte und vielleicht gute Programmierer dafür abstellen und wir hätten alle mehr davon. Jetzt ist aber das Problem, dass jemand die Frage stellen würde, was denn Firma A davon hat, wenn Firma B das auch einfach mitbenutzen kann oder (Schnappatmung) JEDER einfach ihre eigenes System aufsetzen könnte! Keine Kontrolle, vielleicht sogar keine Einnahmung! Unmöglich! So etwas ist heute kaum vorstellbar, was eigentlich obskur ist, schließlich haben sich vor Jahren (oder Jahrzehnten) genau solche Ansätze verbreitet, wie etwa Email. Ich kann mir tatsächlich nicht vorstellen, das so etwas wie Email noch einmal passieren könnte, mal ganz abgesehen davon, dass dieses Ökosystem unter der einseitigen Beeinflussung der großen Spieler auch schon massiv leidet.

Meine Verallgemeinerung dieser Situation ist folgende: Durch das Etablieren großer Monopole in dem Bereich wird die Entwicklung von tatsächlich nützlichen Dingen erheblich gebremst. Die simplistische Theorie des freien Marktes, der das beste Produkt befördert, funktioniert nur für den sehr eingeschränkten Rahmen etwa gleich großer (vieler) Spieler und Kunden mit sehr guten Informationen. Letzteres ist in Zeiten von endemischen absurden Marketingkampagnen und komplexen Thematiken ein Traum und ersteres bei großen Konzernen, die sich an zwei Händen abzählen lassen, auch nicht mehr gegeben. Jedes vielversprechende Startup (also ein Startup das viel Geld verspricht) wird schließlich bei dem geringsten Anzeichen von Erfolg von einem der Großen aufgekauft. Üblicherweise geht dabei dann alles Sinnvolle kaputt und das ganze Produkt wird dann abserviert, aber das ist auch nicht so tragisch, schließlich hat man sich relativ billig einen potentiellen Konkurrenten vom Hals geschafft.

Beispiel ÖPNV

Nehmen wir ein weiteres Beispiel zur Hand: Apps für den öffentlichen Personennah- und -fernverkehr. Nachdem ich sowieso den Miniaturcomputer in der Tasche habe, wäre die Anzeige des Fahrplans, der Ausfälle und Verspätungen und der Kauf der jeweiligen Tickets schon ein ziemliches Feature. Soweit, so gut, das Problem beginnt aber schon beim Umstieg von Nah- auf Fernverkehr, ersteres kann ich hier (im Raum Nürnberg) mit der VGN-App erledigen, für zweiteres bräuchte ich dann den DB Navigator (das hier) und dann in einer Zielstadt potentiell noch eine Dritte. Nun gut, dass sind verschiedene Unternehmen, erscheint zunächst mal logisch. Ich tendiere aber ein bisschen zum Minimalismus und suche deshalb nach der Lösung, die mit kleinstem Aufwand meine Anforderungen erfüllt. Meine Anforderung ist, von A nach B zu kommen, möglichst wenig Zeit und Geld dafür zu verbrauchen plus etwas abstraktere Kriterien wie “Ich möchte wissen von welchem Gleis wann welches Zug in welchem Abteil”. Alles Andere ist Unfug, wie etwa drei Apps dafür zu haben. Nachdem ALLE Personentransportgeschichten fast das gleiche tun, gibt es keinen Grund warum jeder jetzt das Rad nochmal neu erfindet!

Vermutlich gibt es ein paar Hundert Unternehmen weltweit, die fast das exakt gleiche bauen, fast völlig ohne Not. Natürlich sind alle Streckennetze ein wenig unterschiedlich, die Preisstrukturen auch und natürlich sind verschiedene Sprachen und kulture Gepflogenheit zu beachten, aber gibt es wirklich einen guten Grund Tausende halbgare Apps zu haben anstatt drei bis fünf (Monokulturen sind auch in der Software eine schlechte Idee, deshalb mehr eine) Gute? Es gibt Ansätze das Problem zu negieren (wie etwa die Öffi-App), aber das ist wieder mal ein kleines Team (eine Person?) die mühevoller Arbeit die ganzen APIs zusammenstückelt und natürlich ist dann Bezahlen auch keine Option darin.

Warum setzen sich denn die ÖPV-Unternehmen nicht zusammen und bauen das zu einer vollständigen Lösung aus? Mein Softwarewunsche hier wäre eine App mit der ich meine Ziele eingeben kann, die Optionen angezeigt bekomme, sinnvoll bezahlen kann und die mir dann sagt wann ich wo sein muss. Alles andere ist unnötig.

Anmerkung: Ich habe keine der oben erwänten Apps installiert, da alle keine freie Software sind, mit Trackern vollgestopft und nicht in Fdroid verfügbar. Pls fix.

Beispiel CAD-Software

Dies ist nun schon ein Nischenthema, aber durch, zumindest kleine, Einblicke in diese Sparte, bekommt man leicht das Gefühl eines großen Problems. Eine einstellige Anzahl von großen Spielern arbeitet an einer Reihe von mittelschlechten Softwareprodukten die natürlich alle nicht sinnvoll miteinander kompatibel sind. Diese sind dann natürlich extrem kostspielig (und außerdem schwierig zu benutzen). Ganz abgesehen davon, dass eine Firma mit der Wahl der Software sich in dieser Wahl “einschliesst”, sind diese Produkte für Hobbyisten, Startups oder kleine Unternehmen kaum erschwinglich. Ich kann nur darüber spekulieren wieviel Potential an interessanten Ingenieurskreationen dadurch verloren geht. Was wäre wenn ein ambitionierter Hobbyist ein Konzept für eine sinnvolle oder zumindest schöne Konstruktion einfach konstruieren und idealerweise noch simulieren könnte ohne sich sehr tief in die (leider noch qualitativ nicht so guten) freien Lösungen einzuarbeiten oder sehr viel Geld für eine teure Lizenz opfern. Das im Zweifelsfall die Formate auch nicht sinnvoll kompatibel sind, ist dann die Austauschbarkeit und Weitergabe eingeschränkt, was wiederum unnötige Mehrarbeit erzeugt.

Ausblick

Ich habe die Theorie das die Softwarewelt in der aktuellen Situation furchtbar ineffizient, rückständig, unsicher und unnötig schädlich für die Benutzer ist und vor allem, dass dies kein notwendiger Zustand ist, sondern eine Folge eines Denkens und Wirtschaftens, dass nicht den größten Nutzen vieler sondern nur Einzelner anstrebt (vielleicht nicht mal das). Diese Probleme begleiten uns täglich und werden auch absehbar nicht verschwinden, zumal sie sich sehr vertraut anfühlen, wenn man die Ursachen und die mangelnde Reaktion auf die Klimakatastrophe als Vergleich heranzieht. Zu ihrer Überwindung bräuchte es große organisatorische und vor allem willentliche Anstrengunen und ich hoffe, dass ich einen kleinen Beitrag dazu leisten kann, dass diese auch mal angegangen werden. Deshalb gibt es noch ein paar konkretere Vorschläge:

Abschaffung und Einschränkungen von Monopolen
Einzelne Unternehmen dürfen keine signifikanten Anteile an irgendeiner Sparte haben und müssen Schnittstellen für Komponenten von anderen Anbietern bieten. Die Benutzung dieser Schnittstellen darf nicht rechtlich eingeschränkt und künstlich blockiert werden

Öffentliche Gelder, öffentlicher Code
Ist das Motto der Kampagne der FSFE. Öffentliche Gelder dürfen nicht oder nur in sehr eingeschränkten Fällen zur Erstellung von nicht-freier Software benutzt werden

Keine proprietären Softwarekomponenten beschaffen oder verwenden, wenn dies in freier Software umgesetzt werden könnte. Es lohnt sich auf lange Sicht.

Unterstützt freie Software
Lasst den Entwicklern von eurer liebsten freien Software mal ein Dankeschön und etwas Geld da, das kann es einem auch mal wert sein

Zu guter Letzt möchte ich der geduldigen Leserin danken, die bis hierhin durchgehalten hat und möchte dazu einladen ein wenig Feedback dazulassen, falls es hier Zustimmung oder (fast noch wertvoller) Korrekturen und Kritig gibt.

Anschließend gibt es noch eine Sektion mit unbeliebten und unnötig geäußerten Meinungen zur Unterhaltung.

Unbeliebte Meinungen

Diese Sektion drückt meine persönliche Meinung und keine Position der Firma aus, welche dafür doch bitte keine Shitstorm bekommen sollte und bla bla bla. Wer sich angegriffen fühlt, darf mir dass in gewählter Wortwahl mitteilen oder für sich beleidigt sein.

Blockchains und Cryptowährungen sind Betrugsmaschen. Sie sind zu (fast) nichts nütze und sollten einfach nicht benutzt werden (Ich scheue hier das Wort “verboten”, aber unsympathisch ist es nicht). Jede Beteilung daran, macht einem zu einem Abzocker oder einem Opfer davon. Cryptowährungen sind ein System um Hoffnung auszunutzen und es ist nicht nur ein Nullsummenspiel, es ist ein Negativsummenspiel. Es macht die Welt insgesamt schlechter. Es ist falsch mitzumachen. Es wird da absehbar nichts Sinnvolles entstehen. Links: The Case against Crypto The Simple English Argument Against Crypto The Complete Argument Against Crypto The Philosophical Argument Against Crypto
Das gilt auch für NFTs was noch eine viel absurdere Idee. Das ist keine Verbesserung des Kunstmarktes, es ist ein Paradies für (Ab)Zocker
Die “sozialen Netzwerke” oder “sozialen Medien” sind größtenteils keine, sie dienen als Werbeplattform und damit zur Manipulation der Benutzer. In Summe schaden sie meiner Ansicht nach der geistigen Gesundheit schon der zugrunde liegenden Mechanismen wegen

Es gibt eine neue Auflage des Icinga-Buches!
Sinnvolle stabile und bewährte Chat-Lösung gesucht? Wie wäre es mit XMPP? Zum selber hosten oder einfach. DSGVO-kompatibel einfach machbar, interoperabel, stabil, E2E-Verschlüsselung möglich
Die Free Software Foundation Europe wirbt im digitalen Raum für Bürgerrechte, freie Software und allgemein sinnvolle Entwicklungen. Kann man mal anschauen

Lorenz Kästle

Consultant

Lies mehr von Lorenz und triff unser Team

Administrators Toolbox: SSH

von Lorenz Kästle | Dez 23, 2021 | NETWAYS, Technology

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