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
/home/pi/bin/my_script.sh


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


If I change the last two lines above in:

PasswordAuthentication 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_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
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: authmethod_lookup publickey
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
• post the sshd logs on the server side? – ilkkachu Mar 21 '17 at 16:38
• "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
• 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
• 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.