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

[lespocky at gmail.com]

Hallo Hans,

Am Montag, 9. Dezember 2019 01:42:26 UTC+1 schrieb Hans Bachner:
> 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.

Autsch'n.

> 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.

Das sieht mir irgendwie nach einem Problem mit mkfli4l unter Windows aus. Da kann ich weiter nichts zu sagen.

> >> 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?

Urgs. Ja bitte. Das sollten wir mal versuchen nachzustellen. Und in Deiner Datei SSHD_PUBLIC_KEYFILE_x steht wirklich was anderes als nachher auf dem fli4l? Ich nehme an, Du hast da nichts drin editiert?

> 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.

Das kann ja nur sein, wenn irgendwer oder -was das geändert hat. Mich wundert das, weil ich davon ausgegangen wäre, dass das unverändert übernommen wird.

Grüße
Alex