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

[Alexander Dahl]

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.

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.

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

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

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

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.

Wie gesagt, probier mal die neueste Version von PuTTY, da sehe ich gute
Chancen.

Grüße
Alex

-- 
***** http://blog.antiblau.de/ *****************************
GnuPG-FP: C28E E6B9 0263 95CF 8FAF  08FA 34AD CD00 7221 5CC6