Perché questo lavoro cron rsync + ssh mi dà errori "Autorizzazione negata (chiave pubblica)"?

Eseguo backup frequenti su un'unità locale che desidero sincronizzare quotidianamente su un server remoto.

Il server di destinazione è configurato solo per l'accesso alla chiave SSH (nessuna password). Poiché la mia chiave SSH primaria per quel server è protetta da passphrase, ho creato una seconda chiave SSH (non protetta da passphrase) + utente da utilizzare per backup non presidiati - in questo modo non devo essere presente per inserire la mia passphrase quando cron viene eseguito .

Sto usando cron e rsync e tutti i comandi funzionano singolarmente, ma falliscono quando combinati.

Il più lontano che ho mentre la risoluzione dei problemi è in esecuzione

env -i sh -c "rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ backups-only@XX.XX.XX.XX:/backups/desktop/"

che restituisce l'errore

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]

Qualche consiglio su come risolvere ulteriormente questo problema?

Ecco cosa ho provato finora e non ho idee:

1. Cron è decisamente funzionante ps aux | grep cron

2. Niente di insolito in / var / log / syslog Sep 7 13:22:01 desktop CRON[6735]: (tom) CMD (sh /home/tom/Documents/Scripts/offsite-backup)

3. SSH in Terminale su server remoto mentre l'utente di backup funziona ssh backups-user@XX.XX.XX.XX

4. L'esecuzione del comando in Terminale funziona perfettamente rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ backups-only@XX.XX.XX.XX:/backups/desktop/

5. La specifica manuale del percorso della chiave utente di backup non ha alcun effetto rsync -lrstRO --delete --exclude 'lost+found' -e 'ssh -i /home/tom/.ssh/backups-only' /Backups/auto-daily-backups/./ backups-only@XX.XX.XX.XX:/backups/desktop/

6. La sostituzione del comando non funzionante con un semplice comando di prova funziona echo "Hello world" > ~/Desktop/test.txt

7. Gridare / imprecare contro il computer non ebbe alcun effetto (ma mi fece sentire temporaneamente meglio).

Modifica 1:

Ecco il mio file crontab e lo script che chiama.

...
# 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/./ backups-only@XX.XX.XX.XX:/backups/desktop/

Modifica 2:

Giusto per chiarire, /var/log/auth.logsul server di destinazione contiene la riga Sep 11 08:23:01 <hostname> CRON[24421]: pam_unix(cron:session): session closed for user rootQuesto è confuso perché non eseguo più cron ogni minuto localmente, ma una nuova voce appare comunque ogni minuto nei registri del server. I file crontab per tutti gli utenti (incluso root) sul server sono vuoti e non fanno nulla.

Inoltre, l'utente 'solo backup' è stato creato solo sul server e con diritti limitati, con una chiave SSH dedicata copiata sul mio computer desktop. Suppongo che sia la strada da percorrere perché tutto funziona quando si eseguono i comandi manualmente.

Il file crontab pubblicato sopra è per me, l'utente "tom" sul mio computer desktop. Il mio intento è di farlo chiamare lo script che dovrebbe accedere al server come "solo backup" dell'utente. Ho appena provato a eseguire lo script di backup (anziché il comando al suo interno) e si è connesso e funzionato correttamente. L'ho eseguito sul mio desktop come utente 'tom', stesso utente che ha creato il processo cron che non funzionerà. Ecco l'output dal registro del server corrispondente a tale accesso riuscito

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

Poiché tutto funziona correttamente dalla riga di comando, l'errore Permission denied (publickey)indica che la parte SSH rsyncutilizza un file di identità diverso dal nome utente specificato.

Dal commento di Jan sulla domanda originale, possiamo specificare il file di identità nel rsynccomando usando -e 'ssh -i /path/to/identity.file' ....

L'uso del comando seguente per iniziare con un nuovo ambiente in cron e specificare il percorso completo del file risolve apparentemente il problema:

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

