ssh to remote machine with public-key method

2007fld · 08-13-2007, 02:37 PM

I would like to ssh to remote machines without typing password. I generated public/private key pairs. Then I scp the pub key to remote machine /homedir/.ssh, renamed it to authorized_ keys. One remote machine lets me ssh onto using public-key method immediately. But the other remote machine keeps asking me to type password.

Here is the result of "ssh -v" from the 2nd remote machine. The result from the 1st remote machine is very similar to this one, except it find the key and opend channel.

Code:

SSH Version Sun_SSH_1.0, protocol versions 1.5/2.0.
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: getuid 102 geteuid 102 anon 1
debug1: Connecting to x.x.x.x port 22.
debug1: Connection established.
debug1: Bad RSA1 key file /xxx/.ssh/identity.
debug1: identity file /xxx/.ssh/identity type 3
debug1: Bad RSA1 key file /xxx/.ssh/id_rsa.
debug1: identity file /xxx/.ssh/id_rsa type 3
debug1: identity file /xxx/.ssh/id_dsa type 3
debug1: Remote protocol version 2.0, remote software version VShell_3_0_0_439 VShell
debug1: no match: VShell_3_0_0_439 VShell
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-Sun_SSH_1.0
debug1: sent kexinit: diffie-hellman-group1-sha1
debug1: sent kexinit: ssh-rsa,ssh-dss
debug1: sent kexinit: aes128-cbc,blowfish-cbc,3des-cbc,rijndael128-cbc
debug1: sent kexinit: aes128-cbc,blowfish-cbc,3des-cbc,rijndael128-cbc
debug1: sent kexinit: hmac-sha1,hmac-md5
debug1: sent kexinit: hmac-sha1,hmac-md5
debug1: sent kexinit: none
debug1: sent kexinit: none
debug1: sent kexinit:
debug1: sent kexinit:
debug1: send KEXINIT
debug1: done
debug1: wait KEXINIT
debug1: got kexinit: diffie-hellman-group1-sha1
debug1: got kexinit: ssh-dss
debug1: got kexinit: aes256-cbc,aes192-cbc,aes128-cbc,twofish-cbc,blowfish-cbc,3des-cbc,arcfour
debug1: got kexinit: aes256-cbc,aes192-cbc,aes128-cbc,twofish-cbc,blowfish-cbc,3des-cbc,arcfour
debug1: got kexinit: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96
debug1: got kexinit: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96
debug1: got kexinit: zlib@openssh.com,zlib,none
debug1: got kexinit: zlib@openssh.com,zlib,none
debug1: got kexinit:
debug1: got kexinit:
debug1: first kex follow: 0
debug1: reserved: 0
debug1: done
debug1: kex: server->client unable to decide common locale
debug1: kex: server->client aes128-cbc hmac-sha1 none
debug1: kex: client->server unable to decide common locale
debug1: kex: client->server aes128-cbc hmac-sha1 none
debug1: Sending SSH2_MSG_KEXDH_INIT.
debug1: bits set: 481/1024
debug1: Wait SSH2_MSG_KEXDH_REPLY.
debug1: Got SSH2_MSG_KEXDH_REPLY.
debug1: Host 'x.x.x.x' is known and matches the DSA host key.
debug1: Found key in /xxx/.ssh/known_hosts:3
debug1: bits set: 525/1024
debug1: len 55 datafellows 0
debug1: ssh_dss_verify: signature correct
debug1: Wait SSH2_MSG_NEWKEYS.
debug1: GOT SSH2_MSG_NEWKEYS.
debug1: send SSH2_MSG_NEWKEYS.
debug1: done: send SSH2_MSG_NEWKEYS.
debug1: done: 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
debug1: next auth method to try is publickey
debug1: try pubkey: /xxx/.ssh/identity
debug1: read SSH2 private key done: name rsa w/o comment success 1
debug1: authentications that can continue: publickey,password
debug1: next auth method to try is publickey
debug1: try pubkey: /xxx/.ssh/id_rsa
debug1: read SSH2 private key done: name rsa w/o comment success 1
debug1: authentications that can continue: publickey,password
debug1: next auth method to try is publickey
debug1: key does not exist: /xxx/.ssh/id_dsa
debug1: next auth method to try is password
password:

Any suggestions is appreciated!

acid_kewpie · 08-13-2007, 03:48 PM

my personal gotcha is that the authorized keys file is often not set to perms of 600, meaning that other people could read your keys and copy them... not handy, and somethign ssh guards against, albeit with little notification to the client connection.

Brian1 · 08-13-2007, 04:13 PM

Check this link and set permissions of the needed directory and files as described.
http://www.suso.org/docs/shell/ssh.sdf

Brian