Oracle Linux 10 steht für 64-Bit-Intel-, AMD- und 64-Bit-Arm-Plattformen zur Verfügung und baut auf den Unbreakable Enterprise Kernel 8 (UEK 8.1).

Der SSH-Dienst ist ein natürliches Angriffsziel jedes Servers. Klassische Abwehrmaßnahmen zielen darauf aus, den root-Login zu sperren (das sollte eine Selbstverständlichkeit sein) und mit Fail2ban wiederholte Login-Versuche zu blockieren. Eine weitere Sicherheitsmaßnahme besteht darin, den Passwort-Login mit einer Zwei-Faktor-Authentifizierung (2FA) zu verbinden. Am einfachsten gelingt das server-seitig mit dem Programm google-authenticator. Zusätzlich zum Passwort muss nun ein One-time Password (OTP) angegeben werden, das mit einer entsprechenden App generiert wird. Es gibt mehrere geeignete Apps, unter anderem Google Authenticator und Authy (beide kostenlos und werbefrei).

Es gibt verschiedene Konfigurationsoptionen. Ziel dieser Anleitung ist es, parallel zwei Authentifizierungsvarianten anzubieten:

• mit SSH-Schlüssel (ohne 2FA)
• mit Passwort und One-time Password (also mit 2FA)

Grundlagen: sshd-Konfiguration

Vorweg einige Worte zu Konfiguration des SSH-Servers. Diese erfolgt durch die folgenden Dateien:

