© sosiukin / 123rf.com

OpenSSH gehört zweifellos zu den wichtigsten Open-Source-Projekten überhaupt. Trotz des langen Bestehens überzeugt SSH wieder und wieder mit Neuerungen.

Linux ohne SSH lässt sich kaum vorstellen, bei mir scheitert der bloße Gedanke daran. Die Secure Shell ist und bleibt einer der wichtigsten Bausteine der Open-Source-Welt. Nicht nur, weil sie schlicht grandios funktioniert, sondern auch, weil das Projekt Security groß schreibt. Wir leben in Zeiten, in denen Microsoft uralte Sicherheitslücken im Remote Desktop Protocol RDP als “Designentscheidung” anzupreisen versucht. Redmond findet, es müsse sichergestellt sein, “dass es auf jedem Windows-System immer mindestens einen Benutzer gibt, der sich noch anmelden kann.” [1] Selbstverständlich auch Remote, nicht lokal, sonst wäre es ja keine RDP-Lücke.

Während man sich in Redmond noch darum bemüht das Zahlvieh für dumm zu verkaufen, hat das OpenSSH-Projekt längst die Zukunft entdeckt. Allerdings setzt das Projekt nicht auf immer längere Schlüssel, es entwickelt neue Verfahren. Dabei handelt es sich nicht nur um Verschlüsselungsverfahren, sondern auch um automatische Upgrades von Server-Schlüsseln.

Inzwischen besitzen durchaus manche Nutzer bereits ein Gespür dafür, welche Schlüssellängen bei welchen Algorithmen genügen. Daran, dass womöglich Schlüsselpaare auf Servern ebenfalls erneuert werden müssten, denken dagegen die wenigsten. Man mag es kaum glauben, aber schon seit Version 6.8 kann der OpenSSH-Client alternative Host-Schlüssel eines Servers akzeptieren – indem im Rahmen einer ordentlichen Key-Rotation Ersatz für Public Keys akzeptiert wird, bevor sie veraltet sind. Genau so stelle ich mir gute Software vor!

Wichtiger Ersatz: SFTP

Während also Microsoft es für den Königsweg hält, vorsintflutliche Sicherheitslücken mit neuem Charme zu garnieren, schneidet OpenSSH alte Zöpfe ab. Dazu gehört neben DSA und MD5 das vermutlich vielen vertraute SCP. Da es sich mehrfach als vulnerabel gegen Command-Injection-Attacken [2] erwiesen hatte, ist SCP bereits seit Jahren als deprecated markiert. Stattdessen sollte längst das wesentlich robuster entwickelte Protokoll SFTP über SSH zum Einsatz kommen. Zudem zeigt sich SFTP deutlich flexibler. Wer unbedingt das Legacy-SCP-Protokoll benötigt, kann es per Schalter »-O« reaktiveren, etwa auf antiken, denkmalgeschützten Servern, die auf entsprechend altem Globbing bestehen.

Doch OpenSSH beerdigt nicht nur veraltete Chiffren, auch nach wie vor zeitgemäße Verfahren wie RSA lassen sich dank Parametern wie »RequiredRSASize« seit OpenSSH 9.1 einschränken. Admins sollten wissen, dass RSA-Schlüssellängen von unter 2048 Bit längst nicht mehr dem aktuellen Standard entsprechen. Wenn man nicht direkt auf ECDSA-Keys umsteigt, sollte man zumindest zu RSA4096 greifen. Wer als Bedingung »RequiredRSASize« auf »2048« fordert, bewirkt vielleicht obendrein, dass allzu nachlässige Kollegen endlich wieder einmal über ihre Schlüsselpaare nachdenken und an dieser Stelle zum Status Quo übergehen.

Post-Quantum

Die OpenSSH-Welt gleicht Villarriba und nicht Villabajo – besonders, was die langfristige Planung betrifft. Obwohl ich persönlich sehr von Anton Zeilingers Forschung fasziniert bin und das Konzept non-deterministischer Maschinen aus der Theoretischen Informatik kenne, werde ich mich hüten, den OpenSSH-Code dahingehend auf Security zu untersuchen. Zu dünn ist mir mein Kenntnisstand, um darüber belastbare Aussagen zu treffen.

