[Fli4l_dev] ssh-login mit public/private key - file format error beim private key file

[Hans Bachner]

Hallo Alex,

danke für deine ausführlichen Vorschläge! Inzwischen hatte ich Zeit, 
mich mit dem Thema noch einmal genauer zu befassen.

tl;dr
Das Login über ein Schlüsselpaar funktioniert, wenn ich den public key 
in der Variablen SSHD_PUBLIC_KEY_x eintrage. Der Inhalt des 
SSHD_PUBLIC_KEYFILE_x wird anscheinend falsch interpretiert.

Die Details dazu stehen bei deinen Kommentaren.

Alexander Dahl schrieb am 08.12.2019 um 09:08:
> Hallo Hans,
> 
> Hans Bachner schrieb Samstag,  7. Dezember 2019, 15:45 (CET):
>> Ich habe mit PuTTYgen ein Schlüsselpaar erzeugt, den public key in
>> <config>/etc/ssh/ hinterlegt, als SSHD_PUBLIC_KEYFILE eingetragen und
>> erfolgreich zum Router übertragen. Dort taucht er auch in
>> /etc/ssh/authorized_keys auf, der Text sieht identisch zu dem im
>> PuTTYgen Fenster aus.
> 
> Gut.
> 
>> Nur funktioniert das Login per Schlüssel nicht.
>>
>> Wenn ich in mkfli4 fürs Remote Update den privaten Schlüssel (.ppk)
>> eintrage, erhalte ich beim SCP die Meldung:
>>> Unable to load private key file "<kompletter Pfad zum .ppk>" (file format error)
>> und werde nach dem Passwort gefragt.
> 
> Mit mkfli4l unter Windows kenne ich mich nicht aus, aber offenbar
> erwartet er hier den private Key im PuTTY-Format.

Ja, offensichtlich. Ich habe ihn aber ohnehin mit PuTTYgen erzeugt.

> Hast Du mal versucht den nicht da einzutragen sondern mit pageant zu
> laden? Das ist der SSH-Agent von PuTTY, damit brauch man nicht ständig
> sein Passwort neu eingeben und dann auch in PuTTY o.ä. nicht extra eine
> .ppk-Datei angeben.

Ich verwende den Pageant. Wenn ich aber in mkflil keinen private key 
angebe, fragt mich der Build-Prozess, ob er das Passwort aus der 
base.txt verwenden soll. Ablehnen und auch kein Passwort im folgenden 
Dialog eingeben führt zum Abbruch.

Wenn ich die private key Datei (.ppk) angebe, sieht das 
Filetransfer-Fenster des Build-Prozesses jetzt (mit dem richtigen pubic 
key auf dem fli4l) so aus:

> SCP-Transfer
> ============
> 
> to: flitest
> 
> Unable to load private key file "<kompletter Pfad und Dateiname>"  (file format error)
> boot.msg                  | 0 kB |   0.5 kB/s | ETA: 00:00:00 | 100%
> boot_s.msg                | 0 kB |   0.1 kB/s | ETA: 00:00:00 | 100%
> boot_z.msg                | 0 kB |   0.1 kB/s | ETA: 00:00:00 | 100%
> kernel                    | 408 kB | 408.0 kB/s | ETA: 00:00:04 |  17%
> [...]
usw. (auch die übrigen Dateien werden übertragen).

Mit dem key file hat er offenbar nach wie vor Probleme, mit der im 
Pageant hinterlegten Kopie kann sich der Build Prozess aber offenbar 
anmelden.

