Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

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

On an ubuntu machine I did the following:

~$ sudo su -
[sudo] password for jamie:
root@mydomain:~# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/
The key fingerprint is:
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|                 |
|                 |
|                 |
|                 |
|                 |
|                 |
|                 |
|                 |
root@mydomain:~# cat /root/.ssh/ | ssh -p 443 'cat > ~/.ssh/authorized_keys''s password:
root@mydomain:~# ssh's password:

It's asking me for a password.

However, using a regular account, the following works:

$ cd ; ssh-keygen -t rsa ; cat ~/.ssh/ | ssh 'cat >> ~/.ssh/authorized_keys'
$ ssh
Last login: Thu Oct 24 14:48:41 2013 from
[ ~]$ 

Which leads me to believe it's not an issue of authorized_keys versus authorized_keys2 or permissions.

Why does the 'root' account accessing the remote 'jamie' account not work?

The remote machine is CentOS if that's relevant.

share|improve this question
In both cases you're adding the key to the authorized_keys of the same user. There is no reason why it would let you log in as root. Besides that, root login might simply be disabled (as it should be). As long as you're allowed to elevate, just log in as "jamie" and use sudo once logged on. – Oliver Salzburg Oct 24 '13 at 19:00
@OliverSalzburg I wasn't clear; I want the root account on the Ubuntu machine to have access to the 'jamie' account on the remote, not 'root'. – Jamie Oct 24 '13 at 19:02
I bet it has something to do with the way you use su. What is $HOME set as after you su? Try it again with su - and maybe it will work better. – Kevin Panko Oct 24 '13 at 19:12
I'm not sure if this matters (it probably doesn't), but I don't think sudo su ; cd does what you want. The cd won't be processed in the elevated shell, but only after you log out of it. – Oliver Salzburg Oct 24 '13 at 19:15
Can you verify if the public key you generated as root is properly added to the authorized_keys on the remote side? You might also want to have a look at ssh-copy-id – Oliver Salzburg Oct 24 '13 at 19:16
up vote 2 down vote accepted

The answer was found here:

probably should mark this question as duplicate of the same.

share|improve this answer
Unfortunately stack exchange does not currently support linking questions between sites. – Jan Hudec Oct 25 '13 at 6:27
Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference. – Canadian Luke Oct 25 '13 at 16:12
Yes, and duplicates must be in the same site. The question would need to be migrated first and then it could be marked as duplicate. – Kevin Panko Oct 25 '13 at 17:47

Try running ssh in verbose mode. I find this often provides a clue as to what is happening.

Check the security on the directories all the way to .ssh on the target machine. If any directories are world or group writable, this can cause ssh to refuse to access your authorized keys file. I believe the .ssh directory must be not be accessible to either group or world.

Try creating a key file on the remote and adding the public key to the authorized_keys file. Get ssh localhost working first, then try remote access.

You can configure the .ssh/config file on root to add the user for you. Something like this should work:

host remote
share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .