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

[Hans Bachner]

Hallo Alex,

Alexander Dahl schrieb am 10.12.2019 um 08:41:
> Hallo Hans,
> 
> Hans Bachner schrieb Dienstag, 10. Dezember 2019, 00:21 (CET):
>> Ich nehme einmal dein P.S. vorweg:
>>> P.S.: ich empfehle einfach mal den Code in rc460.dropbear zu lesen und zu
>>> verstehen ;)
>> Genau das hab ich die letzten Tage schon getan, sonst wär ich erst gar
>> nicht so weit gekommen.
> 
> Danke, dass Du da auch genauer rein schaust. :-)

Aber gerne doch - hilft enorm, wenn etwas nicht so tut wie erwartet :-)

>>>>>>> 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.
>>>
>>> das Programm pscp.exe das durch mkfli4l aufgerufen wird erwartet nicht das
>>> binäre ppk Format sondern das PEM Format das so aussieht:
>>> -----BEGIN RSA PRIVATE KEY-----
>>> ....
>>> ....
>>> ....
>>> -----END RSA PRIVATE KEY-----
>>
>> Da pscp.exe (und plink.exe) aus dem sshd-Paket von PuTTY kommen, würde
>> es mich doch sehr wundern, wenn dieses Programm keine .ppk Files
>> verstehen würde.
>>
>> Ich habe es auf der Befehlszeile auch getestet (mit pscp -v) und
>> festgestellt, dass das im Prinzip auch einwandfrei funktioniert.
>>
>> ABER: die mit fli4l mitgelieferten pscp.exe und plink.exe stammen von
>> PuTTY v0.62 (aus dem Jahr 2013). Diese Version unterstützt halt das
>> ecdsa Verfahren noch nicht und bemängelt daher einen "file format error".
> 
> Wenn fli4l da ein altes plink und pscp mitliefert, dann sollten die auf
> jeden Fall aktualisiert werden und dafür kann man sicher ein Ticket
> aufmachen, sowas würde ich sogar auch noch für 3.10 fixen und nicht nur
> für 4.0, das ist ggf. sicherheitsrelevant.

Danke an Peter fürs Ticket, um das er sich auch gleich selber gekümmert hat!

> Ansonsten scheint mir auch ein Review der dropbear-Skripte keine
> schlechte Idee zu sein. Ich habe bei mir folgenden Key eingetragen und
> das funktioniert, von daher bin ich etwas irritiert:
> 
> ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBCcJuPA33Rf1XUidFB8mYiEn5PMd/Ajs2Mg3fydsDcqMVwxiCfQ261esyGL9cvY3NodPEFZWEqs1KxdKNDnIAy8= alex at lemmy

Naja - wenn ich den Key so als SSHD_PUBLIC_KEY eintrage, funktioniert es 
bei mir auch - der wird 1:1 in authorized_keys kopiert. Wenn ich einen 
derartigen Schlüssel aber als SSHD_PUBLIC_KEYFILE übertrage (der vom 
Aufbau her ja etwas anders aussieht, nur der Schlüssel selbst ist 
natürlich identisch), wird er mit dem falschen Schlüsseltyp übertragen.

Vielleicht kann sich die Skripte jemand genauer ansehen, der besser mit 
der Materie vertraut ist.

Danke + schöne Grüße,
Hans.

> Verbinde mich allerdings auch von Linux aus mit OpenSSH und nicht mit
> PuTTY.
> 
> Grüße
> Alex
>