Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have 2 ubuntu 12.04 (beta) servers (node1 and node2) and want to establish passwordless root access between them. Other users should not have access to other boxes. Also note that ssh default port is changed to 220.

Here's what I did:

sudo -i
cd /root/.ssh
ssh-keygen -t rsa # with default name and empty password
cat > authorized_keys

then copied id_rsa & to node2 and added to authorized_keys. Both hosts have the same /root/.ssh/config file:

Host node1
Port 220
IdentityFile /root/.ssh/id_rsa

Host node2
Port 220
IdentityFile /root/.ssh/id_rsa

Now the problem is that when I type ssh node2 it asks me for password. What may be the problem?


Debug info on client:

debug1: Server host key: RSA ***
debug1: Host '[*.*.*.*]:220' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:6
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
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /root/.ssh/id_rsa ((nil))
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: read PEM private key done: type RSA
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug1: Next authentication method: password

Debug info on server:

debug1: userauth-request for user root service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: PAM: initializing for "root"
debug1: PAM: setting PAM_RHOST to "*.*.*.*"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth-request for user root service ssh-connection method publickey [preauth]
debug1: attempt 1 failures 0 [preauth]
debug1: test whether pkalg/pkblob are acceptable [preauth]
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug1: matching key found: file /root/.ssh/authorized_keys, line 2
Found matching RSA key: ****
debug1: restore_uid: 0/0
debug3: mm_answer_keyallowed: key 0x7f0647b0c1b0 is allowed
debug3: mm_request_send entering: type 22
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa [preauth]
Postponed publickey for root from *.*.*.* port 38887 ssh2 [preauth]


drwx------ 2 root root   4096 Mar 26 15:34 .ssh

-rw------- 1 root root  840 Mar 26 14:50 authorized_keys
-rw-r--r-- 1 root root  225 Mar 26 15:34 config
-rw------- 1 root root 1679 Mar 26 14:47 id_rsa
-rw-r--r-- 1 root root 2652 Mar 26 14:39 known_hosts

Some lines from config files:

PermitRootLogin without-password
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  %h/.ssh/authorized_keys
UsePAM no # also tried yes
share|improve this question
Have you been through all the other questions about this first? There are many suggestions as to how to troubleshoot this problem, and it generally comes down to permissions on .ssh/* and /etc/sshd_config – Paul Mar 26 '12 at 12:26
@Paul Yep I've read those (not all to be honest) and found nothing useful – Poma Mar 26 '12 at 13:22
Is that debug from the client side? Can you enable debugging on the server side and see what it doesn't like? – Paul Mar 26 '12 at 23:08
What's the permission for /root itself? It would be better practice to have to key-pairs and add the public key to the remote side's authorized_keys, rather than copying the private keys across. – Bruno Mar 27 '12 at 1:38
@Paul added server debug info to my question – Poma Mar 27 '12 at 16:06

Is root's home directory encrypted (perhaps by ecryptfs)?

I was having a similar issue where public key authentication would not work unless the user already had an active session. Reading this question, I realized that by choosing to encrypt the user's home directory I was preventing sshd from reading ~/.ssh/authorized_keys unless the user was already logged in on another session (which would then automatically decrypt the home directory).

I resolved the issue by switching to unencrypted home directories, after which public key authentication started working.

share|improve this answer
+1: thanks, I was having a problem with .Xauthority and I thought it was related. It seems this is the first time I try to ssh to my other PC without being logged in... – Avio Sep 30 '12 at 17:39

ssh comes with a command to copy the public key to the remote server, ssh-copy-id. It takes care of any necessary permissions and various other "gotcha" issues.


ssh-copy-id -i $HOME/.ssh/id_dsa

After copying with ssh-copy-id you should no longer be asked for a password when you ssh.

share|improve this answer

Some suggestions:

  • Check the permissions of your /root/.ssh (and its contents
  • Check whether ssh allows root-login and/or public key authentication (/etc/ssh/sshd_config iirc)
  • use ssh -v -v to see more debugging output
share|improve this answer
I've already checked those. Everything looks ok to me. I've updated my answer with more info. – Poma Mar 26 '12 at 13:14

Use LogLevel DEBUG in /etc/ssh/sshd_config to debug. One possible gotcha is having the .ssh directory in /home/someuser/, as it should be under /root/.

share|improve this answer

I encountered this, because I had one encrypted user on my system. This leads the sshd into the assumption, that every users directory is encrypted and the authorized_keys file is located under /etc/ssh/username/authorized_keys

For me it worked, after I moved the authorized key to /etc/ssh/username/ and then chown -R username:username /etc/ssh/username/. Funny enough, that I had to do this for every user, even the not encrypted ones!

share|improve this answer

Your Answer


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.