>> Außerdem habe ich in PuTTY eine SSH-Verbindung definiert, die ebenfalls
>> diesen .ppk verwenden soll. Die Definition ist identisch zu einigen
>> anderen vordefinierten Verbindungen zu verschiedenen Rechnern mit
>> CentOS, RHEL und OpenVMS, die allesamt einwandfrei funktionieren. Öffne
>> ich die Verbindung zum fli4l, werde ich nach dem Benutzernamen sofort um
>> das Passwort gefragt.
>>
>> Starte ich auf dem Router den Dropbear mit
>>      dropbear -s -p 22
>> (entspricht ALLOWPASSWORDLOGIN='no'), erhalte ich beim Login versuch die
>> M;eldung, dass kein gemeinsames Authentifizierungsverfahren gefunden
>> wird mit der Anmerkung "(server sent public key)" (zumindest sinngemäß).
> 
> Ja, das ist eine interessante Meldung. Möglicherweise können sich hier
> Client und Server nicht einigen, weil die Sets unterstützter
> Auth-Verfahrung disjunkt sind. Das einfachste, was Du hier probieren
> kannst: die neueste PuTTY-Version installieren. (Das ist sowieso zu
> empfehlen.)

Das scheint daran zu liegen, dass der im .pub File übertragene Schlüssel 
auf dem fli4l in authorized_keys falsch eingetragen wird.

PuTTY ist auf dem aktuellen Stand (0.73).

Ich habe versuchsweise den gleichen public key zweimal auf den fli4l 
übertragen: einmal in SSHD_PUBLIC_KEY_x und einmal als 
SSHD_PUBLIC_KEYFILE_x.

Nach dem Reboot sieht die /.ssh/authorized_keys so aus:

> flitest 4.0.0-r55209-testing # cat /.ssh/authorized_keys
> ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoY[...]QSbVkaWO4A= ecdsa-key-fli at home
> ssh-dss AAAAE2VjZHNhLXNoY[...]QSbVkaWO4A=
> flitest 4.0.0-r55209-testing #

d.h. der als Datei übertragene public key wird als ssh-dss Schlüssel 
eingetragen anstatt als ecdsa-sha2-nistp256! Muss man den Schlüsseltyp 
noch irgendwo extra definieren? Oder sollte ich für dieses Verhalten ein 
Ticket im Bugtracker öffnen?

>> Im syslog finde ich keinerlei Hinweise auf Loginversuche mit einem
>> Schlüssel, nur die üblichen "Password auth succeeded" Meldungen nach
>> einem erfolgreichen Login per Passwort.
> 
> Bin nicht sicher, ob man den dropbear dazu bringen kann, mehr zu loggen.
> Ich würde da eher auf Client-Seite ansetzen. Mit OpenSSH macht man da
> einfach `ssh -v …` und mit PuTTY gibt es bestimmt auch eine Möglichkeit
> genauere Meldungen auszugeben?

Ja, das geht - bei den Logging Einstellungen kann man auch SSH Pakete 
(und sogar die darin enthaltenen Rohdaten) mitloggen.

>> Was kann die Ursache für dieses eigenartige Verhalten sein?
> 
> Wie gesagt, das eine, was von Client und Server unterstützt werden muss
> ist das eigentliche Verschlüsselungsverfahren, da gehe ich aber davon
> aus, dass PuTTY da immernoch RSA-Keys erzeugt, die unterstützt der
> dropbear ziemlich sicher. Finger weg von DSA. ECDSA macht der dropbear
> auch, das noch recht neue ed25519 noch nicht. Aber das ist nur die
> Verschlüsselung. Die Authentifizierung läuft über andere Verfahren. Da
> sagt mir bspw. `ssh -v …` zu meinem fli4l, dass auch SHA-256 mit im
> Spiel ist.

Ja, sieht hier auch so aus (im PuTTY-Log).

> Es kann gut sein, dass bspw. ein alter fli4l 3.10 mit Deinem PuTTY noch
> geht, ein 4.0 mit aktualisiertem dropbear und neuen Settings für den
> aber nicht. Das ist quasi ein Sicherheitsfeature, im SSH-Server wurden
> vermutlich ältere Verfahren abgeschaltet und nur noch neuere Verfahren
> erlaubt.

Das war jedenfalls nicht der Grund für das Problem - der Typ des per 
File übertragenen public keys wurde in authorized_keys falsch 
eingetragen und passte daher nicht mehr zum private key.

Jedenfalls vielen Dank für deine Denkanstösse! Sie haben meine weiteren 
Nachforschungen sehr erleichtert.

Schöne Grüße,
Hans.