{PLI-garnet} Heeft iemand RSA/DSA keys en dropbear werkend?

[Gast]

De key moet op een enkele tekstregel staan, en de file moet in UNIX text formaat blijven. "cat" via een telnet/ssh sessie is dus de veiligste optie, dan is het zeker goed. In PuTTY doe je gewoon "cat > ~/.ssh/authorized_keys" en met de rechtermuisknop paste je dan de public key regel naar de terminal. Dan op ENTER en CTRL-D drukken (einde file).

[rongogo]

P.s.

Pli heeft ook nano als editor.

"^" Betekent Ctrl

 

 

grtzz RGG

[koekjedebij]

Nu met Helenite heb ik weer problemen hiermee.

ook een 1024bits key werkt dit keer niet meer (als ik exact dezelfde key in bijvoorbeeld openslug gebruik werkt ie wel, voorheen deed dezelfde key het zowel in openslug als dreambox-busybox).

Code:

mauce@laptopcmg ~ # ssh root@dreambox -vvvOpenSSH_4.3p2 Debian-5ubuntu1, OpenSSL 0.9.8b 04 May 2006debug1: Reading configuration data /etc/ssh/ssh_configdebug1: Applying options for *debug2: ssh_connect: needpriv 0debug1: Connecting to dreambox [192.168.175.106] port 22.debug1: Connection established...............................debug3: check_host_in_hostfile: filename /home/mauce/.ssh/known_hostsdebug3: check_host_in_hostfile: match line 3debug3: check_host_in_hostfile: filename /home/mauce/.ssh/known_hostsdebug3: check_host_in_hostfile: match line 4debug1: Host 'dreambox' is known and matches the RSA host key.debug1: Found key in /home/mauce/.ssh/known_hosts:3debug2: bits set: 502/1024debug1: ssh_rsa_verify: signature correctdebug2: kex_derive_keysdebug2: set_newkeys: mode 1debug1: SSH2_MSG_NEWKEYS sentdebug1: expecting SSH2_MSG_NEWKEYSdebug2: set_newkeys: mode 0debug1: SSH2_MSG_NEWKEYS receiveddebug1: SSH2_MSG_SERVICE_REQUEST sentdebug2: service_accept: ssh-userauthdebug1: SSH2_MSG_SERVICE_ACCEPT receiveddebug2: key: /home/mauce/.ssh/identity ((nil))debug2: key: /home/mauce/.ssh/id_rsa (0x8097488)debug2: key: /home/mauce/.ssh/id_dsa ((nil))debug1: Authentications that can continue: publickey,passworddebug3: start over, passed a different list publickey,passworddebug3: preferred publickey,keyboard-interactive,passworddebug3: authmethod_lookup publickeydebug3: remaining preferred: keyboard-interactive,passworddebug3: authmethod_is_enabled publickeydebug1: Next authentication method: publickeydebug1: Trying private key: /home/mauce/.ssh/identitydebug3: no such identity: /home/mauce/.ssh/identitydebug1: Offering public key: /home/mauce/.ssh/id_rsadebug3: send_pubkey_testdebug2: we sent a publickey packet, wait for replydebug1: Authentications that can continue: publickey,passworddebug1: Trying private key: /home/mauce/.ssh/id_dsadebug3: no such identity: /home/mauce/.ssh/id_dsadebug2: we did not send a packet, disable methoddebug3: authmethod_lookup passworddebug3: remaining preferred: ,passworddebug3: authmethod_is_enabled passworddebug1: Next authentication method: passwordroot@dreambox's password:

 

Hij probeert het wel, maar de dreambox lijkt geen respons te geven....

[Gast]

Citaat:

Nu met Helenite heb ik weer problemen hiermee.
ook een 1024bits key werkt dit keer niet meer (als ik exact dezelfde key in bijvoorbeeld openslug gebruik werkt ie wel, voorheen deed dezelfde key het zowel in openslug als dreambox-busybox).

ssh is dropbear, geen busybox.
En de dropbear versie is voor zover ik weet niet veranderd.
We zullen even kijken wat er mis kan zijn.

[koekjedebij]

