SSH: private/public key, Login ohne Passwort

[jfkdlsa]

Hallo,

ich versuche nun schon etwas länger mit einer Fritz! 7050 auf meinen Debian server ohne Eingabe eines Passwortes zu connecten. Dabei habe ich nun schon herausgefunden, dass der Freetz mod schonmal RSA und DSS schlüssel automatisch in /tmp/flash/xxx_host_key anlegt. um von diesen private keys nun einen public zu bekommen, habe ich

dropbearkey -f /tmp/flash/rsa_host_key -y

aufgerufen, was ja dann im terminal den public key liefert.
Wenn ich diesen public key nun in die authorized_keys von meinem laptop, oder dem server einbinde, und versuche per SSh ohne passwort zu connecten, kommt immer wieder der passwort prompt.
ich habe es schon mit 2 anderen computern untereinander probiert, und es geht, sogar der zugriff AUF die fritz ohne passwort geht, wenn man die entprechenden keys vorher eingebunden hat.

was ich mit dem ganzen vorhabe?
ich würde gerne ein skript haben, was meinen server per SSH runterfährt, und zwar von der fritz aus. diese will ich dann im callmonitor einbinden und dann je nach status den server starten oder runter fahren.

ich habe bis jetzt keinerlei hilfe zu dropbear gefunden, die auf die config eingeht, da ich denke, dass es an der konfiguration liegt.

vielleicht hat ja schonmal jemand vor dem selben problem gestanden

gruß

 

[olistudent]

Hi.
Die Einrichtung der Schlüssel hat nichts mit Freetz zu tun. Da solche Fragen immer wieder kommen haben wir im Wiki einen Abschnitt dazu.

MfG Oliver

 

[jfkdlsa]

danke schonmal für die antwort.

aber dort im Wiki ist genau NICHT mein szenario, also Fritz ---> Debian server über eine host-based authentication - was grundsätzlich ja nicht verschieden ist vom anderen weg. zumindest sollte es das nicht.

könnte das vielleicht jemand bei sich testen, also mit Freetz & Dropbear auf einen anderen pc zugreifen? selbst der SSH log auf dem server gibt keinerlei rückmeldung, warum es nicht läuft.

gruß

 

[jfkdlsa]

ok, problem gelöst.
man muss den SSH client folgendermaßen aufrufen, damit er auch das richtige identity file der fritz mitnimmt

ssh -i /tmp/flash/rsa_host_key [email protected]

oder halt dorthin verweisen, wo man den RSA/DSS key erstellt hat. weiterhin muss man dann noch den public key der fritz, wie oben beschrieben, in die authorized_keys datei des jeweiligen anderen rechners verschieben. so kann man dann endlich per SSH von der fritz auf andere rechner zugreifen mittels host-based authentication.

 

[wengi]

Hi,

das ist bei jedem anderen System genauso. Hat mit freetz nichts zu tun.
Und wenn Du das Identfile im home-verzeichnis unter .ssh hast brauchst Du es auch nicht angeben....

wengi

 

[ao]

@jfkdlsa: Schreib doch Deine o.g. Lösung ins Wiki rein, dann haben alle etwas davon.

 

[jfkdlsa]

ich habe im man nachgelesen, dass ssh per default im ~/.ssh nachschaut und dann auch noch bestimmte dateinamen erwartet.
deswegen muss man bei der standardinstallation von freetz hier nachhelfen, insofern man nicht eigene keys anlegt die dem entsprechen was ssh erwartet.

 

[olistudent]

Normalerweise wird aber von /mod/root/.ssh auf das Keyfile verlinkt. Daher versteh ich nicht warum man das extra angeben muss. Evtl. müssen wir doch was am dropbear anpassen.

MfG Oliver

 

[jfkdlsa]

@olistudent
der symlink stimmt, das problem sind die name der identitäten, und zwar als 'id_rsa' und 'id_dss'. nicht rsa_host_key

edit:

ich habe gerade mal mit ein paar symlinks rumgespielt, aber nichts hat geholfen. bis jetzt funktioniert bei mir nur der weg über ssh -i uinter der angabe des key files in /tmp/flash/

 

[RalfFriedl]

Schau doch mal mit "strace -efele ssh ..." nach, welche Dateien gesucht werden.

 

[olistudent]

Sieht für mich so aus als ob ssh (dbclient) ohne Parameter nicht nach einem "identity file" sucht. Wobei das auch schon im Wiki steht wie ich gerade sehe. Aber von einem open(...id_rsa) hab ich nichts im trace gelesen.

MfG Oliver

 

[ao]

Hallo, ich hänge mich mal an diesen inzwischen älteren Thread, da ich ein ähnliches Problem habe.

Auf meiner Fritzbox mit Freetz-Mod läuft dropbear als SSH-Server, an dem man sich als root anmelden kann (User sind keine eingerichtet).
Mit ssh vom Mac OS X- oder Ubuntu-Terminal und PW klappt das, auch mittels putty unter Windows mit PW und auch mit einem key, aber leider nicht mit einem key unter Max OS X:

