Publickey-Auth mit dropbear klappt nicht [Solved]

[Eruvaer]

Hi @ all,

habe auf meiner FritzBox 7270 dropbear installiert (über die cfg_dropbear von http://www.spblinux.de/fbox.new/), sonst aber keine mods drauf. Die Anmeldung über ein Passwort funktioniert einwandfrei. Jedoch schaffe ich es nicht, mich mit meinem RSA-Key (2048 bit mit Passphrase) zu authentifizieren.

Habe meine id_rsa.pub in die /var/tmp/.ssh/authorized_keys kopiert und /var/tmp/ als $HOME für root zugewiesen. Sobald ich mich mit ssh verbinde, fragt er mich nach meiner Passphrase. Gebe ich diese ein, verweigert er den Zugang jedoch:

eruvaer@gentoo-laptop ~/.ssh $ ssh -p 22 [email protected] -vvv
...
...
...
debug2: key: /home/eruvaer/.ssh/id_rsa (0x80a1688)
debug2: key: /home/eruvaer/.ssh/identity ((nil))
debug2: key: /home/eruvaer/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/eruvaer/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/eruvaer/.ssh/identity
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key '/home/eruvaer/.ssh/identity': 
debug1: read PEM private key done: type RSA
debug3: sign_and_send_pubkey
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/eruvaer/.ssh/id_dsa
debug3: no such identity: /home/eruvaer/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

Interessanterweise fragt er mich nur nach meiner Passphrase, wenn ich auf meinem lokalen PC in ~/.ssh/ den privaten Key 'identity' nenne; solange er 'id_rsa' heißt, fragt dropbear überhaupt nicht nach einer Passphrase. Habe auch testweise einen DSA-Key generiert und in die authorized_keys der FB geschrieben, jedoch mit gleichem Ergebnis. Bei anderen SSH-Servern funktioniert der RSA-Key problemlos.

Würde mich über Ideen freuen
Gruß Eruvaer

 

[RalfFriedl]

Habe /var/tmp/ als $HOME für root zugewiesen.

Was genau heißt das? Im Zweifelsfall hast Du das nicht wirklich gemacht.

... fragt dropbear überhaupt nicht nach einer Passphrase.

Diese Formulierung deutet darauf hin, daß Du gar nicht weißt, wie das mit den Public Keys funktioniert. Ein SSH-Server (hier dropbear) fragt Dich niemals nach einer Passphase.

 

[Eruvaer]

Was genau heißt das? Im Zweifelsfall hast Du das nicht wirklich gemacht.

Mein Eintrag in der /var/tmp/passwd für root lautet:

root:***:0:0:root:/var/tmp/:/bin/sh

*** steht hier für den Passworthash. Ein Softlink von /etc/passwd auf /var/tmp/passwd existiert.

Des weiteren erhalte ich in innerhalb einer ssh-sitzung:

# echo $HOME 
/var/tmp/

Diese Formulierung deutet darauf hin, daß Du gar nicht weißt, wie das mit den Public Keys funktioniert. Ein SSH-Server (hier dropbear) fragt Dich niemals nach einer Passphase.

Die Formulierung ist womöglich unglücklich, da die Abfrage wohl durch meinen openssh-clienten erfolgt. Das ändert jedoch nichts daran, dass der Server einmal den Clienten um Entschlüsselung des privaten Keys bittet und einmal nicht.

Weitere Ideen, was ich ausprobieren könnte?

 

[sf3978]

Eruvaer hat Folgendes geschrieben:

Hi @ all,

habe auf meiner FritzBox 7270 dropbear installiert (über die cfg_dropbear von http://www.spblinux.de/fbox.new/), sonst aber keine mods drauf. Die Anmeldung über ein Passwort funktioniert einwandfrei. Jedoch schaffe ich es nicht, mich mit meinem RSA-Key (2048 bit mit Passphrase) zu authentifizieren.

Habe meine id_rsa.pub in die /var/tmp/.ssh/authorized_keys kopiert und /var/tmp/ als $HOME für root zugewiesen. Sobald ich mich mit ssh verbinde, fragt er mich nach meiner Passphrase. Gebe ich diese ein, verweigert er den Zugang jedoch:
..................

Interessanterweise fragt er mich nur nach meiner Passphrase, wenn ich auf meinem lokalen PC in ~/.ssh/ den privaten Key 'identity' nenne; solange er 'id_rsa' heißt, fragt dropbear überhaupt nicht nach einer Passphrase. Habe auch testweise einen DSA-Key generiert und in die authorized_keys der FB geschrieben, jedoch mit gleichem Ergebnis. Bei anderen SSH-Servern funktioniert der RSA-Key problemlos.

Würde mich über Ideen freuen
Gruß Eruvaer

Diese Formulierung deutet darauf hin, daß Du gar nicht weißt, wie das mit den Public Keys funktioniert. Ein SSH-Server (hier dropbear) fragt Dich niemals nach einer Passphase.

Nein, er fragt nicht nach einer Passphase, sondern nach einer Passphrase (password).
Mein Dropbear (ssh-server) fragt auch nach einem password, also nach einer passphrase:

$ ssh -oPort=yyyyy [email protected]
[email protected]'s [COLOR="#ff0000"]password[/COLOR]:

Und lt. WIKIPEDIA ist passphrase = password/Passwort/Kennwort

@Eruvaer:
Ich weiß auch nicht wie Pubic Keys funktionieren und ich weiß auch nicht was eine passphase (ohne r) ist.

 

[RalfFriedl]

Ok, da fehlt ein r. Irgendwo in der Spaß-Abteilung kann man die auch kaufen.

Unabhängig davon wird das Paßwort für den Key immer vom Client angefordert, während das Paßwort für die normale Anmeldung (wie in Deinem Beispiel "[email protected]'s password") vom Server angefordert wird. Einer der wichtigen Unterschiede zwischen Anmeldung mit Paßwort oder mit Key ist, daß der Key im Gegensatz zum Paßwort niemals zum Server übertragen wird.

Die passwd oben sieht richtig aus, und eine Anmeldung mit Key funktioniert mit einem dropbear Server, zumindest bei Freetz.

Die Frage ist also, warum es hier nicht funktioniert. Es wäre denkbar, daß die Dateirechte für den Key zu großzügig sind und der Server die deswegen nicht verwendet. Auf jeden Fall wäre das protokoll vom Server interessant, nicht vom Client, denn der Client versucht es ja mit dem Key.

 

[Eruvaer]

Es wäre denkbar, daß die Dateirechte für den Key zu großzügig sind

'ls' sagt zu den Dateirechten folgendes:

drwx------    4 root     root            0 Dec 27 01:48 /var/tmp/
-rw-r--r--    1 root     root          157 Dec 22 06:16 /var/tmp/passwd
drwxr-xr-x    2 root     root            0 Dec 24 02:07 /var/tmp/.ssh/
-rw-------    1 root     root         1014 Dec 24 03:54 /var/tmp/.ssh/authorized_keys

Sieht für mich soweit in Ordnung aus.

Auf jeden Fall wäre das protokoll vom Server interessant

Dieses ist leider nicht gerade aussagekräftig; habe die Logs beim starten von dropbear

# dropbear -E -s -g >> /var/tmp/dropbear.info 2>> /var/tmp/dropbear.err

auf die stderr umgeleitet, da sagt er folgendes:

# tail /var/tmp/dropbear.err
...
[5600] Dec 29 03:16:08 Child connection from 192.168.0.5:33040
[5600] Dec 29 03:16:14 exit before auth (user 'root', 0 fails): Exited normally

Entsprechender ssh-Aufruf:
ssh [email protected] -vvv -i ./identity 
...
debug1: Authentications that can continue: publickey
debug1: Trying private key: ./identity
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key './identity': 
debug1: read PEM private key done: type RSA
debug3: sign_and_send_pubkey
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

Gibt es eine Möglichkeit, den verbose mode von dropbear zu erhöhen? Ist mal keine Option auf der manpage vermerkt.

Hoffe mal dass die Infos helfen.

Gruß Eruvaer

@ sf3978:
Nach RFC 4251 (http://www.rfc-editor.org/rfc/rfc4251.txt) heißt das "Passwort" für den private Key Passphrase, wohingegen das normale "Passwort" zum Anmelden auch Passwort heißt. Daher die Unterscheidung

 

[RalfFriedl]

An den Rechten sollte e snicht liegen, ich habe mal nachgeschaut, es geht auch mit Rechten 644 bzw. 755 für das Verzeichnis .ssh.

Sieht Deine Datei authorized_keys ungefähr so aus?

ssh-rsa AAAAB...

Paßt der Schlüssel in "identity" dazu? Es kann sein, daß dropbear nur Keys der Version 2 unterstützt, die üblicherweise in einer Datei "id_rsa" liegen, und "id_rsa.pub" für den öffentlichen Teil.

Keys der Version 1 verwende ich schon seit langem nicht mehr, und habe sie noch nie in Verbindung mit dropbear verwendet.

 

[Eruvaer]

Ja, die authorized_keys beginnt genau so, besteht nur aus einer Zeile und endet mit:

== {username}@{pc-name}

Sie ist auch identisch mit der authorized_keys auf Laptop und Desktop-PC, auf denen ich Publickey-Auth erfolgreich eingerichtet habe (habe einen private RSA v2 Key, den ich überall verwende).

Die Sache mit "identity" und "id_rsa" habe ich wohl etwas unklar formuliert. Den private Key habe ich mit ssh-keygen (default-settings) erstellt, also RSA Version2 und unter dem Namen '.ssh/id_rsa' bzw '.ssh/id_rsa.pub'. Die "id_rsa" habe ich testweise in "identity" umbenannt, um zu sehen ob es damit funktioniert. Wusste damals noch nicht, dass die "identity" für RSA v1 vorgesehen ist und das umbennen damit Unsinn. Jedenfalls klappt es mit der "id_rsa" trotzdem nicht mit Publickey-Auth. Ich starte ssh über:

$ ssh -vvv -i /home/eruvaer-ohta/.ssh/id_rsa [email protected]
...
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
  [hier fragt der Client nach der Passphrase für den private Key]
debug2: key: /home/eruvaer-ohta/.ssh/id_rsa (0x80a26f8)
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/eruvaer-ohta/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
[email protected]'s password:

Der dropbear log ist nach wie vor mager.

Habe auch testweise RSA v1 Keys generiert, hatte damit allerdings ebenfalls keinen Erfolg.

Danke schon mal für die Hilfe, hoffe mal dass sich noch eine Lösung findet.

 

[albern]

...
Den private Key habe ich mit ssh-keygen (default-settings) erstellt, also RSA Version2
...

Ich glaub', dropbear verlangt nach einem besonderem Schlüsselformat. Es gibt aber zusammen mit dropbear ein Konvertierungsprogramm (dropbearconvert?; bin nicht sicher), mit dem sich auch existierende OpenSSH-Schlüssel zurecht biegen lassen.
Vielleicht hilft das ...


LG

EDIT:
Meine Aussage scheint irrelevant, da wohl nur den dropbear-Client betreffend:
http://minimalinux.org/ttylinux/DocumentsV7.0/user_multi/node23.html

Vielleicht willst Du aber trotzdem mal einen Freetz-generierten Schlüssel testen?

 

[Eruvaer]

@ albern:

Hab schon mal mit dropbearconvert rumgespielt, allerdings ohne damit weiterzukommen; außerdem sollte, wie du ja schon bemerkt hast, der dropbear-Server nativ openssh-Schlüssel verwenden können.

Vielleicht willst Du aber trotzdem mal einen Freetz-generierten Schlüssel testen?

Wie genau meinst du das? Ich kann mit meinem dropbear nur host-Keys generieren. Gibts bei Freetz ein eigenes Programm zum generieren von Publickeys? Wenn ja, könntest du mir bitte zu Testzwecken damit ein public/private-Key-Paar erstellen und senden oder hier als Anhang reinstellen?

Gruß Eruvaer

 

[sf3978]

Sorry. Kann gelöscht werden.

 

[Eruvaer]

So, der Thread ist zwar schon unter einer dicken Staubschicht verschwunden, aber ich habe endlich eine Lösung gefunden, vll hilft es ja noch anderen . Ich beziehe mich hier auf eine FritzBox 7270 mit Stock-Firmware und dropbear-0.50 von spblinux (fbox.new/cfg_dropbear).

Das Problem war ja, dass dropbear keine public-keys akzeptiert hat und er die authorized_keys in /var/tmp einfach nicht verwenden wollte.

Die Lösung: dropbear greift auf /etc/dropbear/ zu, um die authorized_keys und den rsa_hostkey zu finden. Allerdings sind dort standardmäßig nur softlinks auf schreibgeschützte Dateien drin. Also habe ich den entsprechenden softlink entfernt und mit einem softlink auf meine eigene authorized_keys ersetzt:

rm /etc/dropbear/authorized_keys
cat /var/tmp/id_rsa.pub >> /var/tmp/authorized_keys
ln -s /var/tmp/authorized_keys /etc/dropbear/authorized_keys

Und siehe da, dropbear akzeptiert endlich meinen public key !