Citaat:

Citaat:

Nu met Helenite heb ik weer problemen hiermee.
ook een 1024bits key werkt dit keer niet meer (als ik exact dezelfde key in bijvoorbeeld openslug gebruik werkt ie wel, voorheen deed dezelfde key het zowel in openslug als dreambox-busybox).

ssh is dropbear, geen busybox.
En de dropbear versie is voor zover ik weet niet veranderd.
We zullen even kijken wat er mis kan zijn.

Dat bedoelde ik idd ook, sorry.
Ik bedoelde aan te geven dat de key die eerst op zowel mijn nslu2 als op de dreambox werkte nu in Helenite niet meer werkt . Dat ie het nog wel op de nslu2 doet geeft aan dat de key goed is.
Overigens heb ik zowel rsa1 rsa2 als dsa geprobeerd (nieuwe keys aangemaakt) en voor alle gevallen hetzelfde resultaat.
Alvast bedankt voor de moeite!!

[Gast]

hier werkt het nog wel.

/home/root/.ssh directory aangemaakt, rechten 700

dsa key (1024bits?) lang geleden op de pc aangemaakt, id_dsa.pub gecopieerd naar /home/root/.ssh/authorized_keys op de box.

/etc/passwd root passwd op * gezet, of met passwd ingesteld (leeg laten werkt niet, dan mag je ook niet inloggen met een key)

 

En dan werkt het.

Op de box staat dropbear versie 0.48, volgens mij dezelfde als Garnet.

[Gast]

Oja authorized_keys rechten 600, maar volgens mij concludeerden we een vorige keer al dat dropbear niet zo strict is wat de rechten betreft van de .ssh directory en z'n inhoud.

[NetWave]

@mauce, verander de permissions van /home/root eens naar 700 (chmod 700 /home/root). De default waarde voor die dir is 755 en het lijkt er op dat dropbear dat niet wil.

Hier (DM7020 + Helenite) werkte het na deze verandering.

 

De permissions voor ~/.ssh en ~/.ssh/authorized_keys lijken niet van belang te zijn.

[koekjedebij]

Citaat:

@mauce, verander de permissions van /home/root eens naar 700 (chmod 700 /home/root). De default waarde voor die dir is 755 en het lijkt er op dat dropbear dat niet wil.
Hier (DM7020 + Helenite) werkte het na deze verandering.

De permissions voor ~/.ssh en ~/.ssh/authorized_keys lijken niet van belang te zijn.

Yes!!! goed gezien! nu werkt het.
Jammer dat in de diepste debug info van de ssh sessie dat niet terug te vinden is.
Aan de andere kant gelukkig dat er altijd oplettende mensen zijn die bereid zijn mee te denken en een oplossing met de rest te delen.

fenks again!

Aan pieterg dan de vraag of hij dit verschil in permissions van /home/root terug kan vinden in de source van Garnet en Helenite. Misschien iets om even rekening mee te houden in de volgende pli-image.

[NetWave]

Citaat:

Jammer dat in de diepste debug info van de ssh sessie dat niet terug te vinden is.

Klopt. Ik heb strace (IPKG download) gebruikt voor het traceren van het probleem, daarmee zag ik dat er een 'stat' gedaan werd op /home/root.

Vreemd is wel dat als je de file permissions terug op 755 zet, nadat het een keer gewerkt heeft, het probleem niet terug komt. Misschien dat het weer terugkomt na een reboot, maar dat heb ik niet geprobeerd.

[Gast]

/home/root permissies zijn altijd 755 geweest, en zijn het bij mij nu ook nog:

 

Code:

root@dm7020 ~ # ls -lad /home/rootdrwxr-xr-x    3 root     root            0 Apr 19 01:09 /home/root/

 

Dus dat kan volgens mij niet de echte oorzaak van je probleem zijn.

[koekjedebij]

Citaat:

/home/root permissies zijn altijd 755 geweest, en zijn het bij mij nu ook nog:

Code:

root@dm7020 ~ # ls -lad /home/rootdrwxr-xr-x    3 root     root            0 Apr 19 01:09 /home/root/

