Eu tenho dois Raspberry Pi (com Raspbian 7 e 8) conectados à mesma LAN. Um deles tem uma conexão de dados com um no-break da APC. Há alguns scripts semelhantes em ambas as máquinas para serem executados em situações de falha de energia. Em /etc/apcupsd/onbattery e /etc/apcupsd/offbattery (do UPS anexado Pi) eu tenho algo semelhante a:
# [...]
# 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
O script local funciona, mas o do Pi remoto não (erro: "Permissão negada (publickey)".
Ele funciona se for executado como usuário normal. Novamente, não funciona se você executar com sudo , a partir do shell.
Então, eu entendo que o problema é que o usuário root não pode se conectar via SSH à outra máquina usando o método de chaves compartilhadas.
A execução do comando sudo ssh com -vv mostra que a chave oferecida é a que está em /root/.ssh/id_rsa . A chave pública correspondente já foi adicionada ao root/.ssh/authorized_keys na máquina remota e seu /etc/ssh/sshd_config foi configurado, incluindo:
RSAAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin without-password
Se eu alterar as duas últimas linhas acima em:
PasswordAuthentication yes
PermitRootLogin yes
o usuário root do Pi conectado à UPS pode acessar o Pi remoto, mas o comando solicita uma senha, algo que não pode ser feito quando os scripts do apcupsd serão executados sem supervisão.
Qualquer sugestão é mais que bem-vinda. Obrigado.
EDIT: adicionando a saída do comando com ssh -vvv como sugerido.
Eu acho que a parte relevante está no final:
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
debug1: SSH2_MSG_SERVICE_REQUEST sent
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).
O problema era que o comando ssh estava chamando o usuário pi , não o root , então, o authorized_keys marcado era o de /home/pi/.ssh , não o de /root/.ssh . Tudo o que eu precisava fazer era adicionar a chave raiz do cliente ao /home/pi/.ssh/authorized_keys do servidor. Isso é tudo.