/etc/ssh/sshd_config
/etc/ssh/sshd_config.d/*.conf
/etc/crypto-policies/back-ends/opensshserver.config  (nur RHEL)

Verwechseln Sie sshd_config nicht mit ssh_config (ohne d) für die Konfiguration des SSH-Clients, also für die Programme ssh und scp! opensshserver.config legt fest, welche Verschlüsselungsalgorithmen erlaubt sind.

Beachten Sie, dass bei Optionen, die in den sshd-Konfigurationsdateien mehrfach eingestellt sind, der erste Eintrag gilt (nicht der letzte)! Das gilt auch für Einstellungen, die am Beginn von sshd_config mit Include aus dem Unterverzeichnis /etc/ssh/sshd_config.d/ gelesen werden und die somit Vorrang gegenüber sshd_config haben.

Werfen Sie bei Konfigurationsproblemen unbedingt auch einen Blick in das oft übersehene sshd_config.d-Verzeichnis und vermeiden Sie Mehrfacheinträge für ein Schlüsselwort!

Weil die Dateien aus /etc/ssh/sshd_config.d/ Vorrang gegenüber sshd_config haben, besteht eine Konfigurationsstrategie darin, sshd_config gar nicht anzurühren und stattdessen alle eigenen Einstellungen in einer eigenen Datei (z.B. sshd_config.d/00-myown.conf) zu speichern. 00 am Beginn des Dateinamens stellt sicher, dass die Datei vor allen anderen Konfigurationsdateien gelesen wird.

Überprüfen Sie bei Konfigurationsproblemen mit sshd -T, ob die Konfiguration Fehler enthält. Wenn es keine Konflikte gibt, liefert sshd -T eine Auflistung aller aktuell gültigen Einstellungen. Die Optionen werden dabei in Kleinbuchstaben angezeigt. Mit grep -i können Sie die für Sie relevante Einstellung suchen:

sshd -T | grep -i permitro

  permitrootlogin yes

Änderungen an sshd_config werden erst wirksam, wenn der SSH-Server die Konfiguration neu einliest. Dazu führen Sie das folgende Kommando aus:

systemctl reload sshd       # RHEL
systemctl reload ssh        # Debian, Ubuntu

google-authenticator einrichten

Google Authenticator bezeichnet zwei unterschiedliche Programme: einerseits die App, die sowohl für iOS als auch für Android verfügbar ist, andererseits ein Linux-Kommando, um die 2FA auf einem Linux-Server einzurichten. Während der Code für die Smartphone-Apps nicht öffentlich ist, handelt es sich bei dem Linux-Kommando um Open-Source-Code. Das resultierende Paket steht für RHEL-Distributionen in der EPEL-Paketquelle zur Verfügung, bei Ubuntu in universe.

dnf install google-authenticator qrencode   # RHEL + EPEL
apt install libpam-google-authenticator     # Debian, Ubuntu

Nach der Installation führen Sie für den Account, als der Sie sich später via SSH anmelden möchten (also nicht für root), das Programm google-authenticator aus. Nachdem Sie den im Terminal angezeigten QR-Code gescannt haben, sollten Sie zur Kontrolle sofort das erste OTP eingeben. Sämtliche Rückfragen können Sie mit y beantworten. Die Rückfragen entfallen, wenn Sie das Kommando mit den Optionen -t -d -f -r 3 -R 30 -W ausführen. Das Programm richtet die Datei .google-authenticator im Heimatverzeichnis ein.

user$ google-authenticator
  Do you want authentication tokens to be time-based (y/n)
  Enter code from app (-1 to skip): nnnnnn
  Do you want me to update your .google_authenticator file? (y/n)
  Do you want to disallow multiple uses of the same
    authentication token? (y/n)
  ...

SSH-Server-Konfiguration

Das nächste Listing zeigt die erforderlichen sshd-Einstellungen. Mit der Methode keyboard-interactive wird PAM für die Authentifizierung verwendet, wobei auch eine mehrstufige Kommunikation erlaubt ist. Die ebenfalls erforderliche Einstellung UsePAM yes gilt bei den meisten Linux-Distributionen standardmäßig. Am besten speichern Sie die folgenden Zeilen in der neuen Datei /etc/ssh/sshd_config.d/00-2fa.conf. Diese wird am Beginn der sshd-Konfiguration gelesen und hat damit Vorrang gegenüber anderen Einstellungen.

# Datei /etc/ssh/sshd_config.d/00-2fa.conf
UsePAM                           yes
PasswordAuthentication           yes
PubkeyAuthentication             yes
ChallengeResponseAuthentication  yes
# Authentifizierung wahlweise nur per SSH-Key oder
# mit Passwort + OTP
AuthenticationMethods            publickey keyboard-interactive

PAM-Konfiguration

Der zweite Teil der Konfiguration erfolgt in /etc/pam.d/sshd. Am Ende dieser Datei fügen Sie eine Zeile hinzu, die zusätzlich zu allen anderen Regeln, also zusätzlich zur korrekten Angabe des Account-Passworts, die erfolgreiche Authentifizierung durch das Google-Authenticator-Modul verlangt:

# am Ende von /etc/pam.d/sshd (Debian, Ubuntu)
...
# Authenticator-Zifferncode zwingend erforderlich
auth required pam_google_authenticator.so

Alternativ ist auch die folgende Einstellung mit dem zusätzlichen Schlüsselwort nullok denkbar. Damit akzeptieren Sie einen Login ohne 2FA für Accounts, bei denen Google Authenticator noch nicht eingerichtet wurde. Sicherheitstechnisch ist das natürlich nicht optimal — aber es vereinfacht das Einrichten neuer Accounts ganz wesentlich.

# am Ende von /etc/pam.d/sshd (Debian, Ubuntu)
...
# Authenticator-Zifferncode nur erforderlich, wenn 
# Google Authenticator für den Account eingerichtet wurde
auth required pam_google_authenticator.so nullok

Wenn Sie RHEL oder einen Klon verwenden, sieht die PAM-Konfiguration ein wenig anders aus. SELinux verbietet dem SSH-Server Zugriff auf Dateien außerhalb des .ssh-Verzeichnisses. Deswegen müssen Sie die Datei .google-authenticator vom Home-Verzeichnis in das Unterverzeichnis .ssh verschieben. restorecon stellt sicher, dass der SELinux-Kontext für alle Dateien im .ssh-Verzeichnis korrekt ist.

user$ mv .google-authenticator .ssh/    (nur unter RHEL!)
user$ restorecon .ssh

In der Zeile auth required übergeben Sie nun als zusätzliche Option den geänderten Ort von .google-authenticator. Falls Sie die nullok-Option verwenden möchten, fügen Sie dieses Schlüsselwort ganz am Ende hinzu.

# am Ende von /etc/pam.d/sshd (RHEL & Co.)
...
auth required pam_google_authenticator.so secret=/home/${USER}/.ssh/.google_authenticator

Test und Fehlersuche

Passen Sie auf, dass Sie sich nicht aus Ihrem Server aussperren! Probieren Sie das Verfahren zuerst in einer virtuellen Maschine aus, nicht auf einem realen Server!

Vergessen Sie nicht, die durchgeführten Änderungen zu aktivieren. Vor ersten Tests ist es zweckmäßig, eine SSH-Verbindung offen zu lassen, damit Sie bei Problemen die Einstellungen korrigieren können.

sshd -T                   # Syntaxtest
systemctl reload sshd     # RHEL
systemctl reload ssh      # Debian + Ubuntu

Bei meinen Tests hat sich die Google-Authenticator-Konfiguration speziell unter RHEL als ziemlich zickig erwiesen. Beim Debugging können Sie client-seitig mit ssh -v, server-seitig mit journalctl -u sshd nach Fehlermeldungen suchen.

Die Anwendung von Google Authenticator setzt voraus, dass die Uhrzeit auf dem Server korrekt eingestellt ist. Die One-Time-Passwords gelten nur in einem 90-Sekunden-Fenster! Das sollten Sie insbesondere bei Tests in virtuellen Maschinen beachten, wo diese Bedingung mitunter nicht erfüllt ist (z.B. wenn die virtuelle Maschine pausiert wurde). Stellen Sie die Zeit anschließend neu ein, oder starten Sie die virtuelle Maschine neu!

Was ist, wenn das Smartphone verlorengeht?

Für den Fall, dass das Smartphone und damit die zweite Authentifizierungsquelle verlorengeht, zeigt das Kommando google-authenticator bei der Ausführung fünf Ziffernfolgen an, die Sie einmalig für einen Login verwendet können. Diese Codes müssen Sie notieren und an einem sicheren Ort aufbewahren — dann gibt es im Notfall einen »Plan B«. (Die Codes sind auch in der Datei .google_authenticator enthalten. Auf diese Datei können Sie aber natürlich nicht mehr zugreifen, wenn Sie keine Login-Möglichkeit mehr haben.)

Die App Google Authenticator synchronisiert die 2FA-Konfiguration automatisch mit Ihrem Google-Konto. Die 2FA-Konfiguration kann daher auf einem neuen Smartphone rasch wieder hergestellt werden. Schon eher bereitet Sorge, dass nur die Kenntnis der Google-Kontodaten ausreichen, um Zugang zur 2FA-Konfiguration zu erhalten. Die Cloud-Synchronisation kann in den Einstellungen gestoppt werden.

Auch Authy kann die 2FA-Konfiguration auf einem Server der Firma Twilio speichern und mit einem weiteren Gerät synchronisieren. Anders als bei Google werden Ihre 2FA-Daten immerhin mit einem von Ihnen zu wählenden Passwort verschlüsselt. Mangels Quellcode lässt sich aber nicht kontrollieren, wie sicher das Verfahren ist und ob es den Authy-Betreibern Zugriff auf Ihre Daten gewährt oder nicht. 2024 gab es eine Sicherheitspanne bei Twilio, bei der zwar anscheinend keine 2FA-Daten kompromittiert wurden, wohl aber die Telefonnummern von 35 Millionen Authy-Benutzern.

Sicherheits- und Privacy-Bedenken

Authenticator-Apps funktionieren prinzipiell rein lokal. Weder der beim Einrichten erforderliche Schlüssel bzw. QR-Code noch die ständig generierten Einmalcodes müssen auf einen Server übertragen werden. Die Apps implementieren den öffentlich standardisierten HMAC-based One-Time Password Algorithmus (OATH-HOTP).

Allerdings bieten einige OTP-Apps die Möglichkeit, die Account-Einträge über ein Cloud-Service zu sichern (siehe oben). Diese Cloud-Speicherung ist eine mögliche Sicherheitsschwachstelle.

Davon losgelöst gilt wie bei jeder App: Sie müssen der Firma vertrauen, die die App entwickelt hat. Der Code der App Google Authenticator war ursprünglich als Open-Source verfügbar, seit 2020 ist das leider nicht mehr der Fall. Wenn Sie weder Google Authenticator noch Authy vertrauen, finden Sie im Arch Linux Wiki Links zu Apps, deren Code frei verfügbar ist.

Quellen, Links

• https://de.wikipedia.org/wiki/Google_Authenticator
• https://de.wikipedia.org/wiki/HMAC-based_one-time_password
• https://www.authy.com/
• https://wiki.archlinux.org/title/Google_Authenticator
• https://9to5mac.com/2024/07/04/authy-hack/
• https://security.googleblog.com/2023/04/google-authenticator-now-supports.html
• https://futurezone.at/apps/google-authenticator-update-2-factor-authentification-cloud-synchronisierung-google-konto/402425360

In Kubernetes wurde ein Sicherheitsproblem entdeckt, bei dem ein unbefugter Benutzer in der Lage sein kann, per SSH auf einen VM-Knoten zuzugreifen, der ein mit dem Kubernetes Image…

Der Sicherheitsexperten Qualys hat mit der RegreSSHion getauften Sicherheitslücke in OpenSSH eine Schwachstelle gefunden, die sich remote ausnutzen lässt, um Code darüber auszuführen.

Eine von Qualys entdeckte Sicherheitslücke im OpenSSH-Server mit einem CVSS-Score von 9 wurde geschlossen. Erfolgreiche Angreifer erhalten automatisch Root-Rechte.

Quelle

Dem Forscherteam von Qualys ist es gelungen, eine ältere Sicherheitslücke in OpenSSH, die schon eigentlich längst geschlossen war, erneut auszunutzen. Die neue Lücke wird als CVE-2024-6387 geführt und ist deswegen brisant, weil Sie bei Erfolg dem Angreifer Root-Rechte ohne vorherige Authentifizierung ermöglicht. Die nötigen Bedingungen für ein Ausnutzen der Lücke sind allerdings nicht ganz trivial.

Die gesamte Erläuterung der Sicherheitslücke ist im Bericht von Qualys umfangreich erläutert wollen. Wenn wir es schaffen, werden wir diesen schon Mittwoch im Risikozone-Podcast detaillierter erläutern.

So viel sei gesagt: die Lücke existierte schon mal als CVE-2006-5051, wurde dann gefixt und konnte jetzt (erstmals) ausgenutzt werden, da der eigentlich kritische Teil 2020 wieder versehentlich eingebaut wurde. Der Fehler selber baut darauf, dass syslog() zur Protokollierung asynchron aufgerufen wird, obwohl die Funktion nicht "async-signal-safe" ist. Kann ein Angreifer Timingeigenschaften ausnutzen, wird er in die Lage versetzt, Code einzuschleusen, der in einem privilegierten Teil von OpenSSH ausgeführt wird. Der Zeitaufwand ist allerdings hierfür nicht zu unterschätzen, da das Codefragment nur bei einem Verbindungstimeout aufgerufen wird.

Es ist gemäß des Qualys-Berichtes hervorzuheben:

• Die OpenSSH-Versionen vor 4.4p1 (2006) sind angreifbar, sofern sie nicht explizit gepatcht wurden.
• Die OpenSSH-Versionen zwischen 4.4p1 und 8.5p1 (2021) hatten nicht den besagten Code drin.
• Die OpenSSH-Versionen ab 8.5p1 hatten den Code wieder drin.
• Mit OpenSSH 9.8p1 wurde die Lücke gepatcht.

Mit anderen Worten: abhängig von eurem System ist die Schwachstelle vorhanden, weswegen ihr in eure Distribution schauen solltet, ob es Updates gibt.

OpenSSH ist nichtsdestotrotz im Hinblick auf seine Rolle und Exposition eines der sichersten Programme der Welt. Die Software ist ein sehr stringent abgesicherter Dienst, der u. a. auf Sandboxing-Mechansimen setzt, um den Umfang der Codesegmente, die als root ausgeführt werden, gering zu halten. Diese Lücke ist eine der seltenen Situationen, in der trotzdem ein Security-Bug vorhanden ist. Dabei ist eine Ausnutzung vergleichsweise aufwändig.

Cisco Talos, ein zu Cisco gehörendes Cybersecurity-Unternehmen,  beobachtet seit Mitte März 2024 einen weltweiten Anstieg von Brute-Force-Angriffen gegen eine Vielzahl von Zielen, darunter…

OpenSSH will die Unterstützung für DSA-Schlüssel entfernen und informiert über den Zeitplan und den einhergehenden Prozess dazu.

Die freie SSH-Implementierung OpenSSH ist in Version 9.4 erschienen. Die neue Ausgabe bringt Bugfixes und einige neue Features.

Darunter fällt das neue ssh_config “Tag” und ein entsprechendes “Match tag”-Prädikat. Das Config-Tag könne dazu verwendet werden, um Konfigurationsblöcke auszuwählen, was die Konfiguration erleichtern soll. Neu ist auch die Möglichkeit des Forwarding von Unix-Domain-Sockets.

Neben den Neuerungen werden auch eine Reihe von Fehlern ausgebügelt. Die neue Version entfernt die Unterstützung für ältere Versionen von libcrypto, teilen die Entwickler mit. Und OpenSSH benötigt nun LibreSSL ab Version 3.1.0 oder OpenSSL ab Version 1.1.1.

Der Beitrag OpenSSH 9.4 verbessert Konfiguration erschien zuerst auf Linux-Magazin.

Mit Version 9.3p2 der freien Verschlüsselungssuite OpenSSH schließen die Entwickler eine kritische Sicherheitslücke, die den Remote-Zugriff ermöglicht.

Angreifer könnten dann unter bestimmten Umständen Schadcode einschleusen, warnt das OpenSSH-Projekt. Auch das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat die Sicherheitslücke auf dem Radar und stuft sie als hochriskant ein. Ein entfernter, anonymer Angreifer kann eine Schwachstelle in OpenSSL ausnutzen, um einen Denial of Service Angriff durchzuführen, schreibt das BSI in seiner Warnmeldung.

Die Entwickler erläutern in der Ankündigung zur neuen Version von OpenSSH, die die Lücke schließt, dass bestimmte Voraussetzungen gegeben sein müssen, damit der Remote-Zugriff funktioniert. So sei die das Vorhandensein bestimmter Bibliotheken auf dem Opfersystem nötig und die Fernausnutzung erfordert auch, dass der Agent an ein vom Angreifer kontrolliertes System weitergeleitet wurde.

Der Beitrag OpenSSH 9.3p2 schließt hochriskante Lücke erschien zuerst auf Linux-Magazin.