Benachrichtigung bei VM-Ausfall

[TErxleben]

*Autsch!*

Ich habe (beruflich, nicht im Homelab - aber ich muss einfach antworten...) gerade etwas umstrukturiert, "normale" ssh-keys verwende ich seit vielen, vielen, vielen Jahren.

Meine jetzigen ssh-keys sind nur dann greifbar, wenn ein Yubikey/Nitrokey die wertlose "Secret-Key"-Datei, die ganz normal im Dateisystem (von zwei redundaten Rechnern) liegt, aktiv entschlüsselt. Ich füttere damit einen ssh-agent. Verwenden kann ich den Key aber nur in der Sekunde, in der ich aktiv die momentane "Presence" des Nitrokeys bestätige. Den Agenten kann ich durch einen ssh-tunnel weitergeben und komme dann von dem Jumphost an einige Dutzend Systeme, die ich mit minimalen Aufwand meinerseits ("Presence"-Taste betätigen) sicher administrieren kann.

So geht es natürlich sehr sicher. Bedeutet aber natürlich auch einen gewissen Aufwand. Wer macht das aber schon so konsequent?
Meistens lümmeln die keys in irgendwelchen lokalen Dateisystemen rum. Dort sehe ich die Hauptgefahr. Wie machst du es denn bei reiner Inter-Server-kommunikation mit? Da hast dann ja wahrscheinlich eher Keys direkt im Dateisystem. Ein fettes Passwort lässt sich genauso gut wie ein key absichern. Keylogger sind da auch irrelevant. Logs sind auch nur für autorisierte Nutzer einsehbar.
was spricht denn dann gegen sshpass?

Passwort-Authentifizierung ist auf den Zielkisten nicht nur für root, sondern für alle Nutzer komplett deaktiviert.

Um das Szenario abzurunden: ich sitze dabei vor einem möglichst sicheren System, meist Qubes-OS.

Das geht dann schon fast in Richtung Paranoia ;-)

Man kann sicher von dem Beschriebenen abweichen (Homelab...) und Kompromisse eingehen, aber ssh-KEYS bilden in meiner Welt die Grundlage.

In meiner Welt ist konsequente Nutzung von MFA die Grundlage. Es lässt sich einfacher zentral administrieren und ist immanent sicherer. sshkeys sind doch eigentlich nur besonders lange Passwörter.

 

[TErxleben]

Indem ich den erzeuge und dann den public key über eine Automatisierung (per Skript oder ansible, ist am Ende wurst) ausrolle. Es gibt auch passwort-manager, die dann als Agent dafür fungieren können.


Passwort-Manager mit ssh-agent Funktion tun dafür nach meiner Erfahrung ganz gut.

Damit wirst du dann keys auf ehemals autorosierten Geräten zuverlässig los? Da lachen doch die Hühner.
Oder entfernst du einen key und verprellst 15 andere clients?

Man kann auch bei ssh-keys Passphrasen vergeben, mit einen ssh-agent muss man die dann auch nur einmal pro Session eintippen.



LOL. Anders als Antiviren-Schlangenöl ( siehe: https://www.golem.de/news/antivirensoftware-die-schlangenoel-branche-1612-125148.html ) haben die schon mal den klaren Vorteil, dass der private Key eben im Regelfall nur im Client vorhanden sind und aufgrund der verwendeten Algorithmen auch nicht so einfach über brute-force oder Wörterbuchattacken angegriffen werden können. Szenarien wie ein mitgeschnittenes Passwort (etwa über einen keylogger) kann damit auch nicht passieren.

Starke Passwörter und fail2ban ist dein Freund. keylogger sind mit MFA raus.

Das ist nun wirklich blödsinn, sorry. Es ist deutlich einfacher "aus Versehen" seine Passwörter irgendwo (weil das ja so schön bequem ist) in eine Konfigdatei reinzuschreiben, statt den (im Regelfall ja in einen eigenen Verzeichnis befindlichen) ssh-Schlüssel aus Versehen hochzuladen.

Steile These.

Und genau das kann man eben auch mit ssh-keys kombinieren.

Ich sehe ja das Argument ein, dass deren Deployment bei einer größeren Zahl Sever und häufig wechselnder User unhandlich und nervig wird. Das wird mit Passwörtern (die man dazu ja auch auf jeden Server pflegen muss oder halt eine Authentifizierungs-Instanz wie AD/LDAP/Keycloak ins Boot holen->Höhere Komplexität) aber nicht besser. Wenn man die Größenordnung erreicht hat, sind dann eher automatisch ablaufende ssh-Zertifikate das Mittel der Wahl siehe https://smallstep.com/blog/use-ssh-certificates/

Aber soweit muss man erstmal kommen, das sehe ich im Homelab jetzt nicht so wirklich.

Ich wollte nur sagen, dass die inzwischen fast verteufelten Passwörter verglichen mit keys kaum schlechter abschneiden.

 

[UdoB]

Das geht dann schon fast in Richtung Paranoia ;-)

Ja. Ich streite die Paranoia natürlich ab, gebe die Richtung aber zu

Jeder legt seinen eigenen Sicherheitslevel selber fest, insbesondere im Homelab und bei irgendwelchen Spaß-VMs sowohl im Homelab als auch "draußen". Man kann vieles sicherer betreiben, als oft der Fall ist. VPNs und eben SSH sind ja keine neue Erfindung.

Der Schwierigkeitsgrad nimmt jedenfalls unerfreulich schnell zu. So schnell und simpel wie lediglich Username+Passwort ist das alles leider nicht, ssh-Keys hin und Passkeys her...

Meine wichtigste Empfehlung ist: man sollte die Angriffs- und die Verteidigungs- bzw. Sicherheitsmaßnahmen kennen. Erst danach kann man sich selber den passenden Kompromiss auswählen

In meiner Welt ist konsequente Nutzung von MFA die Grundlage.

Das ist schonmal sehr gut.

 

[6equj5]

Intern verwende ich Zabbix, und ja, das ist definitiv "dick"

Das läuft bei mir im Docker und ich finde es extrem schlank. Kaum meßbar CPU und knapp 2G RAM. Für alle Container zusammen.

 

[UdoB]

Das läuft bei mir im Docker und ich finde es extrem schlank.

Prima!
Wie groß ist die Datenbank? In meinem Homelab habe ich momentan ~100 GB in einer Mariadb (und im Job sind es knapp 200 GB in PostgreSQL). Der kontinuierliche Schreibvorgang stresst jede SSD --> ein Grund mehr für "Enterprise Class w/ PLP" und entsprechendes Monitoring.