Por que esse trabalho cron rsync + ssh está me causando erros de 'Permissão negada (chave pública)'?

Question

Faço backups frequentes em uma unidade local que desejo sincronizar diariamente com um servidor remoto.

O servidor de destino está configurado apenas para acesso por chave SSH (sem senha). Como minha chave SSH primária para esse servidor é protegida por senha, eucriou uma segunda chave SSH (não protegida por senha) + usuário para usar em backups autônomos- dessa forma, não preciso estar presente para inserir minha senha quando o cron for executado.

Estou usando cron e rsync, e todos os comandos funcionam individualmente, mas falham quando combinados.

O máximo que consegui enquanto a solução de problemas está em execução

env -i sh -c "rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ [email protected]:/backups/desktop/"

que retorna o erro

Permission denied (publickey).
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(226) [sender=3.1.0]

Alguma dica sobre como solucionar isso ainda mais?

---

Aqui está o que tentei até agora e estou sem ideias:

1. Cron definitivamente está rodandops aux | grep cron

2. Nada incomum em /var/log/syslogSep 7 13:22:01 desktop CRON[6735]: (tom) CMD (sh /home/tom/Documents/Scripts/offsite-backup)

3. SSH no Terminal para o servidor remoto enquanto o usuário de backup trabalhassh [email protected]

4. Executar o comando no Terminal funciona perfeitamentersync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ [email protected]:/backups/desktop/

5. Especificar manualmente o caminho para a chave do usuário de backups não tem efeitorsync -lrstRO --delete --exclude 'lost+found' -e 'ssh -i /home/tom/.ssh/backups-only' /Backups/auto-daily-backups/./ [email protected]:/backups/desktop/

6. Substituir o comando que não funciona por um comando de teste simples funcionaecho "Hello world" > ~/Desktop/test.txt

7. Gritar/xingar o computador não surtiu efeito (mas me fez sentir melhor temporariamente).

---

Editar 1:

Aqui está meu arquivo crontab e o script que ele chama.

...
# m h  dom mon dow   command
MAILTO=""
* * * * * sh /home/tom/Documents/Scripts/offsite-backup

e

#!/bin/bash

rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ [email protected]:/backups/desktop/

---

Editar 2:

Só para esclarecer, /var/log/auth.logno servidor de destino contém a linha Sep 11 08:23:01 <hostname> CRON[24421]: pam_unix(cron:session): session closed for user rootIsto é confuso porque não estou mais executando o cron a cada minuto localmente, mas uma nova entrada ainda aparece a cada minuto nos logs do servidor. Arquivos Crontab paratodosos usuários (incluindo root) no servidor estão vazios e não fazem nada.

Além disso, o usuário 'somente backups' foi criado apenas no servidor e com direitos limitados, com uma chave SSH dedicada copiada para minha máquina desktop. Presumo que este seja o caminho a seguir porque tudo funciona ao executar os comandos manualmente.

O arquivo crontab postado acima é para mim, usuário 'tom' em minha máquina desktop. Minha intenção é fazer com que ele chame o script que deve efetuar login no servidor como usuário 'somente backups'. Eu apenas tentei executar o script de backup (em vez do comando dentro dele) e ele conectou e funcionou com sucesso. Executei-o em meu desktop como usuário 'tom', mesmo usuário que criou o cron job que não funciona. Aqui está a saída do log do servidor correspondente ao login bem-sucedido

Sep 11 08:35:31 <hostname> sshd[25071]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
Sep 11 08:35:32 <hostname> sshd[25071]: Accepted publickey for backups-only from <desktop IP> port 54242 ssh2: RSA e2:e6:07:27:c1:continues...
Sep 11 08:35:32 <hostname> sshd[25071]: pam_unix(sshd:session): session opened for user backups-only by (uid=0)
Sep 11 08:35:32 <hostname> systemd-logind[638]: New session 12 of user backups-only.
Sep 11 08:36:00 <hostname> sshd[25133]: Received disconnect from <desktop IP>: 11: disconnected by user
Sep 11 08:36:00 <hostname> sshd[25071]: pam_unix(sshd:session): session closed for user backups-only

Answer 1

Como tudo está funcionando bem na linha de comando, o erro Permission denied (publickey)significa que a parte SSH rsyncestá usando um arquivo de identidade diferente do nome de usuário especificado.

DeComentário de janeirona pergunta original, podemos especificar o arquivo de identidade no rsynccomando usando -e 'ssh -i /path/to/identity.file' ....

Usar o comando abaixo para começar com um novo ambiente no cron e especificar o caminho completo para o arquivo aparentemente resolve o problema:

env -i sh -c "rsync -lrstRO --delete --exclude 'lost+found' -e 'ssh -i /home/tom/.ssh/backups-only' /Backups/auto-daily-backups/./ [email protected]:/backups/desktop/"

