Seite wählen

NETWAYS Blog

Die drei großen Fragezeichen

Eine kleine Detektivgeschichte – oder: wer Centos beerbt. Als RedHat entschied, dass Centos 8 nach nur einem Jahr sein EOL (End of Life) erreicht hat, war das relativ umstritten. Wie bei großen reichen Familien versammelten sich alle, um das Erbe zu bekommen. Wie in allen Detektivgeschichten geht es um ein Warum, Wie und Wo. Ähnlich wie in Cluedo, nur dass hier als Protagonist nicht Colonel Mustard mit der Rohrzange jemanden im Salon ermordet. Diese Frage will ich heute an der Stelle hier aber gar nicht ausgraben. Der Täter ist in diesem Fall das Familienoberhaupt mit Namen RedHat Enterprise, die Tatwaffe ist Centos Stream und der Tatort, nunja, virtuell der Cyberspace.

Centos Stream ist halt ein Unstable Branch, der für viele Kunden nicht mehr die Stabilität garantiert, welche Sie vorher hatten. Redhat versucht hier, das lizenzpflichtige Produkt (den erstgeborenen Sohn) zu promoten – was nicht per se schlecht ist. RHEL 8.x ist weiterhin ein funktionierendes OS mit Support. Hingegen das Adoptivkind (Centos8) wird von der Burgzinne geworfen. In der Erbschaftsreihenfolge rückt der ungeliebte Neffe auf (Centos Stream). Allerdings wie sieht es mit den Alternativen aus? Ich habe mir heute 3 herausgepickt, welche ich in einem kurzen Abriss mal versuche mit einer Icinga Installation zu bestücken.

Als ersten im Ring haben wir Cloudlinux, welches sich als RHEL-kompatibel vermarktet und auch direkt die Clouduser ansprechen will. Hier eins vorweg: es ist kostenpflichtig. Nach Einlegen der ISO werden wir von einem Anaconda installer begrüsst, welcher auch durch eine Kickstart beantwortet werden kann. So weit, so gut… Der Abflauf der folgenden Installation ist wie immer unspektakulär. Kernel Version ist beim ersten Start 4.18 ohne Updates. Das initial Update wirft einen nach aktuellen Stand erstmal 141 Updates entgegen. Powertools sind schon von Haus aus dabei. Ein Blick in die SSHD Konfig zeigt, dass initial PasswordAuthentication auf ‚Yes‘ steht. Das mögen nicht alle 🙁 – vor allem der Butler (Root) am wenigsten.
Nun gut. Wir gehen über in die Icinga installation (Detektei Simon & Simon), welche ich hier als Benchmark verwende; wie gut, es funktioniert, Stand Juni 2021.

Es erfolgt die Subscription, welche die Cloudlinux Repos freischaltet, das ist auch relativ unspannend. (Beschatten & stundenlang im Auto warten und Screenshots machen). Es kommt an der folgenden Stelle der Punkt, auf den es ankommt. (Der also, an dem unsere Informationsfitzel langsam den Plan offenlegen.)

#> dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
#> rpm --import https://packages.icinga.com/icinga.key
#> dnf install https://packages.icinga.com/epel/icinga-rpm-release-8-latest.noarch.rpm

Die Installation erfolgt relativ schmerzlos und wir haben ein laufendes Icinga auf einem Cloudlinux.


