3

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 [email protected]

logged in as XXXX.

This fails:

root@server:/src# sudo ssh -T [email protected]

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.

2
  • 7
    Do you understand that with sudo ssh looks into root's home directory for public key?
    – Serge
    Commented Jun 2, 2016 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
    Commented Jun 2, 2016 at 23:29

3 Answers 3

5

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.

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

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.

-3

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

https://www.garron.me/en/linux/visudo-command-sudoers-file-sudo-default-editor.html

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

You must log in to answer this question.

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