bash-3.2$ sudo ssh -vvv -i ~/.ssh/id_rsa root@xxx
OpenSSH_5.1p1, OpenSSL 0.9.7l 28 Sep 2006
debug1: Reading configuration data /etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to xxx [xxx.xxx.xxx.xxx] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug3: Not a RSA1 key file /Users/xxx/.ssh/id_rsa.
debug1: identity file /Users/xxx/.ssh/id_rsa type 1
debug1: Remote protocol version 2.0, remote software version dropbear_0.52
debug1: no match: dropbear_0.52
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: [EMAIL="aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr"]aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr[/EMAIL]
debug2: kex_parse_kexinit: [EMAIL="aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr"]aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr[/EMAIL]
debug2: kex_parse_kexinit: [EMAIL="hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96"]hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96[/EMAIL]
debug2: kex_parse_kexinit: [EMAIL="hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96"]hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96[/EMAIL]
debug2: kex_parse_kexinit: [EMAIL="none,[email protected],zlib"]none,[email protected],zlib[/EMAIL]
debug2: kex_parse_kexinit: [EMAIL="none,[email protected],zlib"]none,[email protected],zlib[/EMAIL]
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,3des-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes256-cbc,twofish256-cbc,twofish-cbc,twofish128-cbc,blowfish-cbc
debug2: kex_parse_kexinit: aes128-ctr,3des-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes256-cbc,twofish256-cbc,twofish-cbc,twofish128-cbc,blowfish-cbc
debug2: kex_parse_kexinit: hmac-sha1-96,hmac-sha1,hmac-md5
debug2: kex_parse_kexinit: hmac-sha1-96,hmac-sha1,hmac-md5
debug2: kex_parse_kexinit: [EMAIL="zlib,[email protected],none"]zlib,[email protected],none[/EMAIL]
debug2: kex_parse_kexinit: [EMAIL="zlib,[email protected],none"]zlib,[email protected],none[/EMAIL]
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug2: dh_gen_key: priv key bits set: 131/256
debug2: bits set: 516/1024
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug3: check_host_in_hostfile: filename /var/root/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug3: check_host_in_hostfile: filename /var/root/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug1: Host 'xxx' is known and matches the RSA host key.
debug1: Found key in /var/root/.ssh/known_hosts:1
debug2: bits set: 529/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /Users/xxx/.ssh/id_rsa (0xxxxxxxx)
debug2: key: /Users/xxx/.ssh/id_rsa (0xxxxxxxx)
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: /Users/xxx/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Offering public key: /Users/xxx/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 148
debug2: input_userauth_pk_ok: fp xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
debug3: sign_and_send_pubkey
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
debug2: bad passphrase given, try again...
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
debug2: bad passphrase given, try again...
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
debug2: bad passphrase given, try again...
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).
bash-3.2$

Ganz am Ende des obigen Logs sieht man, dass bei den Zeilen mit "PEM" nach der pass-phrase gefragt wurde, die den key zusätzlich schützt. D.h., es handelt sich bei der pass-phrase nicht um ein PW im herkömmlichen Sinne, sondern es verschlüsselt den key, damit dieser noch zusätzlich gesichert ist, falls z.B. das Medium (USB-Stick) mit dem key gestohlen wird.
Die Anmeldung mit demselben USB-Stick/key/pass-phrase funktioniert mit putty unter Windows.

Sieht jemand im o.g. Log evtl. noch ein Problem, welches dieses Fehl-Verhalten unter Max OS X erklärt?

Die Zugriffsrechte für ~/.ssh/ sind rw (chmod 600 .ssh) und der "Server" (Fritzbox mit dropbear) steht auch in known_hosts.

Danke für Eure Hilfe!

 

[RalfFriedl]

debug2: bad passphrase given, try again...

Das sieht doch nach einem Problem auf der Client-Seite aus.

Wie Du schon richtig schreibst, wird die passphrase verwendet, um den Key zu entschlüsseln. Die passiert auf dem Client. Wenn der Key nicht entschlüsselt werden kann, kann er auch nicht verwendet werden.

Gibt es einen speziellen Grund, warum Du die Konstruktion mit sudo verwendest?
Funktioniert es vom Mac auf irgend einen anderen SSH Server?

 

[ao]

Nun, ich denke inzwischen, dass das Problem darin liegt, dass der key für putty nicht kompatibel mit dem openssh key ist und es daher auch ein Problem mit der pass-phrase gibt.

Sorry, das mit sudo ist in der Tat überflüssig, ändert aber nichts daran.

Noch etwas, was mir nun auffällt:

Are you sure you want to continue connecting (yes/no)? yes
Failed to add the host to the list of known hosts (/Users/xxx/.ssh/known_hosts).

Wieso kann das nun nicht mehr aufgenommen werden? Die xxx stehen für meinen Usernamen auf dem client.
Die Datei .ssh hat die korrekten Rechte:

drw-------   6 xxx  xxx    204 11 Jan  2009 .ssh

Blöderweise kann ich auch mit "sudo; cd .ssh" vom normalen Nutzer-Account auf dem Macbook nicht rein, weil mein Nutzer-Account nicht in die sudoers eingetragen ist. Also hatte ich das Ganze anfangs vom Admin-Account des MB versucht (daher oben noch alles mit sudo), aber das tut hier eigentlich doch nichts zur Sache. Es bleibt aber die Frage, weshalb oben "Failed to add the host to the list of known hosts" kommt.

Später checke ich nochmal, ob die known_hosts evtl. falsche Rechte hat. Aber jetzt erst einmal Gute N8!

 

[RalfFriedl]

Bei Putty gibt es ein Programm puttygen. Dieses Programm kann nicht nur Keys erzeugen, es hat auch einen Menü-Punkt "Conversions".

 

[ao]

Danke, damit wird es funktionieren!