===========================================================
[root@localhost ~]# systemctl status icinga2
● icinga2.service - Icinga host/service/network monitoring system
Loaded: loaded (/usr/lib/systemd/system/icinga2.service; disabled; vendor preset: disabled)
Active: active (running) since Tue 2021-06-15 08:11:21 EDT; 9min ago
Main PID: 6298 (icinga2)
Tasks: 13 (limit: 5021) Memory: 14.4M
CGroup: /system.slice/icinga2.service ├─6298 /usr/lib64/icinga2/sbin/icinga2 --no-stack-rlimit daemon --close-stdio -e /var/log/icinga2/error.log ├─6313 /usr/lib64/icinga2/sbin/icinga2 --no-stack-rlimit daemon --close-stdio -e /var/log/icinga2/error.log └─6316 /usr/lib64/icinga2/sbin/icinga2 --no-stack-rlimit daemon --close-stdio -e /var/log/icinga2/error.log Jun 15 08:11:21 localhost.localdomain icinga2[6298]: [2021-06-15 08:11:21 -0400] information/ConfigItem: Instantiated 1 Host. Jun 15 08:11:21 localhost.localdomain icinga2[6298]: [2021-06-15 08:11:21 -0400] information/ConfigItem: Instantiated 2 NotificationCommands. Jun 15 08:11:21 localhost.localdomain icinga2[6298]: [2021-06-15 08:11:21 -0400] information/ConfigItem: Instantiated 12 Notifications. Jun 15 08:11:21 localhost.localdomain icinga2[6298]: [2021-06-15 08:11:21 -0400] information/ConfigItem: Instantiated 2 HostGroups. Jun 15 08:11:21 localhost.localdomain icinga2[6298]: [2021-06-15 08:11:21 -0400] information/ConfigItem: Instantiated 1 Endpoint. Jun 15 08:11:21 localhost.localdomain icinga2[6298]: [2021-06-15 08:11:21 -0400] information/ConfigItem: Instantiated 1 FileLogger. Jun 15 08:11:21 localhost.localdomain icinga2[6298]: [2021-06-15 08:11:21 -0400] information/ConfigItem: Instantiated 235 CheckCommands. Jun 15 08:11:21 localhost.localdomain icinga2[6298]: [2021-06-15 08:11:21 -0400] information/ScriptGlobal: Dumping variables to file '/var/cache/icinga2/icinga2.vars' Jun 15 08:11:21 localhost.localdomain icinga2[6298]: [2021-06-15 08:11:21 -0400] information/cli: Closing console log. Jun 15 08:11:21 localhost.localdomain systemd[1]: Started Icinga host/service/network monitoring system. ===========================================================

Damit haben wir den ersten der drei Erben getestet. In den kommenden Posts werde ich mit den anderen versuchen, Icinga zu installieren.

David Okon
David Okon
Senior Systems Engineer

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu glücklichen Menschen zu machen.

Von Fackeln, elektrischen Schafen und Datenpunkten

Hallo und Willkommen im Jahr 2021! sheep

Damit sind wir offiziell 2 Jahre nach dem originalen Zeitablauf von Blade Runner welcher 2019 spielt.
Hmm, nirgends sind Nexus 6 Modelle die Rumlaufen und von elektrischen Schafen träumen.
(Auch keine Flugautos) *seufz*. Egal !!

Kommen wir zu dem eigentlichen Thema diese Woche.
Ich würde euch gern im neuen Jahr kurz erklären wie ihr mit einfachen Bordmitteln & wenig Aufwand aus den den meisten APIs Prometheus Daten exportiert ohne Zusatzsoftware zu installieren.

Explainer!! Was macht man mit den Fackeln https://prometheus.io/ ist eine Software welche mit ihrer eigenen Time Series Database auch Graphen Zeichnen kann und einen ziemlichen Erfolg hat, https://prometheus.io/docs/prometheus/latest/storage/ wenn man allerdings aus seiner Allerweltsapplikation Daten nach Prometheus exportieren will ist man leicht Aufgeschmissen. Viele Anbieter verkaufen teuer Plugins welche dies für Software tun oder es gibt halt keine Schnittstelle.

Ich versuche in meinem Beispiel aufzuzeigen wie man sich selbst einen Prometheus Output baut und ihn mit dem Prometheus node_exporter zu der Haupt Prometheus Instanz bringt.

Was brauchen wir an Software dafür machen wir einen kleinen Einkaufszettel 🙂

Die Zutaten:
1x Software welche eine API zur verfügung stellt – als Beispiel nehmen wir Icinga 2 kann aber eine Software eurer Wahl sein
1x Prometheus node_exporter (muss man leider zusätzlich installieren)
1x crontab – bringt hoffentlich eure Linux Distro von Haus aus mit
1x curl – hoffentlich auch schon von „Werk“ ab mit an Bord
1x awk – same here auch hoffentlich schon mit an Bord
1x jq – Okay .. ich geb zu das muss man nachinstallieren (ich versuche mich gerade unter dem Schreibtisch zu verstecken)
https://stedolan.github.io/jq/download/

