How to setup password-less ssh with RSA keys

Question

I am trying to setup a password-less SSH configuration between two machines and I am having a problem. There are a ton of howtos out there that I have followed and have had no success. Here are the steps that I've taken

1. Generate the authentication keys on the client. (Pressed enter when prompted for a passphrase) [root@box1:.ssh/$] ssh-keygen -t rsa

2. Copy the public key to the server. [root@box1:.ssh/$] scp id_rsa.pub root@box2:.ssh/authorized_keys

3. Verified the authorized key was created successfully on the server

4. Executed the following command: [root@box1:.ssh/$] ssh root@box2 ls

And I was still prompted for a password. I read a note on one howto that said "depending on the version of SSH that is running..." (although it did not specify which versions needed this), it might require:

• The public key in .ssh/authorized_keys2
• Permissions of .ssh to 700
• Permissions of .ssh/authorized_keys2 to 640

I also followed those steps and had no success. I have verified that the home, root, and .ssh directories are not writable by group (according to https://unix.stackexchange.com/tags/ssh/info).

Anyone have any ideas what I'm missing?

Thanks

EDIT: I also copied the public key to the second box using the ssh-copy-id command and that generated the .ssh/authorized_keys file.

[root@box1:.ssh/$] ssh-copy-id -i id_rsa.pub root@box2

EDIT2: Including version information

// box1 (system keys were generated on)

• Linux 2.6.34
• OpenSSH_5.5p1 Debian-6, OpenSSL 0.9.8o 01 June 2010

// box2

• Linux 2.6.33
• Dropbear client v0.52

EDIT3: Debug output

[root@box1:.ssh/$] ssh -vvv root@box2 ls
OpenSSH_5.5p1 Debian-6, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to box2 [box2] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug3: Not a RSA1 key file /root/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /root/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version dropbear_0.52
debug1: no match: dropbear_0.52
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-6
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-    
group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit:
[email protected],[email protected],ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-    
cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysatoe
debug2: kex_parse_kexinit:
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-    
cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysatoe
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-    
sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-
sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],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-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-ctr,3des-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes256-cbc,twofish256-cbc,twofish-
cbc,twofish128-cbc,blowfish-cbc
debug2: kex_parse_kexinit:
aes128-ctr,3des-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes256-cbc,twofish256-cbc,twofish-
cbc,twofish128-cbc,blowfish-cbc
debug2: kex_parse_kexinit: hmac-sha1-96,hmac-sha1,hmac-md5
debug2: kex_parse_kexinit: hmac-sha1-96,hmac-sha1,hmac-md5
debug2: kex_parse_kexinit: zlib,[email protected],none
debug2: kex_parse_kexinit: zlib,[email protected],none
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug2: dh_gen_key: priv key bits set: 132/256
debug2: bits set: 515/1024
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug3: check_host_in_hostfile: host 192.168.20.10 filename
/root/.ssh/known_hosts
debug3: check_host_in_hostfile: host 192.168.20.10 filename
/root/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 3
debug1: Host 'box2' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:3
debug2: bits set: 522/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: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /root/.ssh/id_rsa (0x54b1c340)
debug2: key: /root/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred
gssapi-keyex,gssapi-with-mic,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: /root/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa
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

EDIT4: Another interesting development. Instead of generating the keys on box1 (running OpenSSH) and copying them to box2 (running dropbear) I did it in reverse:

[root@box2:.ssh/$] dropbearkey -t rsa -f id_rsa [root@box2:.ssh/$] dropbearkey -y -f id_rsa | grep "^ssh-rsa" >> authorized_keys [root@box2:.ssh/$] scp authorized_keys root@box1:.ssh/

And with that I am successfully able to issue commands password-less from box2 to box1 ONLY if I specify the ID file: [root@box2:.ssh/$] ssh -i id_rsa root@box1 ls

Still unable to issue commands from box1 (OpenSSH) to box2 (dropbear).

Solution

