I am trying to use git salt ssh access (which runs with root). The error is always:

Permission denied (publickey).

I managed to reproduce the problem, simulating what salt may be doing, by running an ssh command on the root user, and then the same command with sudo (still on the root account), getting the same error.

This succeeds:

root@server:/src# ssh -T git@bitbucket.org

logged in as XXXX.

This fails:

root@server:/src# sudo ssh -T git@bitbucket.org

Permission denied (publickey).

Permissions are apparently correct:

ls -la ~/.ssh
total 32
drwx------  2 root root 4096 Jun  2 12:18 .
drwx------ 12 root root 4096 Jun  2 12:10 ..
-rw-------  1 root root  550 Jun  1 16:31 authorized_keys
-r--------  1 root root   83 Jun  2 12:18 config
-rw-------  1 root root  134 Jun  1 18:18 environment
-rw-------  1 root root 1679 May 26  2015 id_rsa
-rw-r--r--  1 root root  393 Aug  3  2014 id_rsa.pub
-rw-r--r--  1 root root 3984 Jun  2 10:19 known_hosts

Adding -v to the failing command shows all good up to the end, where there's no error until the failure:

debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /root/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

I have searched and found only things related to permissions, but nothing explaining about sudo failing when running with root.

  • 7
    Do you understand that with sudo ssh looks into root's home directory for public key?
    – Serge
    Jun 2 '16 at 3:17
  • I understand, and will update the question to show that the first scenario is also run with root user. This is, as mentioned above due to trying to replicate salt behaviour (which runs under root).
    – Efren
    Jun 2 '16 at 23:29

Like @Serge pointed out in a comment, this line

debug1: Offering RSA public key: /root/.ssh/id_rsa

in your ssh -v output tells you that ssh tried to authenticate with the public key in root's home directory (/root) and not your own user directory (/home/yourusername).

This leaves you with three options. You can either

  • run ssh with the -i option to explicitly specify a key that ssh will use (e.g. ssh -i /home/yourusername/.ssh/id_rsa ...),
  • Create a new ssh key for root and add it to your authorized keys on the remote or
  • Copy or link your own .ssh directory to /root

You might want to rethink your setup though. SSH doesn't require root privileges on your machine and running it as root won't get you anything on the remote end either.

  • I was running as root the normal command as well. As mentioned, the setup is for using salt, which runs under root.
    – Efren
    Jun 2 '16 at 23:27

Somehow it was related to the id_rsa.pub file. For the root user, it didn't make a problem, but for sudo through root, it apparently does not work.

Perhaps it is a particular case with root that blocks this or perhaps it needs another special permission, other than the recommended ones or group configuration.

The "solution" was to just remove the public key file.


I think you need to check sudoer file and add the user through root privileges. The sudoers file located at: /etc/sudoers(depends on linux base), contains the rules that users must follow when using the sudo command.

Read out for suoders for you version of Linux/Unix. you will get lot of material on web which definitely help you out


  • 1
    Since the command quite clearly does run (whence the transcripts), this answer is not relevant. Jun 2 '16 at 5:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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