Nun wo wir die Zutaten kennen kommen wir zu dem eigentlichen Rezept.
*/1 * * * * curl -k -s -u 'user:password' https://localhost:5665/v1/status | jq '.results[1].status.active_host_checks_1min' | awk {'print "node_icinga2_active_checks1m""{" "active=" "\"" "/checks1m" "\"" "}" " "$1'} > /var/lib/node_exporter/textfile_collector/active_checks.prom.$$ && mv /var/lib/node_exporter/textfile_collector/active_checks.prom.$$ /var/lib/node_exporter/textfile_collector/active_checks.prom

Was habe Ich da in der Zeile über dieser eigentlich verbrochen?
Dröseln wir das doch auf, Schritt für Schritt.

Step 1:
*/1 * * * * curl -k -s -u 'user:password' https://localhost:5665/v1/status
Ich gehe im Crontab jede Minute her und greife mir aus der lokalen icinga 2 Instanz per Api den Status per JSON.

Step 2:
| jq '.results[1].status.active_host_checks_1min'
Dann gebe ich den JSON Output an jq weiter. Dies lass ich auf einen Wert aus dem JSON parsen. Idealerweise ein Zahlenwert welchen einen schönen Datenpunkt abgibt.

Step 3:
| awk {'print "node_icinga2_active_checks1m""{" "active=" "\"" "/checks1m" "\"" "}" " "$1'}
Dies reicht leider für Prometheus nicht aus wir müssen das etwas aufbereiten das Prometheus das auch als Datenquelle akzeptiert. Der Inhalt eines .prom Files muss in folgenderweise Formatiert sein. Hier kommt awk für die Aufbereitung ins Spiel.

Was nach dem awk Befehl rauskommt sieht formatiert ungefähr so aus node_icinga2_active_checks1m{active="/checks1m"} 607.

Ich hab mal aus Beschreibungsgründen den vorderen Teil node_icinga2_active_checks1m genannt. Könnte aber auch node_raspberrypi15_active_tempsensor30s sein. Danach folgt {active="/checks1m"} 607 welches nochmal auf den Key=Value + Wert Part hinweist. Ich bin aber ehrlich hier schwimme ich selbst etwas. Wenn mir jemand hier Aufschlüsseln kann was hier „Notwendig“ ist wäre ich sehr Dankbar.

Step 4:
> /var/lib/node_exporter/textfile_collector/active_checks.prom.$$ && mv /var/lib/node_exporter/textfile_collector/active_checks.prom.$$ /var/lib/node_exporter/textfile_collector/active_checks.prom
Danach wird der von awk aufbereitete String in eine active_checks.prom Datei geschrieben.

Damit haben wir ein valides Prometheus File welches wir dem node_exporter (Prometheus) übergeben können.
Was hat es nun mit /var/lib/node_exporter/textfile_collector/active_checks.prom auf sich .. Der oben in der Zutatenliste erwähnte Prometheus node_exporter ist im Grunde die Datenschleuder welche konfiguriert, in einem selbst definierten Intervall (scrape_intervall) die active_checks.prom Datei in Richtung Prometheus Hauptinstanz wirft. Die dann wiederum die Werte in ihre Time Series Database einträgt und den Graphen zeichnet.

Da der Prometheus node_exporter selbst unterschiedliche Möglichkeiten hat Daten entgegenzunehmen, wir aber in "textform" Daten ihm liefern legen wir die .prom Datei unter dem Pfad /var/lib/node_exporter/textfile_collector/ ab.

Damit der node_exporter weiß wann er in welchem Intervall die von uns Aufbereiteten Daten an das Haupt Prometheus übergeben soll.
Muss Konfig ihm sagen wann (kurzer Abriss der /etc/prometheus/prometheus.yml)
...
## Add Node Exporter
- job_name: 'icinga2'
   scrape_interval: 60s
   static_configs:
      - targets: ['x.x.x.x:9100'] <= Adresse der Haupt Prometheus Instanz welche in dem Screenshot unten uns dann einen Graphen zeichnet.

