crontab para fazer backup distante

É verdade que é um pouco de especulação, porque não sei como todos os seus SSH e askpass estão configurados, mas, como essa é a resposta para facilmente 90% das perguntas relacionadas ao crontab aqui:

Quando você executa algo do crontab, o ambiente é diferente de quando você executa da sua sessão. Essa é uma limitação arquitetônica do crontab; ele simplesmente não inicia um shell de login interativo, mas simplesmente executa os comandos especificados como seu usuário, o que não é a mesma coisa.

Emparelhado com o fato de que você está fazendo duas alterações de usuário (por meio do seu double- sudo), meu palpite é que scp/ ssholha os arquivos de configuração errados, ou não consegue lê-los. Realmente não importa: você realmente gostaria de fazer isso sem o sshpasse sem o sudo:

1. Este é claramente um trabalho de sistema – o fato de que você precisa se tornar root através do uso de sudomostra isso sem sombra de dúvidas. Então, em vez do crontab do seu usuário, este deve ser o crontab do root. Isso remove completamente a necessidade de sudo.
2. Como você parece controlar o servidor de backup, você claramente não deveria usar autenticação de senha (já que sua senha como parte da linha de comando pode ser lida por qualquer processo, incluindo scripts PHP desonestos etc. por meio de coisas simples como ps -AFenquanto o trabalho de backup estiver em execução). Eu consideraria essa senha comprometida agora e sugeriria fortemente que você a alterasse imediatamente. Especialmente porque você acabou de nos dizer um caractere da sua senha e isso torna mais fácil para qualquer parte interessada ter certeza de que encontrou a correta. Além disso, certifique-se de que suas senhas sejam geradas com segurança e não apenas algo como "nomedeusuárioSenha!" ou outra combinação fácil de testar automaticamente. (Guiadamente) Força bruta de senhas ainda é uma coisa.
   A autenticação de chave pública sem senha para o usuário root é realmente fácil de configurar ( sudo -i -H ssh-keygen, basta pressionar enter para aceitar os padrões e não especificar uma senha; então , digite a senha uma vez, pronto). Você quer fazer isso como root, já que você quer que essas chaves estejam disponíveis (apenas!) para o usuário root, não para seu usuário local normal (que não tem nada a ver com poder fazer login sem saber a senha). Não há desculpas aqui.sudo -H -i ssh-copy-id [email protected]
3. Como isso reduz a quantidade de surpresas no ambiente, eu pessoalmente recomendo (isso é uma preferência, então, hm, ouça ou não) que você evite usar crontabs completamente e opte pelo mais fácil de configurar systemd-timer. (Isso tem muitas vantagens, pois o ambiente fica mais parecido com uma sessão interativa, mas você também obtém um melhor registro, a capacidade de dizer algo como "OK, faça o backup todo dia útil às 00:13:00 +- 10min aleatórios e toda inicialização logo antes da execução do nginx"). Se você estiver interessado em fazer isso funcionar e esta instrução não for útil (e você não encontrar uma resposta existente aqui), abra uma nova postagem de pergunta!
4. Sua scpparece ser, no geral, uma solução ruim: ela copia o backup inteiro, quer todos os arquivos (ou algum) tenham sido alterados ou não, redefine o tempo de modificação (que, a propósito, você nginxentrega aos clientes, o que significa que você está invalidando os caches deles todos os dias, colocando carga desnecessária no seu servidor) e não é cuidadoso com atributos de arquivo. No mínimo aqui, você usaria rsyncem vez de scp. Mais realisticamente, no entanto:

Além de alterar seu método de autenticação, o que você realmente precisa fazer aqui, e de alterar o usuário que tenta baixar o backup, você provavelmente deveria pensar nisso de uma forma menos "scripts personalizados que funcionam (ou não) para você hoje", para ser honesto.

Anotei o que eu faria na sua situação. Veja minha resposta aqui:
Como faço backups diários automaticamente e em cada desligamento, e os restauro em outro lugar diariamente e na inicialização?