Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I am trying to setup a password-less SSH configuration between two machines and am having trouble. 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 "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 http://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:
ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,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,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-    
sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,umac-64@openssh.com,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-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,zlib@openssh.com,none
debug2: kex_parse_kexinit: zlib,zlib@openssh.com,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).

share|improve this question
    
What versions of ssh? What OS on box1 and box2? Is the ssh daemon configured to allow root logins on box2? –  Chad Huneycutt Sep 10 '12 at 16:54
    
@ChadHuneycutt added in edit2 –  njozwiak Sep 10 '12 at 17:01
    
Also added debug output as it might be insightful. –  njozwiak Sep 10 '12 at 17:17
    
What kind of debug output does dropbear support? And did you check dropbear's configuration to see if it allows root public key logins? –  Chad Huneycutt Sep 10 '12 at 17:31
    
Someone with the same issue as you. Unfortunately, doesn't look like it got solved. :( serverfault.com/questions/299051/what-does-this-ssh-error-mean –  ire_and_curses Sep 10 '12 at 18:11
show 7 more comments

5 Answers 5

up vote 7 down vote accepted

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.

share|improve this answer
1  
Yeah, almost always ssh key issues come down to permissions / ownership problems. Glad you go this sorted out. –  gabe. Sep 17 '12 at 15:40
add comment

This is one very simple article that I often come back to if I don't remember exactly what to do with SSH key setup. It is brief, but complete and concise.

http://linuxproblem.org/art_9.html

share|improve this answer
add comment

here is the article, i came across and its very simply and useful.

Article about password less login using ssh

share|improve this answer
    
Please don't just post links; include some context so that if the other site is down there is some helpful information available here. –  jasonwryan Sep 17 '12 at 18:48
add comment

Can you confirm if root login in ssh is allowed ? keygen usually prompts for password. Have you made a passphrase while keygen ? If yes, then it is prompting for that password. If you want passwordless access for headless account then create passwordless private keys.

share|improve this answer
    
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. –  Chad Huneycutt Sep 10 '12 at 17:42
add comment

From the Debug: debug2: key_type_from_name: unknown key type '-----BEGIN' it looks like you have an improperly formatted authorized_keys file.
Removing the first (two?) lines, the last line (-----End) and any other line breaks should fix the problem.

The key file for Linux does not use the same keyfile as many Windows (and some Linux) generators. PuTTY, for example, starts private keys as ---- BEGIN SSH2 PUBLIC KEY ---- but Linux is looking for ssh-rsa AAAAB3NzaC1yc2E...G8HAaGz8ob6IXx3841ASs= Example@server The full specification can be found here: http://man.he.net/man5/authorized_keys

But the short version is: *No line breaks
*Starts with the protocol (ssh-rsa, ssh-dsa)
*Public key
*Ends with “=” and the key name

Let me know if this helps

share|improve this answer
    
I have verified on both boxes that there is no extra space at the beginning or the end of the authorized_keys file. However, There is also no "=" sign followed by the key name you are referencing. The format of my file is: ssh-rsa $KEY root@boxn Is this incorrect? –  njozwiak Sep 11 '12 at 17:19
    
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. –  Yuugian Sep 12 '12 at 12:21
    
= 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. –  njozwiak Sep 12 '12 at 16:52
    
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 –  Yuugian Sep 12 '12 at 18:06
    
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. –  njozwiak Sep 12 '12 at 18:22
show 2 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.