Dus dat kan volgens mij niet de echte oorzaak van je probleem zijn.

Toch heeft het veranderen van de permissies van deze homedir in 700 het probleem voor mij wel opgelost (ik heb in de tussentijd geen andere acties uitgevoerd).

Vaag.....

[koekjedebij]

als ik de permissies weer terug zet op 755 komt het probleem ook hier niet terug (ook niet na een reboot).

het lijkt erop dat ie alleen de eerste keer wanneer die de key gebruikt kijkt naar de permissies en daarna niet meer.

 

nb: ik weet echt 100% zeker, dat ik voor de oplossing van NetWave geen tussentijdse andere acties heb ondernomen.

[Gast]

wat ik meestal doe, is ssh (of in dit geval dropbear) zelf de .ssh directory aan laten maken (door met de ssh client vanaf de box in te loggen op een ander station).

Dat garandeert dat alle permissies precies zo staan als dropbear wil.

Misschien dat de zaak wat complexer is, en dat de homedir permissies gaan meespelen als de .ssh permissies wat te ruim zijn.

En dat dropbear de .ssh permissies automatisch corrigeert als je de eerste keer inlogt.

Ik verzin maar iets ;-)

[koekjedebij]

Citaat:

wat ik meestal doe, is ssh (of in dit geval dropbear) zelf de .ssh directory aan laten maken (door met de ssh client vanaf de box in te loggen op een ander station).
Dat garandeert dat alle permissies precies zo staan als dropbear wil.
Misschien dat de zaak wat complexer is, en dat de homedir permissies gaan meespelen als de .ssh permissies wat te ruim zijn.
En dat dropbear de .ssh permissies automatisch corrigeert als je de eerste keer inlogt.
Ik verzin maar iets ;-)

Hmmm ik ben nog op geen enkele unix-variant tegengekomen dat een entiteit zelf de permissies van ~/.ssh of ~/.ssh/* aangepast heeft. Voor zover ik weer wordt gewoon de umask toegepast.
Maar in de meeste gevallen gaat het dan om openssh. Ook in openslug gebruik ik openssh.
Wellicht dat dropbear op dit punt inderdaad afwijkt.
Ik kan alleen wel met zekerheid zeggen dat in dit geval de permissies van ~/.ssh en ~/.ssh/* niet (door dropbear) zijn gewijzigd.

Nu wordt het nog gekker:

Eerst mv ik de .ssh op de dreambox naar .ssh.old:

Code:

root@dm7020 ~ # mv .ssh .ssh.orgroot@dm7020 ~ # ls -lart-rwxr-xr-x    1 root     root          372 Jan  1  1970 .profile*drwxrwxr-x    3 root     root            0 Jan  1  1970 ../-rw-r--r--    1 root     root           79 Apr 18 15:08 .bashrcdrwx------    2 root     root            0 Apr 19 11:24 .ssh.org/-rw-r--r--    1 root     root         1878 Apr 19 17:02 .ash_historydrwxr-xr-x    4 root     root            0 Apr 19 17:12 ./drwxr-xr-x    2 root     root            0 Apr 19 17:13 .mc/root@dm7020 ~ # mkdir .sshroot@dm7020 ~ #  

Daarna upload ik de ssh-key weer opnieuw:

Code:

mauce@laptopcmg ~ # cat .ssh/id_dsa.pub | ssh root@dreambox  "cat - > .ssh/authorized_keys"root@dreambox's password:sh: cannot create .ssh/authorized_keys: Directory nonexistentRead from remote host dreambox: Connection reset by peer[edit]tussen deze stappen heb ik op de dreambox 'mkdir ~/.ssh' uitgevoerd[/edit]mauce@laptopcmg ~ # cat .ssh/id_dsa.pub | ssh root@dreambox  "cat - > .ssh/authorized_keys"root@dreambox's password:mauce@laptopcmg ~ # ssh root@dreamboxroot@dm7020 ~ #           

Zoals je ziet blijft het dan ook gewoon werken.

't moe nie gekku woddu.....

Hoe het nou precies zit zal misschien wel een raadsel blijven, echter deze workaround werkt in ieder geval goed.