Home.... | log in.... | Pub my question! | Sign-up....
Java-index >> General >> Talk to the Sysop

ssh authentication issue

Appreciate if any expert able to help me out. I have been checking all ssh sites and forums but still not able to solve this problem.

I have setup a cronjob in server A to run scp command through user 1 and it's working fine. Authentication method used was RSA and without passphrase.

However when I tried to use scp command to copy files from/to another user in same remote server, it keeps prompt for password. I have copied user1's public key to authorized_keys in user2 in remote server.

user1 in server A connect to user3 in server B --> connected without prompting for password

user1 in server A connect to user2 in server B --> keeps prompt for password

Here is the debug code when I run ssh command to connect to user2:

$ ssh -p 32 -v user2@<ip_address>

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 1052 geteuid 1052 anon 1

debug1: Connecting to <ip address> [ip address] port 32.

debug1: Connection established.

debug1: identity file /export/home/user1/.ssh/identity type 3

debug1: Bad RSA1 key file /export/home/user1/.ssh/id_rsa.

debug1: identity file /export/home/user1/.ssh/id_rsa type 3

debug1: identity file /export/home/user1/.ssh/id_dsa type 3

debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1

debug1: no match: Sun_SSH_1.1

Enabling compatibility modefor 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-group-exchange-sha1,diffie-hellman-group1-sha1

debug1: got kexinit: ssh-rsa,ssh-dss

debug1: got kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc

debug1: got kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc

debug1: got kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96

debug1: got kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96

debug1: got kexinit: none,zlib

debug1: got kexinit: none,zlib

debug1: got kexinit: C,POSIX

debug1: got kexinit: C,POSIX

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: 508/1024

debug1: Wait SSH2_MSG_KEXDH_REPLY.

debug1: Got SSH2_MSG_KEXDH_REPLY.

debug1: Host'<ip address>' is known and matches the RSA host key.

debug1: Found key in /export/home/user1/.ssh/known_hosts:1

debug1: bits set: 518/1024

debug1: ssh_rsa_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 cancontinue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive

debug1: next auth method totry is publickey

debug1: key does not exist: /export/home/user1/.ssh/identity

debug1:try pubkey: /export/home/user1/.ssh/id_rsa

debug1: read SSH2private key done: name rsa w/o comment success 1

debug1: authentications that cancontinue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive

debug1: next auth method totry is publickey

debug1: key does not exist: /export/home/user1/.ssh/id_dsa

debug1: next auth method totry is password

user2@<ip address>'s password:

Thanks in advance for spending time on this.

[4884 byte] By [yelo] at [2007-11-26 6:31:29]
«« Subscription for entire domain
»» JComboBox goes to full screen (even goes beyond its boundary)
# 1

I ran into this problem recently. Here's the scoop:

Historical data:

Some servers were hosted in a remote location (one of those ISP services). They re-IP'ed an entire subnet and as a result the hosts changed IPs.

Back to my client's location:

All these servers belonged to a local group here and the DNS entries were locally managed. So while waiting for these entries to get done, someone from the app admin side made /etc/hosts entries. And they were able to access the hosts (similar trusting mechanism) using IP addresses.

But as soon as host names (short names) were used, it would start prompting for a password. After digging a little deeper, I realized that the /etc/hosts entries were wrong. There were 3 servers in the same subnet and the entries had gotten mixed up.

Moral of the story:

a) Check whether the trusting works via IP.

b) check whether they work via hostname

c) check for erroneous entries in /etc/hosts

d) check for erroneous entries in DNS

HTH

implicate_order at 2007-7-6 14:29:37 > top of Java-index,General,Talk to the Sysop...
# 2

Doh! Obviously my "preachy" speech won't help you too much.

:\

1) Check whether the "authorized_keys" file in user2's homedir on server B has any "inappropriate line-breaks". If you have copied/pasted user1's public key, it's possible that something "wierd" has found it's way into the authorized_keys file. Open it up in vi and run ":set list" from the cmd mode. Line breaks show up as "$". Make sure there aren't any linebreaks in the public key string (It has to be 1 unbroken line). You can compare by running "set list" on user1's id_rsa.pub on serverA.

2) Other thing to check is the .ssh directory and authorized_keys file permissions (I usually set .ssh to 0700 and authorized_keys to 0600).