Im Prometheus (Hauptinstanz) haben wir dann so einen Graphen wie im Screenshot unten, dies kann man auch noch schöner in Grafana zeichnen lassen sprich wenn man in seiner Software ein Grafana Fenster eingebunden hat kann man diese Graphen da hinein verlinken.

Ich hoffe ich konnte euch etwas den Einstieg in das neue Jahr verschönern mit meinem Versuch euch einen Prometheus Datenexport nahe zubringen und ich freue mich über euer Feedback.
Servus bis zum nächsten Mal !

David

David Okon
David Okon
Senior Systems Engineer

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu glücklichen Menschen zu machen.

GTD ohne Equipment

 

Hallo Miteinand !

Ich wollte eigentlich aus dem Homeoffice nicht einen üblichen Home Office Blogpost veröffentlichen aber ich wollte euch kurz daran teilhaben lassen, wie man mit minimalsten Gegebenheiten doch noch sein Arbeitspensum ggf. durch die Tür bekommt.

Ich hatte das grosse Pech das mein privates Macbook Pro aus dem Jahr 2016 den Weg allen irdischen gegangen ist und sich mit einer kombi aus exhausted Battery und Display/Grafikkarten Fehler + Wlan Modul Tod verabschiedet hat. Die Batterie ist ersetzbar, aber die anderen Sachen wären aktuell nicht mehr rechtfertigbar. So kurz vor dem Release neuer Hardware.

Ich musste also 2 Tage bis mein Firmenersatzlaptop kam etwas Zeit überbrücken. Das funkionierte sogar besser als geplant und an einigen Stellen schlechter.

Als Ersatz hatte ich nicht viel zur Hand. Ich hatte mein privat genutztes IPad Pro (IOs 13.x) eine Tastatur + Maus der Marke Logitech. IOs 13 wegen dem Maussupport welcher brauchbar ist als OS auf dem IPad. Alternativ läge hier auch noch ein Kindle Fire 7 rum welcher auch seinen Dienst getan hätte.

Keyboard

Keyboard


Das Keyboard ist das K380 in weiss + eine M171 Funkmaus. Man kann das ganze wenn man einen aktuellen Screen hat gemütlich per USB-C verbinden damit wenigstens von der Bildschirmgrösse etwas mehr sichtbar ist. Das ist aber schon purer Luxus.

Das Tablet kann man aber auch durch ein beliebiges Android Tablet der Marke X austauschen. Ich versuche hier Software bzw. Hardware Agnostisch zu sein. Für Office schreibsachen bin ich auf Office 365 Web zurückgefallen. Was Datenschutztechnisch für eine menge Leute nicht in Frage kommt. Es gibt aber auch die dedizierten Apps für IOs und Android somit muss nichts in die Cloud geladen werden.

