SSH with passwordless public/private key not working on another account on server

infocom · 12-10-2006, 08:34 AM

Hi

This is driving me nuts!

I have created a public and private key pair for accessing my CPanel accounts via SSH without a password (so I can run some backup scripts overnight to my local machine).

It seemed to be working fine. I upload the file authorized_keys2 into the .ssh directory for the account I wish to access, and it works OK.

BUT for just 1 of my accounts it wont work. It keeps asking for the password. I have set it up identical to the other accounts! Its the same file public file, .ssh/authorized_keys2. I access the accounts using the same host name, infocomonline.co.uk. They all use the same private id_rsa file on my local machine.

But for this one account, it wont use the authorized_keys2, and skips to ask a password. Here's ssh -v:-

debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'infocomonline.co.uk' is known and matches the RSA host key.
debug1: Found key in /cygdrive/d/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Trying private key: id_rsa
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: password
welshhm@infocomonline.co.uk's password:

Can anyone help?

Thanks

gilead · 12-10-2006, 01:36 PM

Quote:

Originally Posted by infocom

debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: password

It looks like something is failing there. Do you get any more information with a higher debug level, for example -vv or even -vvv instead of -v?

For example, here's my output for that part of the process:

Code:

debug1: Authentications that can continue: publickey,keyboard-interactive
debug3: start over, passed a different list publickey,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 authentication method: publickey
debug1: Offering public key: /home/steve/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 149
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>
Enter passphrase for key '/home/steve/.ssh/id_rsa':

infocom · 12-11-2006, 03:55 AM

A higher level of debugging eh. Didnt know about that...

Here's the output...

Code:

OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
debug2: ssh_connect: needpriv 0
debug1: Connecting to infocomonline.co.uk [208.101.63.208] port 8888.
debug1: Connection established.
debug3: Not a RSA1 key file id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file id_rsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: 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: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,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-group14-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,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,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(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 132/256
debug2: bits set: 513/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /cygdrive/d/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug3: check_host_in_hostfile: filename /cygdrive/d/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug1: Host 'infocomonline.co.uk' is known and matches the RSA host key.
debug1: Found key in /cygdrive/d/.ssh/known_hosts:1
debug2: bits set: 480/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: id_rsa (0x0)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
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: Trying private key: id_rsa
debug1: read PEM private key done: type RSA
debug3: sign_and_send_pubkey
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
welshhm@infocomonline.co.uk's password:

gilead · 12-11-2006, 12:35 PM

Quote:

Originally Posted by infocom

Code:

debug3: Not a RSA1 key file id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'

It looks like there's a problem with the key itself. If you have a file that was generated on MS-DOS/Windows it may not be formatted correctly on the Linux box. Alternatively, the upload itslef may have had a problem.

Those are just guesses, but since the file works on other boxes, have you tried deleting the key on the Linux account with the problem and uploading it again?

infocom · 12-12-2006, 03:32 AM

Yeah I deleted a few times and reuploaded. The thing is, I uploaded it to a couple of other Cpanel accounts on the same server, and I can SSH without password fine. So I assume the files are OK because of this. Its just for this one account.

gilead · 12-13-2006, 01:15 PM

Although it doesn't sound like permissions, that's the only other thing I can think of at the moment. Are your permissions something like these:

Code:

$ ls -ld .ssh
drwx------ 2 steve steve 4096 2006-10-08 21:52 .ssh/
$ ls -l .ssh
total 16
lrwxrwxrwx 1 steve steve  10 2006-10-08 12:55 authorized_keys -> id_rsa.pub
-rw------- 1 steve steve 951 2006-01-05 02:23 id_rsa
-rw-r----- 1 steve steve 244 2006-01-05 02:23 id_rsa.pub
-rw-r----- 1 steve steve 643 2006-11-08 11:12 known_hosts

infocom · 12-14-2006, 03:15 AM

they weren't (they were 700 and 600) but I changed them so and still got the error.

I just tried it with a new account I just created and it worked first time, using the files from this account that does not work. Crazy.

Thanks for your help though.

gilead · 12-14-2006, 01:03 PM

The same file works for all users except that one? Crazy is right

Are you using any of the user restriction options (AllowUsers, AllowGroups, DenyUsers, DenyGroups) in /etc/ssh/sshd_config?

infocom · 12-15-2006, 05:04 AM

I dont have a /etc/ssh folder. I am on a shared server, and use WHM/Cpanel to create accounts. So the process I used to create this account would be the same as all ther rest. I suspect there's no /etc/ssh folder because they are controlled with Cpanel maybe?? Either way wouldn;t /etc/ssh be the same for all accounts as its a shared server? SSH does work of of course, I can use ssh welshhm@infocomonline.co.uk to get in with my password.

timkstout · 09-08-2010, 02:05 PM

INFOCOM: I'm having the exact same ssh problem - only 1 user getting prompted for a password. I've seen it on 2 different systems now. Did you ever find a fix for it???

Thanks!

infocom · 09-09-2010, 03:11 AM

Sorry but this was so long ago I cant even remember the issue! I dont use Linux as a desktop anymore, too many problems to get basic things working. Switched to Mac and still use Windows. Will give Linux a try again in another couple of years to see if it has caught up with the big boys. Still use it for server hosting its good at that.

hpfeil · 12-24-2010, 03:58 PM

For the record, should anyone else find themselves herein with a similar problem, the fix is most likely the permissions of the files in ~/.ssh. The two .pub files and authorized_keys chmod 644, the rest need to be chmod 600, that is read/write for the owner only. If the file permissions are incorrect, the host's authentication will fall through to its last resort, password. Just match the permissions of $HOME/.ssh/* for the users that connect w/o password.

confconf · 12-25-2010, 12:31 PM

Also make sure your home directory is only writable by your user (eg. 0700). Check /var/log/secure for error logs.

ThelenShar · 12-27-2010, 04:41 AM

chmod 750 /home/ -R

if that works it is permissions. If it doesn't, it is the key or something else.

tshikose · 12-27-2010, 05:09 AM

Hi,

Have a look at the SSH versions you are using.
If my memory is accurate, SSH version 2 use dsa keys and file ~/.ssh/authorized_keys2.
But version 1 use rsa keys and file ~/.ssh/authorized_keys.

Maybe the second account just expect a session in SSH version 1 not 2!
You can also create other rsa keys besides the dsa keys with the ssh-keygen -t rsa command.
Version 2 is actually the default. Have a look in the file /etc/ssh/sshd_config, or its equivalent as it seems to the file does not exist on your system (strange isn't?).

Regards,

Tshimanga.