[Linux] ssh probleempje linux <--> linux

[-W0kk3L-]

Howdi,

Ik heb een probleempje. Ik ben mijn ssh zooi aan het goedzetten. Als ik vanuit putty naar mijn linux bak ssh, dan kom ik er zonder pass op (zoals het hoort).

Als ik vanuit putty (met dezelfde loginnaam) naar een externe host ssh, dan kom ik er ook zonder pass op.

Als ik vervolgens vanuit mijn laptop naar die externe host ssh, dan krijg ik een login pass vraag voor me...

Ik heb de public key van mijn laptop geplaatst in de authorised_keys op de externe host. De rechten op die file staan goed (aangezien mijn putty het ook doet).

Ik heb even debugmode gedraaid voor ssh, en ik kom de volgende VERDACHTE melding tegen:

debug2: we did not send a packet, disable method
debug1: next auth method to try is keyboard-interactive

Weet iemand hier een oplossing voor? Ik wil dus ook vanaf mijn linux bak die externe host kunnen benaderen zonder pass....

[zomertje]

waarom zonder password, is het zo'n grote moeite om die even in te typen? Het is niet echt veilig om alles zonder password te doen lijkt me.

[fetcher]

zomertje schreef op 30 maart 2003 @ 09:18:
waarom zonder password, is het zo'n grote moeite om die even in te typen? Het is niet echt veilig om alles zonder password te doen lijkt me.

Bijvoorbeeld ter behoeve van scriptjes.

[Verwijderd]

Je geeft weinig info, kijk hier eens, hier is voor alle ssh en openssh versies het proces beschreven:

http://bumblebee.lcs.mit.edu/ssh2/

[-W0kk3L-]

zomertje schreef op 30 March 2003 @ 09:18:
waarom zonder password, is het zo'n grote moeite om die even in te typen? Het is niet echt veilig om alles zonder password te doen lijkt me.

Idd omwille van scripts. Het is heus niet een grote moeite om je password in te vullen, maar als je meerdere servers beheert is het veel handiger om gewoon in te kunnen loggen, zonder elke keer je pass in te geven.

Overigens is het via deze manier een stuk veiliger dan handmatig een pass intikken.

[-W0kk3L-]

Verwijderd schreef op 30 maart 2003 @ 09:42:
Je geeft weinig info, kijk hier eens, hier is voor alle ssh en openssh versies het proces beschreven:

http://bumblebee.lcs.mit.edu/ssh2/

Ik heb al deze stappen gevolgd, incl de chmod enz. Aangezien het via putty wel werkt, zegt iig dat de authorisaties goed staan. Enkel mijn laptop geef niet aan bij de remote host dat hij de RSA methode moet gebruiken..... Meer ideeen?

[-W0kk3L-]

Meer info nodig? geef maar aan wat jullie willen weten.....

[Verwijderd]

Staat in putty onder de 'ssh' settings de instellingen precies hetzelfde als je putty-pc? (er is bv in putty een optie voor die keyboard-interactive uit jouw debug).

[ Voor 10% gewijzigd door Verwijderd op 30-03-2003 10:33 ]

[-W0kk3L-]

alles in putty werkt goed. Overal kom ik MET PUTTY wel zonder pass in. Echter ssh'en (dus vanuit linux) naar een andere linux bak wil nie. Ik heb net eventjes vanaf de remote host naar mijn eigen bak ge-ssh'd, en dat gaat goed. Ook zonder pass.... dus ik heb het vermoedde dat het aan mijn SSH ligt (en niet aan sshd, en niet aan sshd van de remote host)

[-W0kk3L-]

Dit is wat ik krijg als ik probeer te ssh'en vanaf mijn linux bak naar de remote_host

$ ssh -vvv remote_host
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to remote_host [ip-adres] port 22.
debug1: Connection established.
debug1: identity file /home/userid/.ssh/identity type 0
debug1: identity file /home/userid/.ssh/id_rsa type -1
debug1: identity file /home/userid/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.5p1 FreeBSD-20030201
debug1: match: OpenSSH_3.5p1 FreeBSD-20030201 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.5p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[e-mail]
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[e-mail]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[e-mail],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[e-mail],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
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-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[e-mail]
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[e-mail]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[e-mail],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[e-mail],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 136/256
debug1: bits set: 1613/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/userid/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug3: check_host_in_hostfile: filename /home/userid/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug1: Host 'userid' is known and matches the DSA host key.
debug1: Found key in /home/userid/.ssh/known_hosts:1
debug1: bits set: 1615/3191
debug1: ssh_dss_verify: signature correct
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: next auth method to try is publickey
debug1: try privkey: /home/userid/.ssh/id_rsa
debug3: no such identity: /home/userid/.ssh/id_rsa
debug1: try privkey: /home/userid/.ssh/id_dsa
debug3: no such identity: /home/userid/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: next auth method to try is keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:

