SSH keys not working

GATTACA · 07-09-2007, 10:28 PM

Hello.

I'm trying to configure SSH keys so I don't have to type my password each time to log into a machine.
I've done this countless of times and it has always worked. Now we have a new server in the office and it doesn't work.

Here are the steps I take:
On the local machine I execute:

Code:

ssh-keygen -t dsa

Press <ENTER> twice to create key pairs with out passwords. Then I do the following:

Code:

cd $HOME/.ssh
scp id_dsa.pub user@remoteMachine:$HOME/.ssh/authorized_keys2
chmod 700 $HOME/.ssh
chmod 600 $HOME/id_dsa
chmod 644 $HOME/id_dsa.pub

Then I try to ssh to remoteMachine. Here is the ssh debug log for what I get:

Code:

OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to remoteMachine [123.123.123.123] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/identity type -1
debug1: identity file /home/user/.ssh/id_rsa type -1
debug3: Not a RSA1 key file /home/user/.ssh/id_dsa.
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
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/user/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.5
debug1: match: OpenSSH_4.5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.9p1
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-gro
up14-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-c
tr
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-c
tr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
ssh.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: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-g
roup-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,arcfour1
28,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-c
tr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1
28,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-c
tr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
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: 119/256
debug2: bits set: 502/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/user/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 7
debug3: check_host_in_hostfile: filename /home/user/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 8
debug1: Host 'remoteMachine' is known and matches the RSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:7
debug2: bits set: 508/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: /home/user/.ssh/identity ((nil))
debug2: key: /home/user/.ssh/id_rsa ((nil))
debug2: key: /home/user/.ssh/id_dsa (0x552abfeb70)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug2: we sent a gssapi-with-mic packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug2: we sent a gssapi-with-mic 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 publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/identity
debug3: no such identity: /home/user/.ssh/identity
debug1: Trying private key: /home/user/.ssh/id_rsa
debug3: no such identity: /home/user/.ssh/id_rsa
debug1: Offering public key: /home/user/.ssh/id_dsa
debug3: send_pubkey_test
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
user@remoteMachine's password:

Since I'm being asked for a password, I'm guessing something went wrong with the keys.

Any suggestions what could be the problem?

Thanks in advance.

macemoneta · 07-09-2007, 11:19 PM

The authorized_keys2 file is depreciated since openssh 3.0 (2001). The correct file, since you are running openssh 3.9 is authorized_keys.

GATTACA · 07-10-2007, 07:34 AM

Quote:

Originally Posted by macemoneta

The authorized_keys2 file is depreciated since openssh 3.0 (2001). The correct file, since you are running openssh 3.9 is authorized_keys.

Thanks for the quick reply!

As per your suggestion. I renamed authorized_keys2 to authorized_keys. This had no effect, I'm still requested to provide a password.

nx5000 · 07-10-2007, 07:52 AM

You mean it doesn't work at all or only when you ssh to this particular destination?

An ssh-agent is running right?

GATTACA · 07-10-2007, 08:02 AM

Quote:

Originally Posted by nx5000

You mean it doesn't work at all or only when you ssh to this particular destination?

An ssh-agent is running right?

I mean that SSH keys outbound don't work at all. I can ssh to any machine from the local computer where I generate the ssh key pairs, I'm just required to use a password. The keys seem to be ignored.

SSH is running on the local computer:

Code:

$ ps -fe | grep "sshd"
root      3994     1  0 Jan30 ?        00:00:07 /usr/sbin/sshd
root     16043  3994  0 08:56 ?        00:00:00 sshd: user [priv]
user     16049 16043  0 08:56 ?        00:00:00 sshd: user@pts/0

I've verified that the problem isn't with connecting to the remote machine via SSH. On a different computer I created key pairs and copied the public key over to the remote machine as was able to ssh in without a password.

It's just this one box that can't SSH with keys to any other machine.

macemoneta · 07-10-2007, 08:06 AM

Are the permissions on ~/.authorized keys 644? You can also use the ssh-copy-id command to automate the process and insure it's done correctly:

ssh-copy-id user@host

nx5000 · 07-10-2007, 08:21 AM

Code:

ps -fe | grep ssh
root      3294     1  0 11:47 ?        00:00:00 /usr/sbin/sshd
bill      4376  4329  0 12:05 ?        00:00:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde
bill     14471 14439  0 13:51 pts/1    00:00:21 ssh bill@microsoft.com
bill     16930 16413  0 15:19 pts/3    00:00:00 grep ssh

I usually login, start the ssh _agent_ that gives the key to the ssh client.
Then make an ssh-add
Otherwise I get prompted for the password of the local keys.

That's how I understood it at least

GATTACA · 07-10-2007, 10:36 AM

I've figured it out!

Apparently for SSH-keys to work, the user's home directory on the remote machine must not be group writeable. I had the user's home permissions set to: drwxrwxr-x. When I reset them to drwxr-xr-x the keys worked.

I don't understand why this matters since the $HOME/.ssh directory is set to drwx------.

Thoughts?

macemoneta · 07-10-2007, 10:59 AM

It's a security issue. Group write permissions on the home directory allows the group to change the permissions on the .ssh directory (or any other subdirectory)