An manchen Tagen könnte man meinen, Murphy hat seinen Spaß leidende User zu quälen. Nachdem mich mein Mac schon mehrfach daran erinnerte doch endlich das anstehende Updae auf v10.13.2 durchzuführen, war ich wiedermal so dumm am Anfang des Arbeitstages auf „Installieren“ zu klicken.
Nicht nur, dass ich mal ne gute halbe Stunde Warten und merfache Reboots über mich ergehen lassen durfte, bis ich wieder mit dem Hobel arbeiten konnte, zeigten sich in den darauffolgenden Minuten – die schnell zu Stunden wurden – einige interessante Symptome.
Eigentlich kannte man sowas in erster Linie von MS Windows, sieht so aus als ob Apple nun auch bei dem Punkt angekommen wäre – nur schreien tut hier niemand; was wohl nicht an der im Verhältnis deutlich geringeren Anzahl an Usern liegen dürfte, sondern eher an deren mittlerweile ebenso gut trainierten Leidensfähigkeit, zieht man die letzten Apple Fauxpas in Betracht.
Problem mit ssh
Egal, ein wirklich nerviges, aber umso interessanteres Problem äußerte sich nach dem Update, als ich mittels git pull mein Coderepository auf den neuesten Stand bringen wollte. Da ich nichts mehr hasse, als mir unzählige Paßwörter zu merken, ich aber trotzdem ein Minimum an Sicherheit, Datenschutz und Privatsphäre behalten wollte, verwende ich für das Login am git Host natürlich eine Authentisierung mittels PKI.
Bis heute, denn plötzlich ging diese nicht mehr. Nach Eingabe des Passwortes (ja, das braucht man immer noch, da ich meinen Schlüssel natürlich mittels selbigen zusätzlich absicherte – dafür kann der selbe Schlüssel sicher auf beliebig vielen Hosts verwendet werden) erhielt ich immer wieder die Fehlermeldung „Invalid key length“ und die Authentisierung verlangte nach meinem Hostlogin Passwort.
Zuerst dachte ich etwa, mein privater Schlüssel wäre aus welchem Grund auch immer beschädigt worden, soll ja manchmal bei Systemupdates vorkommen. Die Datei ~/.ssh/id_rsa (privater Schlüssel) sah aber völlig ok aus, auch ein cat auf selbiges verriet nichts Ungewöhnliches.
Die Länge machts…
Also startete ich die Recherche im Internet. Durch Google findet man zu Hauf Links mit dem Problem, die aber alle mehr oder weniger falsch abbogen. Schließlich widmete ich mich nochmals meinem privaten Schlüssel. Das Kommando
openssl rsa -text -noout -in ~/.ssh/id_rsa
liefert eine genaue Analyse und Darstellung des Schlüsselinhalts. Tatsächlich wird der base64 codierte Inhalt decodiert und as Ergebnis gemäß ASN.1 interpretiert und schließlich menschlich leserlich am Bildschirm als Hexadezimal Zahlen ausgeben. Der wirklich interessante Teil der Information steht dabei gleich auf der ersten Zeile:
Private-Key: (1023 bit)
modulus:
00:b7:97:39:...
Mein privater Schlüssel ist also exakt 1023 Bit lang. Das machte mich sofort stutzig. Erstens, weil dies genau 2^10-1 entsprach. Das Binärsystem ist in der EDV essentiell, 1024 ist die 10. Exponentialzahl, als IT Techniker weiß man sowas die ersten 16 Zahlen der Exponentialreihe auswendig. Aber ungerade ist schlecht, sehr schlecht.
Trotzdem, bis dato hat es funktioniert und die Datei wurde laut Inode Information seit Jahren nicht verändert (und hier vertraue ich dem Unix Unterbau von macOS deutlich mehr, als jedem Windows).
Wie sich nach weiterer Recherche herausstellte, kann beim RSA Verfahren durch das MSB tatsächlich auch beim Erzeugen eines 1024 Bit starken Schlüsselpaares ein Schlüssel mit nur effektiv 1023 Bit generiert werden. Dieser ist trotzdem syntaktisch richtig und die Ver- und Entschlüsselung funktioniert auch korrekt.
Versteckte neue Systembibliotheken
Wieso funktionierte es noch immer nicht? Die Fehlermeldung „Invalid key length“ deutete schon in die richtige Richtung. Die Releasenotes des macOS Upgrades geben keinen eindeutigen Hinweis, aber es wurde zumindest bei einem für dieses Problem relevanten Subsystem openSSL etwas verändert. Das Kommando
ssh- V
gibt die relevanten Versionsinformationen aus:
OpenSSH_7.6p1, LibreSSL 2.6.2
Gleich mit der ersten Information läßt sich was anfangen. Dank Google findet mal schnell die zughörigen Releasenotes vom 03. Oktober 2017. Folgende Zeile sagt bereits mehr als tausend Worte:
* Refuse RSA keys <1024 bits in length and improve reporting for keys that do not meet this requirement.
Und genau hier liegt der Hund begraben. Grundsätzlich ist das ja eine willkommene, sicherheitsrelevante Entscheidung die Minimumlänge des Schlüssel von zuvor 768 auf nun 1024 Bit zu erhöhen. Zudem wurde dies bereits mehrmals in den Releasenotes der Vorversionen angekündigt. Und eigentlich wäre das auch bei mir kein Problem gewesen, denn ich hatte ja grundsätzlich bei der Schlüsselerzeugung die korrekte Wunschlänge angegeben. Nur eben nicht überprüft, ob es auch tatsächlich so erzeugt wurde…
Lösung
Man generiert schlicht ein neues Schlüsselpaar, das sicher lange genug ist und kopiert den öffentlichen Schlüssel auf den Zielhost, etwa durch:
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
ssh-copy-id -i ~/.ssh/id_rsa.pub user@remote-system
Alternativ kann man das openSSL Package im Source runterladen, die entsprechende Konstante der SSH_RSA_MINIMUM_MODULUS_SIZE im ssh.h ändern und neu kompilieren.
Tipps
- Möglichst lange Schlüsselpaare erzeugen. Es gibt eigentlich heute keinen Grund mehr, nicht mindestens 2k oder 4k lange Schlüssel zu verwenden; Moderne Hosts schaffen die notwendige Berechnungen in Sekundenbruchteilen.
- Stets prüfen, ob das verwendete Programm auch korrekt lange Schlüsselpaare erzeugt hat.