I have two Raspberry Pi (with Raspbian 7 and 8) connected to the same LAN. One has a data connection with an APC UPS. There's a couple of similar scripts in both machines to be ran under power failure situations. In /etc/apcupsd/onbattery and /etc/apcupsd/offbattery (from the UPS attached Pi) I have something similar to:

# [...] 
# after the e-mail stuff

# this is for the remote machine
/usr/bin/ssh -f pi@piac-pal_wired "sh -c '/home/pi/bin/my_script.sh > /dev/null 2>&1'"

# this is for the local machine, connected to the UPS

The local script works, but the one for the remote Pi doesn't (error: "Permission denied (publickey)." It does work if run it as normal user. Again, it doesn't work if run it with sudo, from the shell.

So I understand the problem is that the root user can't connect via SSH to the other machine using the shared keys method.

Running the sudo ssh command with -vv shows that the offered key is the one in /root/.ssh/id_rsa. The corresponding public key has been already added to the root/.ssh/authorized_keys on the remote machine and its /etc/ssh/sshd_config has been configured including:

RSAAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin without-password

If I change the last two lines above in:

PasswordAuthentication yes
PermitRootLogin yes

the root user from the UPS attached Pi can login to the remote Pi, but the command asks for a password, something that can't be accomplished when the apcupsd scripts will run unattended.

Any suggestion is more than welcome. Thanks.

EDIT: adding command output with ssh -vvv as suggested. I think the relevant part is at the end:

debug3: load_hostkeys: loaded 1 keys
debug1: Host '$HOSTNAME' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:7
debug1: ssh_ecdsa_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
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /root/.ssh/id_rsa (0x7f8c72a8)
debug2: key: /root/.ssh/id_dsa ((nil))
debug2: key: /root/.ssh/id_ecdsa ((nil))
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
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 RSA 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
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug3: no such identity: /root/.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).
  • Check the file/directory permissions of /root and /root/.ssh. Both should be drwx------ – xhienne Mar 21 '17 at 16:31
  • 1
    post the sshd logs on the server side? – ilkkachu Mar 21 '17 at 16:38
  • 1
    "The corresponding public key has been already added to the root/.ssh/authorized_keys on the remote machine" - but seems not to be accepted by the remote. Please double check if - it is the correct key and - there is no line break and - authorized_keys file is -rw-------. Best way to make sure is to allow rootto login via password, then do sudo ssh-copy-id <remote>on the local machine, and afterwards change access back to PermitRootLogin without-password. – ridgy Mar 21 '17 at 17:07
  • 1
    Wait... Wait... sudo ssh -i /home/pi/.ssh/id_rsa ... works! Setting explicitly the pi user's key works... but why? There's even no need for a .ssh dir into server's /root... – dentex Mar 21 '17 at 17:12
  • 1
    Yes, adding the client's root key to the server's /home/pi/.ssh/authorized_keys makes the script working also with the initial sintax... So: the /root/.ssh folder is NOT taken into consideration possibly because I was calling via ssh the pi user. Must be this one. – dentex Mar 21 '17 at 17:21

The problem was the ssh command was calling the pi user, not the root one, so, the checked authorized_keys was the one in /home/pi/.ssh, not the one in /root/.ssh. All I needed to do was adding the client's root key to the server's /home/pi/.ssh/authorized_keys. That's all.

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.