_{Ainda estou muito interessado nesta descoberta. Provavelmente tem a ver com o cron, o fato de ele começar com variáveis ​​de ambiente mínimas e o agente ssh. Estarei configurando o mesmo cenário em alguns dias para testá-lo e relatar.}

Answer 2

Acabei de resolver esse problema que me manteve ocupado.

Não é possível conectar em RSYNC via SSH, apesar de ter estipulado a identidade para SSH...Nada é feito... Rsync diz "permissão negada" e ssh me diz "read_passphrase: não é possível abrir/dev/tty: nenhum dispositivo ou endereço deste tipo"

Mas li um post que explicava que o crontab tem um ambiente próprio que não é igual ao root. Eu já sabia disso mas não entendi o impacto que isso poderia ter no SSH ao usar o SSH-AGENT

Mas minhas trocas de chaves SSH são feitas com PassPhrase ... então se o ambiente for diferente e meu RSYNC sobre SSH espera uma senha que não pode ser inserida => informações de depuração SSH também indicam o erro:

"debug1: read_passphrase: não é possível abrir /dev/tty: Esse dispositivo ou endereço não existe" => Bem, sim, não TTY = sem senha = não permitido

Na minha máquina, eu uso "Keychain" para iniciar o agente SSH, para que não seja necessário inserir novamente a senha toda vez que tento uma conexão remota. Keychain gera um arquivo que contém as seguintes informações

SSH_AUTH_SOCK = /tmp/ssh-PWg3yHAARGmP/agent.18891; exportar SSH_AUTH_SOCK; SSH_AGENT_PID=18893; exportar SSH_AGENT_PID;

==> O comando SSH-AGENT retorna as mesmas informações.

Então, no final das contas, são essas informações relacionadas à sessão atual que permitem futuras autenticações da sessão atual, sem a necessidade de inserir a senha porque já foi feita anteriormente e memorizada...

==> A solução está aí...basta no script lançado pelo crontab, e "source" o arquivo que contém esta informação ou fazê-lo na linha de comando ds o crontab ...

exemplo: 14 09 * * *. /home/foo/.keychain/foo.serveur.org-sh && scp -vvv -P 22 /tmp/mon_fic/toto.sh[e-mail protegido]:. >> / var / log / check_connexion.log 2> & 1 ou use o comando "source /home/foo/keychain/foo.server.org-sh" no script que inicia uma conexão usando SSH.

=> Com esta fonte, não se preocupe mais. As informações de SSH_AUTH_SOCK e SSH_AGENT_PID são carregadas no ambiente do Crontab e portanto são conhecidas, o RSYNC sobre SSH funciona sem nenhum problema.

Isso me manteve ocupado, mas agora funciona :)

Answer 3

Advertência para quem usa encaminhamento de agente SSH:

Se você observar esse comportamento ao depurar um script em um host remoto, é porque mesmo com o -e "ssh -i /path/to/key"sinalizador, o ssh usará sua chave local (encaminhada) em vez da chave do servidor.

Exemplo concreto: tenho um script no servidor de desenvolvimento que extrai dados do "servidor de dados" usando rsync sobre ssh. Quando eu entro no servidor de desenvolvimento e o executo, está tudo bem, mas ao executar no cron, recebo a permissão negada. Adicionando alguma verbosidade ao processo SSH (flag -vv), notei o seguinte:

debug2: key: /home/nighty/.ssh/id_rsa (0x562d8b974820),
debug2: key: /home/juanr/.ssh/id_rsa (0x562d8b962930), explicit
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/nighty/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp 1a:19:08:9f:80:16:b1:db:55:42:9a:52:b2:49:9b:0a
debug1: Authentication succeeded (publickey).

O que me deu uma pista aqui é que, por puro acaso, tenho um nome de usuário diferente no host local ("nighty") e no servidor de desenvolvimento ("juanr").

Observe como ele marca a chave no servidor de desenvolvimento como "explícita", mas ainda usa a chave encaminhada do meu laptop para fazer login. Fazer um ssh-copy-idneste ponto não resolve nada, porque simplesmente reinstala a chave encaminhada em vez da chave do desenvolvedor servidor. Se você usar ssh-copy-id com encaminhamento de agente, será necessário especificar qual chave instalar com o sinalizador -i: ssh-copy-id -i ~/.ssh/id_rsa.pub user@host.

Answer 4

Você já tentou o velho truque de limpar os arquivos hosts? Quero dizer:

rm ~/.ssh/known_hosts

Vale a pena tentar, pois o ssh irá reconstruí-lo e você se livrará de coisas obsoletas. É claro que você também pode remover as partes pertencentes a um determinado IP/host.

Mais perguntas: Seu cron job está sendo executado sob seu UID ou como usuário cron ou root?