Was ich dagegen weiß: Kluge Menschen haben sich »sntrup761x25519-sha512« ausgedacht. Ich bin mir außerdem dessen bewusst, dass das Konzept des Quantencomputers für die Theoretische Informatik nichts wirklich Neues ist – die Konzepte sind, auf einer Zeitskala der Informatik abgebildet, steinalt. Wem also angesichts der Entwicklungen im Bereich des Quantum Computings Zweifel kommen, dem sei angeraten, die passenden RFCs [3] genauer zu studieren [4]. Mit OpenSSH 9.0 hat jedenfalls die Methode Hybrid Streamlined NTRU Prime + x25519 für den sichern Schlüsselaustausch Einzug ins Feature-Set gehalten.

Strafminuten

Seit OpenSSH 9.8 enthält die Software einen eingebauten Schutz gegen Fehlverhalten. Bislang habe ich zu diesem Zweck mein präferiertes Tool Fail2ban [5] eingespannt. Was »PerSourcePenalties« zu leisten vermag, muss sich erst noch herausstellen. Das Feature ist noch relativ neu und meines Erachtens nach nicht vollumfänglich dokumentiert. SSH überwacht damit die Exit-Codes der Prozesse, die sich um die Pre-Auth-Phase kümmern. Registrieren die Prozesse beispielsweise wiederholte Fehlanmeldungen, könnten dahinter Versuche stecken, Passwörter zu erraten. Als Reaktion wird über die jeweilige Client-IP eine Zeitstrafe von zum Beispiel 30 Sekunden verhängt.

Der Ansatz geht allerdings noch ein Stück weiter. Versucht zum Beispiel ein Angreifer, per Exploit Pre-Auth-Prozesse abstürzen zu lassen, bekommt die Software das ebenfalls mit. Ein solcher Bann dürfte deutlich länger ausfallen. Über die Option »PerSourcePenaltyExemptList« schließen Admins bestimmte IP-Adressen oder Netze bei Bedarf von den Penalties aus.

Weiter mit Vertrauen

Als SAP-Basis-Admin muss ich mit dem allzu vertrauten Übel leben, »X11Forwarding« zu benötigen. Warum genau? Weil SAP seit Anbeginn der Zeit ausschließlich einen grafischen (X11), Java-basierten Downloader zur Verfügung stellt. Ich habe mich längst vom Szenario verabschiedet, dass Walldorf auf die verrückte Idee kommt, einen Python-, Perl-, C- oder gar Go-basierten Download-Manager zu entwickeln, der am Ende sogar noch per Repository ausgeliefert wird. Ich erwarte auch kein Flatpak- oder SNAP-Paket. Bislang haben meine Nerven stets die Installation des OpenJDK überlebt – wohlgemerkt für einen Download-Manager, der eine Java-Laufzeitumgebung verlangt. Dagegen wirken Curl oder Wget (Abbildung 1) geradezu absurd bescheiden.

Abbildung 1: Curl und Wget im Größenvergleich auf der Festplatte – neben dem Download-Manager der SAP handelt sich bei den beiden um echte Leichtgewichte.

Was ich seit Jahren schmerzlich vermisse, ist jedoch ein auf der Shell laufender Downloader. Einer, der nicht nur, um etwas herunterzuladen, auf ein grafisches Fenster angewiesen ist, und der einfach nur, nach erfolgreicher Authentifizierung etwas auf meine Platte bringt, vielleicht noch mit etwas Flusskontrolle. Wget und Curl können das seit Äonen.

Doch zurück zum Thema X11-Forwarding. Wenn ich schon nicht darum herumkomme, sollte es zumindest direkt funktionieren und nicht ebenfalls Handstände erfordern, wie es unter Windows allzu häufig eintritt. Auf meiner virtuellen Maschine startet der VcXsrv [6] sowieso per Autostart. Das heißt, meine virtuelle Windose kann damit X11-Fenster darstellen.

Dank moderner SSH-Versionen neigen sich die Zeiten von »xauth list« und »xauth add« ihrem Ende zu. Idealerweise setzen Sie in »/etc/ssh/ssh_config« das Flag »X11Forwarding = no«. Das führt dazu, dass der SSH-Client kein X11-Forwarding betreibt – es sei denn, Sie geben ihm zusätzlich »ForwardX11Trusted = yes« mit. Dadurch und mit einem passenden Eintrag in der persönlichen SSH-Client-Konfiguration (Listing 1), verwandelt sich das X11-Forwarding in ein Kinderspiel.

Host raspi02
      Hostname 172.27.1.2
      User thomas
      IdentityFile ~/.ssh/raspi02
      IdentitiesOnly yes
      ForwardX11Trusted yes
      ForwardAgent yes
      Port 22