I found the source of the problem. There was a vague message in /var/log/messages about strange ownership that tipped me off. So I checked, and the permissions of /root, /root/.ssh, and /root/.ssh/* were all correct (700), but the ownership was default.default. I'm not sure how that happened... but I ran:

[root@box1:.ssh/$] chown root.root /root
[root@box1:.ssh/$] chown root.root /root/.ssh
[root@box1:.ssh/$] chown root.root /root/.ssh/* 

To changed the ownership to root and passwordless login works in both directions.

Comments

[Chad Huneycutt]

What versions of ssh? What OS on box1 and box2? Is the ssh daemon configured to allow root logins on box2?

[linsek]

@ChadHuneycutt added in edit2

[linsek]

Also added debug output as it might be insightful.

[Chad Huneycutt]

What kind of debug output does dropbear support? And did you check dropbear's configuration to see if it allows root public key logins?

[xrfang]

Someone with the same issue as you. Unfortunately, doesn't look like it got solved. :( serverfault.com/questions/299051/what-does-this-ssh-error-me‌​an

[xrfang]

Seems there's not much you haven't tried. My only suggestion: Here is a similar issue, where the fix was to specify protocol version 1 before generating the keys: lists.debian.org/debian-user/2003/02/msg01972.html

[Gilles 'SO- stop being evil']

What options is the dropbear server started with? Does anything appear in the system logs on box2?

[linsek]

adding edit4 solution for dropbear to openssh communication

[linsek]

@Gilles dropbear is started by the following: start-stop-daemon -S -q -p /var/run/dropbear.pid --exec /usr/sbin/dropbear

[linsek]

@ire_and_curses Very interesting post, thanks. I tried to limit it to protocol 1 and generate new keys for rsa1. Not only did that not work, but it also broke the dropbear configuration. So box2 returns connection to root@box1 exited: Incompatible remote version 'SSH-1.5-OpenSSH_5.5p1 Debian6'

[Alessio]

i'm guessing that box2 with dropbear is a router or some other small device rather than a general-purpose PC. is there any chance of upgrading the version of dropbear? 0.52 is quite old (Nov 2008), latest version is 2012.55 from Feb this year. alternatively is replacing dropbear with openssh a viable option?

[Karlson]

@njozwiak Have you tried running the sshd in debug mode to see why it doesn't allow passthru authentication?

[Chad Huneycutt]

According to his step 1, his comment just above, and the ssh output, he did not set a passphrase and is being prompted for the password.

[kumar]

I think the = is required before the root@boxn which is just an identifier for the key. The remote machine will say something like Authenticated with public key "root@boxn" if it works.

[linsek]

= is not required as I have tested between two Linux boxes running OpenSSH and they both work without any = in the public keys. Additionally, it is working from dropbox to OpenSSH without a = in the file.

[kumar]

in that case I am starting to agree with Ashwin: does Dropbear allow root login? - From the Dropbear manual "Dropbear will not let you log in as "root" without a password." - leaf.sourceforge.net/doc/bucu-dropbear.html

[linsek]

it is possible as I have one box that is currently doing it. "box1" in the question is a host computer and there are actually multiple "box2's". box2 is an embedded system running dropbear. I currently have 1/3 of these working fully (that is I am able to passwordlessly communicate from box1 to box2 and from box2 to box1). So it is possible, but I can't find a key or configuration difference between them.

[linsek]

I found an article explaining how to disable password login for root in dropbear by editing the /etc/default/dropbear configuration file. But that file doesn't exist on my system. (source: cybermilitia.net/2009/02/28/dropbear-on-debian)

[Krzysztof Adamski]

This debug line is saying that id_rsa file on client machine is improperly formated, not authorized_keys on server machine. You should also run your dropbear on server machine in debug mode (use options -E and -F and run this from CLI, it should not go to background and log everything to stderr, you should see what is happening).

[gabe.]

Yeah, almost always ssh key issues come down to permissions / ownership problems. Glad you go this sorted out.