HTH

implicate_order at 2007-7-6 14:29:37 > top of Java-index,General,Talk to the Sysop...
# 3

I'm aware of the possibility that content of "authorized_keys" file maybe different when copy from server A to B. That's why I have copy "id_rsa.pub" file from server A to B using scp command and then rename it. So no problem there.

Permission of directory and files in .ssh are also same as what you have suggested but still prompt for password when running ssh command.

Any other suggestion?

Thanks in advance.

yelo at 2007-7-6 14:29:37 > top of Java-index,General,Talk to the Sysop...
# 4
debug1: key does not exist: /export/home/user1/.ssh/id_dsaWhat's the verbose output of trying the same connection on the command line to user 3, i.e.,$ ssh -p 32 -v user3@<ip_address>
Codename47 at 2007-7-6 14:29:37 > top of Java-index,General,Talk to the Sysop...
# 5

Here's the response:

$ ssh -p 32 -v user3@<ip_address>

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 1052 geteuid 1052 anon 1

debug1: Connecting to ip_address [ip_address] port 32.

debug1: Connection established.

debug1: identity file /export/home/user1/.ssh/identity type 3

debug1: Bad RSA1 key file /export/home/user1/.ssh/id_rsa.

debug1: identity file /export/home/user1/.ssh/id_rsa type 3

debug1: identity file /export/home/user1/.ssh/id_dsa type 3

debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1

debug1: no match: Sun_SSH_1.1

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-group-exchange-sha1,diffie-hellman-group1-sha1

debug1: got kexinit: ssh-rsa,ssh-dss

debug1: got kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc

debug1: got kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc

debug1: got kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96

debug1: got kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96

debug1: got kexinit: none,zlib

debug1: got kexinit: none,zlib

debug1: got kexinit: C,POSIX

debug1: got kexinit: C,POSIX

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: 532/1024

debug1: Wait SSH2_MSG_KEXDH_REPLY.

debug1: Got SSH2_MSG_KEXDH_REPLY.

debug1: Host '<ip_address>' is known and matches the RSA host key.

debug1: Found key in /export/home/user1/.ssh/known_hosts:1

debug1: bits set: 521/1024

debug1: ssh_rsa_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: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive

debug1: next auth method to try is publickey

debug1: key does not exist: /export/home/user1/.ssh/identity

debug1: try pubkey: /export/home/user1/.ssh/id_rsa

debug1: read SSH2 private key done: name rsa w/o comment success 1

debug1: ssh-userauth2 successfull: method publickey

debug1: channel 0: new [client-session]

debug1: send channel open 0

debug1: Entering interactive session.

debug1: client_init id 0 arg 0

debug1: channel request 0: shell

debug1: channel 0: open confirm rwindow 0 rmax 32768

Last login: Wed Apr 19 03:55:14 2006 from <ip_address>

$

I noticed that the ip address I entered on ssh command is different from ip address prompted on "Last login: Wed Apr 19 03:55:14 2006 from <ip_address>" .

Does this matter?

yelo at 2007-7-6 14:29:37 > top of Java-index,General,Talk to the Sysop...
# 6

It would matter if you didn't connect last to that box from that IP address. If you login, say, from 10.1.1.10 to 10.1.1.20, log out, and login again from 10.1.0.10 to 10.1.1.20 and the banner says "last login 192.168.1.42", then there are some other issues you need to look at.

Now, probably you've gone through all of these questions before in other groups, but since we haven't here, and you are not going to give us a login to your box :)

Have you checked that the key looks the same in user2's authorized_keys as it does in user3's authorized_keys?

Since the public key entry for user1 in both user2 and user3 authorized_keys should be identical, have you tried copying user2's authorized_keys into user3's authorized_keys and see if ssh works with either user?

You said you copy id_rsa.pub and then rename it. What are you renaming it to?

Are you renaming it to authorized_keys?

Is that the only key in user2's authorized_keys, or are there more keys? Have you checked that there aren't any previous entries for user1 in user2's authorized_keys?

Do you have NIS or NIS+ ? Have you checked whether there is a local user and a NIS(+) user2?

Codename47 at 2007-7-6 14:29:37 > top of Java-index,General,Talk to the Sysop...
General
Talk to the Sysop

General New Topic

General Hot Topic

General

All Classified