Im Listing verwende ich ein weiteres Feature, das in der Dokumentation leicht in den Hintergrund rutscht. »IdentitiesOnly« weist SSH an, ausschließlich die Identität im angegebenen »IdentityFile« an den Server zu schicken und nicht etwa alle möglichen Schlüssel, die der ssh-agent entsperrt hält.

OpenSSH unter Windows

Draußen in der freien Wildbahn existieren nach wie vor Windows-Workstations, von denen aus sich SSH ebenfalls nutzen lässt. Es wäre erfreulich, wenn Microsoft dem Palliativpatienten RDP endlich die ersehnte Ruhe zugestehen würde, um zu erfolgreichen, lange erprobten und gehärteten Protokollen wie SSH zu wechseln. Und tatsächlich gibt es hier Positives zu berichten.

Offenbar muss sich auch Microsoft gedacht haben, dass es besser geht, denn seit Windows 10 build 1809 beziehungsweise Windows Server 2019 ist OpenSSH dort optionales Feature. Damit stehen nicht nur der OpenSSH-Client, sondern auch der Server, SCP, SPTP, der ssh-agent und vieles mehr zu Verfügung.

Das klingt fast zu schön, um wahr zu sein, erspart es doch die Installation lästiger Krücken wie PuTTY, SuperPuTTY, MobaXTerm oder gar solcher Kolosse wie Remote Desktop Manager – ein Stück Software mit der User Experience eines Schlachtschiffs aus dem Ersten Weltkrieg. Mag sein, dass es Nutzer gibt, die gewillt sind, auf den Zugang zu einem Remote-System 30 Sekunden zu warten, bis ein solcher Behemoth Gigabytes an – ja, an was eigentlich? – geladen hat und einsatzbereit ist. Ich bin jedenfalls kein Freund dieser Art Zwangsentschleunigung, vor allem deshalb nicht, weil ich meist aus gutem Grund schnell auf bestimmte Systeme muss.

Bislang habe ich mich nicht großartig für den OpenSSH-Client unter Windows interessiert. Das änderte sich kürzlich spontan, als ich aus purer Neugier versuchte, mich damit auf einem Kundensystem einzuloggen. Meine Überraschung war gewaltig, als eine Kopie meiner SSH-Config (ja, »~/.ssh/config«) zusammen mit meinem Private Key mich ohne Weiteres dazu befähigte. Das war ohne Frage spannend, denn im Zusammenspiel mit dem (aus PuTTY-Zeiten) altbekannten VcXsrv funktionierte sogar X11-Forwarding unter Windows problemlos. Tatsächlich fühlt sich damit ein SSH-Login ausgehend von einer Windows-Maschine nicht mehr wie ein Fremdkörper an.

Ich war also nun im Stande, ebendiese SSH-Config, die ich von meiner Linux-Workstation aus pflege, auch auf der Windows-VM zu nutzen. Auf die muss ich zum Beispiel im Homeoffice zurückgreifen. Dabei gibt es nur einen kleinen Haken: Unter Linux bin ich es gewohnt, »ssh abc<TAB>« einzugeben, um eine virtuelle Maschine mit dem Präfix »abc…« zu erreichen. Die von mir geschätzte AutoCompletion-Funktion fehlt in der Windows-Welt. Zumindest existiert sie nicht im Redmonder Standard.

Doch glücklicherweise finden sich immer wieder Menschen wie Brad Ackerman, der einen Gist [7] anbietet, mit dem man die Hosts aus der Datei »~/.ssh/known_hosts« autovervollständigen kann. Elazar Cohen stellt in einem Kommentar darauf dasselbe Feature für die Hosts aus »~/.ssh/config« zur Verfügung. Ich habe Cohens Lösung [8] an meine SSH-Config-Datei angepasst und übernommen. Obwohl das PowerShell-Skript nicht vollkommen meinen Ansprüchen genügt und längst nicht so feingeschliffen wie unter Linux funktioniert, liegt darin doch eine brauchbare Lösung.

Fazit

Wer tagtäglich pausenlos auf das SSH-Protkoll angewiesen ist, weiß, was es leistet. Bei OpenSSH lässt sich mit Fug und Recht von einer Software sprechen, die hohe Ansprüche an Security erfüllt und dabei größtmöglichen Komfort bietet – genau das, was man haben möchte, egal ob per Public Key Authentication oder per FIDO2. OpenSSH bietet immer eine Lösung. (csi)