_{Sono ancora molto interessato a questa scoperta. Probabilmente ha a che fare con cron, il fatto che inizia con variabili di ambiente minime e l'agente ssh. Preparerò lo stesso scenario tra un paio di giorni per testarlo e riferire.}

Ho appena risolto questo problema che mi ha tenuto occupato ..

Impossibile connettersi in RSYNC su SSH, nonostante abbia stabilito l'identità per SSH ... Nulla è fatto ... Rsync dice "permesso negato" e ssh mi dice "read_passphrase: impossibile aprire / dev / tty: nessun dispositivo o indirizzo di questo tipo"

Ma ho letto un post che spiegava che crontab ha un suo ambiente che non è lo stesso di root. Lo sapevo già, ma non capivo l'impatto che poteva avere su SSH quando si utilizza SSH-AGENT

Ma i miei scambi di chiavi SSH sono fatti con PassPhrase ... quindi se l'ambiente è diverso e il mio RSYNC su SSH si aspetta una passphrase che non può essere inserita => Le informazioni di debug di SSH indicano anche l'errore:

"debug1: read_passphrase: impossibile aprire / dev / tty: nessun dispositivo o indirizzo" => Bene sì no TTY = no passphrase = non consentito

Sul mio computer utilizzo "Portachiavi" per avviare l'agente SSH, quindi non devo reinserire la passphrase ogni volta che provo una connessione remota. Il portachiavi genera un file che contiene le seguenti informazioni

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

==> Il comando SSH-AGENT restituisce le stesse informazioni.

Quindi, alla fine, sono queste informazioni relative alla sessione corrente che consentono le future autenticazioni della sessione corrente, senza la necessità di inserire la passphrase perché già eseguita in precedenza e memorizzata ...

==> La soluzione è lì ... è sufficiente nello script lanciato da crontab e per "sorgente" il file contenente queste informazioni o per farlo sulla riga di comando ds il crontab ...

esempio: 14 09 * * *. /home/foo/.keychain/foo.serveur.org-sh && scp -vvv -P 22 /tmp/mon_fic/toto.sh foo@my-server.fr:. >> / var / log / check_connexion.log 2> & 1 o utilizzare il comando "source /home/foo/keychain/foo.server.org-sh" nello script che avvia una connessione tramite SSH.

=> Con questo approvvigionamento, non ti preoccupare più. Le informazioni di SSH_AUTH_SOCK e SSH_AGENT_PID vengono caricate nell'ambiente di Crontab e sono quindi note, RSYNC su SSH funziona senza problemi.

Mi ha tenuto impegnato ma ora funziona :)

Avvertenza per coloro che utilizzano l'inoltro dell'agente SSH:

Se vedi questo comportamento durante il debug di uno script su un host remoto, è perché anche con il -e "ssh -i /path/to/key"flag, ssh userà la tua chiave locale (inoltrata) piuttosto che quella sul server.

Esempio concreto: ho uno script sul server dev che estrae i dati dal "server di dati" usando rsync su ssh. Quando accedo al server dev ed eseguo, tutto va bene, ma quando corro da cron, ottengo il permesso negato. Aggiungendo un po 'di verbosità al processo SSH (flag -vv) ho notato quanto segue:

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).

Ciò che mi ha indicato qui è che per puro caso, ho un nome utente diverso sull'host locale ("nighty") rispetto al server dev ("juanr").

Notare come contrassegna la chiave sul server dev come "esplicita", ma utilizza ancora la chiave inoltrata dal mio laptop per accedere. ssh-copy-idA questo punto fare una soluzione non risolve nulla, perché semplicemente reinstalla la chiave inoltrata anziché quella della dev server. Se si utilizza ssh-copy-id con inoltro agente, è necessario specificare quale chiave da installare con il flag -i: ssh-copy-id -i ~/.ssh/id_rsa.pub user@host.

Hai già provato il vecchio trucco di ripulire i file hosts? Intendo:

rm ~/.ssh/known_hosts

Vale la pena provare perché ssh lo ricostruirà e ti libererai di cose vecchie. Ovviamente puoi anche rimuovere le parti appartenenti a un determinato IP / Host.

Altre domande: il tuo cron job è in esecuzione sotto il tuo UID o è in esecuzione come cron utente o root?

Utilizzare lo rrsyncscript insieme a un tasto ssh dedicato come segue:

Server remoto

mkdir ~/bin
gunzip /usr/share/doc/rsync/scripts/rrsync.gz -c > ~/bin/rrsync
chmod +x ~/bin/rrsync

Computer locale

ssh-keygen -f ~/.ssh/id_remote_backup -C "Automated remote backup"      #NO passphrase
scp ~/.ssh/id_remote_backup.pub devel@10.10.10.83:/home/devel/.ssh

Computer remoto

cat id_remote_backup.pub >> authorized_keys

Prepara alla riga appena aggiunta quanto segue

command="$HOME/bin/rrsync -ro ~/backups/",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding

In modo che il risultato sia simile

command="$HOME/bin/rrsync -ro ~/backups/",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAA...vp Automated remote backup

LOCALE

Inserisci il tuo crontabseguente script con il xpermesso:

#!/bin/sh
echo ""
echo ""
echo "CRON:" `date`
set -xv
rsync -e "ssh -i $HOME/.ssh/id_remote_backup" -avzP devel@10.10.10.83:/ /home/user/servidor 

Fonte: http://www.guyrutenberg.com/2014/01/14/restricting-ssh-access-to-rsync/

Per provare a eseguire il debug aggiungere alla parte ssh "ssh -v" in questo modo è possibile ottenere la modalità dettagliata con alcune informazioni utili.

Modifica: dalla pagina man:

-v      Verbose mode.  Causes ssh to print debugging messages about its progress.  This is helpful in debugging connection,
             authentication, and configuration problems.  Multiple -v options increase the verbosity.  The maximum is 3.

Penso che non hai configurato correttamente il file sshd_config. Verificare che PermitRootLogin yese PubkeyAuthentication yes per la manutenzione remota.