Kommen wir zum Codehacking Part. Nun da man schlecht direkt auf dem IPad eine virtuelle Maschine mit Vagrant hochziehen kann musste ich wohl oder übel auf gehostete Services zurückgreifen. Zum einen unser einges (https://cloud.netways.de) welches es mir ermöglichte per Openstack Teststellungen zu bauen und testen. Als auch Azure (Terraform) und Bernds Schmuddelkind Nummer eins (AWS). Keines machte grossartig Zicken per Safari. Dies sollte auch per Android (Chrome) keine Probleme darstellen. Es braucht aber einen Sinnvollen SSH Client für das jeweilige Tablett damit man sich in der gehosteten VM zumindest Anmelden kann Ich benutze Termius (https://www.termius.com/) auf IOs. Es hat auch bezahl Features welche ich eigentlich aber gar nicht brauche (SFTP). Die funktionale Alternative auf Android ist Juice (https://juicessh.com/).

Termius Screenshot


Oh natürlich kommt nun die Frage auf wie man nun denn Code editiert. Klar ich muss mir von der VM die Sachen nochmal ziehen oder auf den virtuellen Desktop was aber per dedizierter VNC Viewer App (IOs/Android) (https://www.realvnc.com/en/connect/download/viewer/ios/) oder dem Microsoft Remote Desktop gut gelingt. (https://apps.apple.com/de/app/microsoft-remote-desktop/id714464092?l=en) 
Auch die anderen Remote Desktop Tools sind vertreten wie der bei uns benutzte Anydesk Client (https://anydesk.com/en/downloads/ios) und das nicht Todzubekommende Webex ist am Start (https://apps.apple.com/de/app/cisco-webex-meetings/id298844386?l=en). Beide Tools sind natürlich auch in einer Android Version erhältlich.

Aber zurück zu dem Editor. Ich muss gestehen das ist der Part welcher mich am meisten begrenzt hat. Mit Begrenzt meine ich nicht das es keine Auzwahl gibt. Ich bin eher ein barebones Nutzer der nicht viele Ansprüche hat. Ich brauch keine Codeergänzung, keine Autokorrektur usw. Ich gestehe ich bin mit Vim auf den VMs vollkommen zufrieden gewesen. Auch mit git welches in den VMs installiert war.

Ich würde aber zu cloud9 tendieren (Bernd ist sicher begeistert 🙂 ) (https://aws.amazon.com/cloud9/). Die alten Hasen von Panic Software haben noch Coda 2 zur Hand. (https://www.panic.com/coda/). Wobei mir deren Preisgestaltung bitter aufstösst.

Last But not least gibt es sicher auch noch für Selbsthoster Eclipse CHE. (https://www.eclipse.org/che/). Zu der kann ich leider nichts sagen, keinerlei Erfahrung meinerseits im Handling.
Gitlab hat auch eine Web IDE welche aber einen seltsamen Workflow hat. Man muss die einzelnen Files nach änderung mergen :S.

Die üblichen Kollaborationstools wie Slack, Rocketchat, Microsoft Teams gibt es auch bzw. Funktionieren auch auf mobile Geräten relativ Problemlos. Wenn alles versagt muss man halt sich per Handy in die Online Telko einwählen was manchmal doch erstaunliche Sprachqualitaet zu Tage fördert. (NO More VBR in VOIP).

Fazit:
So bin ich bis mein Arbeitslaptop da war per UPS gut durch die Zeit gekommen und konnte meinen Aufgaben gerecht werden.
Ich würde einen nativen USB-C Monitor favorisieren und ggf. Im Nachblick mir einen Browser wünschen welcher an einem externen Monitor die seitlichen schwarzen 4:3 Balken verschwinden lässt. (IOs Problem)(Lost Screen Estate) und eine IDE welche entweder als App mit frei einhängbaren Online Speicher funktioniert oder eine simpel funktionierende Web IDE.

Ich freue mich wenn ihr mir Sagen würdet  wie ihr so etwas überbrückt.

Gruss

David

Nachtrag:
Just als ich den Blogpost fertig hatte fand ich die folgende App.
Shiftscreen ) scheint zumindest teilweise das Black Bars Problem (IOs) zu beheben.

David Okon
David Okon
Senior Systems Engineer

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu glücklichen Menschen zu machen.

Die Out of the Box Experience

Hallo!

Ich würde gern ein aktuelles Thema aufgreifen, das in letzter Zeit viele Leute beschäftigt. Da aus aktuellem Anlass viele Leute ins Homeoffice gehen mussten und nun von dort ihre Arbeit verrichten, haben viele neue Monitore, Rechner, Mikros und Software erhalten, um dies zu bewältigen.

Nun gibt es aber die schon oben beschriebene Erfahrung, die aus rein subjektiver Sicht entscheidet, ob man mit dem neuen Produkt zufrieden ist oder es gleich wieder einpacken und zurückschicken will.

Das Feld ‚Videokonferenzen‘ will ich hier gar nicht betreten. Da hat jeder andere Präferenzen.

Mir geht es in dem Blogpost eher um die „Experience“, ein tolles Marketing-Buzzword, bei dem sich am liebsten jeder unter der Couch verstecken möchte. Die Erfahrung, die man mit dem jeweiligen Produkt direkt nach dem Auspacken macht, ist sehr variabel.

Nehmen wir mal als Beispiel einen neuen Firmenlaptop. Wir haben ihn aus der Verpackung gepult und drücken auf den Powerknopf und unsere neue Kiste mit SSD und mehr Speicher & CPU Kraft aller Großrechner in den 80zigern dümpelt 5 Minuten in einem Regenbogenfarbenen Waiting Screen von Windows umher in dem uns mitgeteilt wird das wir uns freuen dürfen das ’now‘ etwas für uns passiert.

NOT!!!! Jemanden warten zu lassen ist keine ‚Gute‘ Out of the Box Erfahrung. Auch 4-5 Sicherheitsfragen welche sowas lustiges wissen wollen wie „Was war ihr erstes Haustier“ … sind eher Anti Security .. Rein statistisch hat man hier schon in den USA mit sowas wie ‚Spot‘ einen Treffer um in einen Benutzeraccount rein zu kommen.

Idealerweise sollte man nicht warten müssen . NEVER make your Customer wait.

Das wussten selbst Betriebssysteme aus der prähistorischen Ära. Einschalten, Loslegen. C64 => Einschalten und READY.
Selbst die Amiga Workbench war nach dem Starten direkt verfügbar und auch Atari TOS auf dem ST. Nun sind wir im Jahr 2020 AD.

Aus Sicht eines Endbenutzers ist das keine gute Erfahrung (Warten, abgreifen personenbezogener Daten für Marketing-Zwecke, Sicherheitsexploit-Fragen) und zum goldenen Abschluss, nachdem man die ganze Prozedur hinter sich hat, kommt noch ein haufen Autoupdates, die noch installiert werden müssen, bevor man effektiv anfangen kann zu arbeiten.

Selbst bei Konsolen ist die Out of the Box Erfahrung … inzwischen hundsmiserabel.
Früher: SNES Spiel in die Konsole stecken und läuft. Heute: Mindestens 2 Anmeldungen. Einmal Hersteller spezifisch XBox Account/STEAM Account/PSX Account und dann gegebenenfalls nochmal die des Spieleherstellers und dessen Plattform inkl. Werbung.

Das künstliche Gold der Marketing/Wertschöpfungskette von Daten, die nur um deren Selbstwillen für User Tracking generiert werden, ist bis in das einfachste Produkt vorgedrungen. Selbst meine Bose Wireless Kopfhörer wollen meinen Alex Account Zugriff um mir ‚Mehr Info‘ liefern zu können.

Da ich nun sehr abgedriftet bin von der Thematik: Die „Auspack und sofort Loslegen Erfahrung“ ist sehr „Simplismus“ geprägt, man findet die „Out of the Box“ Erfahrung am idealsten, wenn man direkt loslegen kann.
Kein wenn und kein aber.
Zu einem späteren Zeitpunkt können die Settings des Produktes verfeinert werden. Also ggf. einen Account anlegen, höhere Security Settings setzen und andere Einstellungen vornehmen.

Aber die Defaults sollten IMMER zu einem produktiven Ergebnis führen.

Software ist auch ein Werkzeug wie ein Schraubenzieher. Der will auch nicht, dass ich bei ‚Binford‘ einen Account anlege. bevor ich die erste Schraube in das Holzbrett drehe. Software & Betriebssysteme sollten allgemein wieder auf Funktionalität ausgelegt werden anstelle von Subscription ‚featureitis‘ …

Das baut nur unnötige Hürden und Fehlerquellen auf und dient nur dem Selbstzweck.
Einstecken, Einschalten & Loslegen war mal die Devise – ich hoffe, dass nach all den bitteren Erfahrungen der letzten Zeit wieder auf diese Out of the Box Erfahrung Wert gelegt wird.

In dem Sinne ‚Good Luck and Good Night‘

Bis zum nächsten Mal

David

Das Nette Katzenfoto wurde bereitgestellt von

Photo by DNK.PHOTO on Unsplash.

David Okon
David Okon
Senior Systems Engineer

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu glücklichen Menschen zu machen.

SSH – Der Schlüssel zum Erfolg

Seal of ApprovalOder wie man das meiste aus SSH herauskitzelt.

SSH wird von den meisten Sysadmins genutzt, aber selten so wie es genutzt werden sollte.
Die meisten Administratoren verwenden das folgende Kommando Tag ein Tag aus.

ssh-keygen -t rsa -b 4096 -C "dummy_user@fqdn_dummy.com"

Zerlegen wir das Kommando mal in seine Einzelteile und versuchen zu verstehen was diese eigentlich tun.

Der Parameter '-t' gibt an welchen Key-Typ wir rsa/dsa/ecdsa/ecdsa-sk/ed25519 erstellen wollen. Hierbei wird von kleineren RSA-Keys unter 4096 Bits inzwischen abgeraten. DSA ist als unsicher deklariert und sollte auch seit Version 7 von OpenSSH auch nicht verwendet werden. ECDSA ist wegen der NSA ggf. problematisch zum nachlesen hier. So bleibt nur ED25519 welchen ich bei meiner täglichen Arbeit kaum sehe. Dies sollte aber heutzutage der De-Facto-Standard-Key sein, mit dem das obige Kommando aufgerufen wird.

'-b' für die Bits welche verwendet werden sollen. Wenn nun an dieser Stelle die Frage aufkommt mit welcher Bits-Anzahl ED25519 erstellt werden sollte, sei gesagt dass dieser eine festgelegte Länge hat und damit diesen Parameter ignoriert.

'-C' steht für Comment und dieser kann beliebig sein. Zumeist wird hier aber zur besseren Nachvollziehbarkeit von den Admins dieser Welt das Pattern Username@Hostname verwendet, damit man sehen kann für wen dieser Key erstellt wurde.

Im obigen Beispiel fehlt der Parameter '-N' welcher für new_passphrase bzw. das Passwort steht, wenn man den fehlenden Parameter '-N' mit "" ohne Zeichenkette angibt erhält man einen passwortlosen, privaten SSH-Schlüssel. Zusätzlich wird ein öffentlicher Schlüssel erstellt.

Verbessern wir das obige Kommando: ssh-keygen -t ed25519 -N'' -C 'dummy_user@fqdn_dummy.com'

Der Output des Beispiels:

ssh-keygen -t ed25519 -N'' -C'dummy_user@fqdn_dummy.com'
Generating public/private ed25519 key pair.
Enter file in which to save the key (/root/.ssh/id_ed25519): /root/.ssh/dummy
Created directory '/root/.ssh'.
Your identification has been saved in /root/.ssh/dummy.
Your public key has been saved in /root/.ssh/dummy.pub.
The key fingerprint is:
SHA256:14RQXbFyQCtEZfnGN8O7hV4h9hAEY0SYQN9Y0+9TRp8
root@fqdn_dummy.com The key's randomart image is:
+--[ED25519 256]--+
|      .oooO%O+o. |
|        .==o== ..|
|         oo.+o*.o|
|           + *+E=|
|        S . o.=+*|
|         .    .=o|
|             . .+|
|              .. |
|                 |
+----[SHA256]-----+
[root@fqdn_dummy.com .ssh]# ll
total 8
-rw-------. 1 root root 464 Nov 14 22:45 dummy
-rw-r--r--. 1 root root 108 Nov 14 22:45 dummy.pub

Damit hätten wir einen Standard-SSH-Schlüsselpaar, welches zumeist in den Unternehmen vergessen wird, wenn Mitarbeiter das Unternehmen verlassen oder die Abteilungen wechseln und auch durch automatisierte Deployments wird es oft als Karteileiche liegen gelassen.

Wie wäre es wenn wir ablaufende SSH-Schlüsselpaare hätten, welche nach einer gewissen Zeit ablaufen und zwar von selbst?

Was vielen nicht bewusst ist, ist dass dies SSH eigentlich schon von ganz allein kann, nur nutzt es kaum jemand.

Beginnen wir mit dem ersten Schritt und generieren uns eine CA (Certificate Authority).

ssh-keygen -t ed25519 -N '' -C 'ca' -f ca

Da diese CA unser Dreh- und Angelpunkt ist bedarf es Achtsamkeit, damit diese nie in falsche Hände gelangt.

Dank dieser CA können wir nun Zertifikate von Hosts und Benutzern signieren.

Als Beispiel nehmen wir einen Benutzer 'test' welcher sich per SSH an den Host namens ColdMoon anmelden soll.

Wir brauchen also für beide Zertifikate und einen SSH Schlüssel.

Bevor wir es vergessen müssen wir unsere vorher erstellte CA auf unserem SSH Server in der sshd_config als 'TrustedUserCAKeys /etc/ssh/ca.pub' eintragen.

Nun nehmen wir von unserem Benutzer 'test' auf seinem Laptop und den dort bereits erstellten öffentlichen Schlüssel mit dem wir ihm begrenzten Zugriff auf unsere Infrastruktur geben wollen in diesem Fall unser Rechner ColdMoon.

Im Vorfeld haben wir schon den Benutzer auf dem Rechner angelegt, und der Kollege 'test' hat uns seinen öffentlichen Schlüssel per Email geschickt.
Von unserem Vorgesetzten wissen wir das der Kollege 'test' nur 1 Woche ein Praktikum bei uns vornimmt und danach das Unternehmen wieder verlässt.

Auf gehts wir erstellen einen zeitlich begrenzten Zugang:

ssh-keygen -s ca -I Azubi_auf_Zeit -n test -V +1w -z 1 test.pub
Signed user key test-cert.pub: id "Azubi_auf_Zeit" serial 1 for test valid from 2019-11-13T09:00:00 to 2019-11-20T09:00:00

Das Resultat dieses Kommandos ist das wir ein signiertes 'test-cert.pub' erhalten mit eine Lebenszeit von 1 Woche.
Dieses senden wir umgehend unseren Praktikanten zu mit dem Hinweis das er sich mit dem folgenden Kommando nun an dem Rechner ColdMoon anmelden kann.

ssh -i ~/.ssh/test -i ~/.ssh/test-cert.pub test@ColdMoon -v

Ich habe mal den Verbose-Schalter genommen um zu zeigen wie das Zertifikat sich dann gegen ColdMoon anmeldet.

...
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering public key: test ED25519 SHA256:4A3ab2/7dq0klERi9IevmSnTZd7dkOuuP8yrWCZ24gI explicit
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: test ED25519-CERT SHA256:4A3ab2/7dq0klERi9IevmSnTZd7dkOuuP8yrWCZ24gI explicit
debug1: Server accepts key: test ED25519-CERT SHA256:4A3ab2/7dq0klERi9IevmSnTZd7dkOuuP8yrWCZ24gI explicit
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.242.67 ([192.168.242.67]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Requesting authentication agent forwarding.
debug1: Sending environment.
debug1: Sending env LC_CTYPE = UTF-8
Last login: Thu Nov 14 11:00:14 2019 from 192.168.242.225
[test@coldmoon ~]$

Die Authentifizierung wird nun die gesamte Woche lang funktionieren in der der Praktikant Zugriff auf dem Rechner braucht, danach weil es nur zeitlich begrenzt ist nicht mehr. Damit ist für den Praktikanten kein Zugriff auf unserer Infrastruktur mehr möglich. Dies funktioniert auch mit anderen Hosts oder Services, welchen man nur für einen Zeitraum einen begrenzten Zugriff per SSH geben möchte.

Der Parameter '-V' gibt den Validity_Interval an, also den Zeitraum der Gültigkeit, und der Parameter '-z' eine Serialnumber, welche von uns frei gewählt werden kann.

Dies kann mit den üblichen Systemmitteln automatisiert werden oder per Ansible/Puppet auch auf Systeme verteilt werden.
Schöner ist es noch wenn es ohne viel manuelle Arbeit geht. Dies zeige ich in meinem nächsten Blogpost welcher Vault aus dem Hause Hashicorp zeigt.

Gruss

David

David Okon
David Okon
Senior Systems Engineer

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu glücklichen Menschen zu machen.