Suggesties?

[rig0r]

Hij kan blijkbaar je private key niet vinden (id_rsa), of er is iets mis mee qua content. Die moet ie wel hebben om in te kunnen loggen via public key authentication. (Net getest hier).
Anders ff opnieuw genereren.

[pinball]

-W0kk3L- schreef op 30 maart 2003 @ 10:05:
Overigens is het via deze manier een stuk veiliger dan handmatig een pass intikken.

offtopic:
Hoezo dat?
Volgens mij is het juist onveiliger omdat degene die nu je laptop root er meteen gratis een paar andere machines bij krijgt.

[-W0kk3L-]

Pinball schreef op 30 March 2003 @ 16:24:
[...]

offtopic:
Hoezo dat?
Volgens mij is het juist onveiliger omdat degene die nu je laptop root er meteen gratis een paar andere machines bij krijgt.

Dat zou kunnen...echter de laptop staat in mijn woonkamer, en mijn vrouw heeft geen flauw benul hoe linux werkt, dus ik denk dat ik me daar niet druk over hoef te maken

[-W0kk3L-]

rig0r schreef op 30 March 2003 @ 13:18:
Hij kan blijkbaar je private key niet vinden (id_rsa), of er is iets mis mee qua content. Die moet ie wel hebben om in te kunnen loggen via public key authentication. (Net getest hier).
Anders ff opnieuw genereren.

Ook opnieuw genereren heb ik uiteraard geprobeerd. Zonder succes. Dit is ECHT VAAG!

[zomertje]

-W0kk3L- schreef op 30 March 2003 @ 10:05:
[...]


Idd omwille van scripts. Het is heus niet een grote moeite om je password in te vullen, maar als je meerdere servers beheert is het veel handiger om gewoon in te kunnen loggen, zonder elke keer je pass in te geven.

Overigens is het via deze manier een stuk veiliger dan handmatig een pass intikken.

Ok, ikke snap. Had ik even niet aan gedacht

[DiedX]

Hoe staan de rechten op de id_dsa.ppk?

[-W0kk3L-]

DiedX schreef op 30 March 2003 @ 22:26:
Hoe staan de rechten op de id_dsa.ppk?

Waar moet die file staan? Ik heb em wel voor putty, maar daar werkt tie al.... maar voor Linux?

[DiedX]

Zo noem ik 'm meestal. Je hebt die public en private key. De private moet je aanroepen met ssh -i <key> <host>

[rig0r]

Staat de public key wel goed in de authorised_keys op de bak waar je heen wilt ?
Ik had een keer per ongeluk een newline er tussen staan

[Eärendil]

Pinball schreef op 30 March 2003 @ 16:24:
[...]

offtopic:
Hoezo dat?
Volgens mij is het juist onveiliger omdat degene die nu je laptop root er meteen gratis een paar andere machines bij krijgt.

Het is veiliger omdat een je je password nu niet aan een gespoofde ssh-server kan geven. Het is wel aan te raden een passphrase over de private key te zetten.
Dit staat allemaal uit gelegd op http://www.tartarus.org/~simon/puttydoc/Chapter8.html#8

[-W0kk3L-]

DiedX schreef op 31 maart 2003 @ 11:05:
Zo noem ik 'm meestal. Je hebt die public en private key. De private moet je aanroepen met ssh -i <key> <host>

uit ssh --help
-i file Identity for public key authentication (default: ~/.ssh/identity)

Deze file is aanwezig en staat goed (incl gechmod op 600).

[-W0kk3L-]

rig0r schreef op 31 March 2003 @ 12:40:
Staat de public key wel goed in de authorised_keys op de bak waar je heen wilt ?
Ik had een keer per ongeluk een newline er tussen staan

Ik heb em via diverse editors geopend. Vooral ee is daar makkelijk in. Die laat gewoon de regels in 1 lengte staan. En die staat erin zonder spaties of evt vreemde leestekens.

Als extra toevoeging. Zie ook 2 of 3 messages hoger. Daar kun je lezen dat ik hem zelfs al een keer opnieuw aangemaakt heb en hem opnieuw in authorized_keys gezet heb.

[ Voor 18% gewijzigd door -W0kk3L- op 31-03-2003 14:09 ]

[-W0kk3L-]

Eärendil schreef op 31 March 2003 @ 13:43:
[...]

Het is veiliger omdat een je je password nu niet aan een gespoofde ssh-server kan geven. Het is wel aan te raden een passphrase over de private key te zetten.
Dit staat allemaal uit gelegd op http://www.tartarus.org/~simon/puttydoc/Chapter8.html#8

Mee eens... het is veiliger om dat erin te zetten, omdat je zo de encryptie nog moeilijker maakt. Echter ik vind dat hier niet nodig, dus maak er geen gebruik van.