¿Por qué este trabajo cron rsync + ssh me da errores de 'Permiso denegado (clave pública)'?

Realizo copias de seguridad frecuentes en una unidad local que quiero sincronizar diariamente con un servidor remoto.

El servidor de destino está configurado para acceso de clave SSH (sin contraseña) solamente. Como mi clave SSH principal para ese servidor está protegida con frase de contraseña, he creado una segunda clave SSH (no protegida con frase de contraseña) + usuario para usar para copias de seguridad desatendidas , de esta manera no tengo que estar presente para ingresar mi frase de contraseña cuando se ejecuta cron .

Estoy usando cron y rsync, y todos los comandos funcionan individualmente, pero fallan cuando se combinan.

Lo más lejos que tengo mientras se ejecuta la solución de problemas

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

que devuelve el error

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]

¿Algún consejo sobre cómo solucionar esto más?

Esto es lo que he intentado hasta ahora y no tengo ideas:

1. Cron definitivamente está corriendo ps aux | grep cron

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

3. SSH en la Terminal al servidor remoto mientras el usuario de respaldo trabaja ssh backups-user@XX.XX.XX.XX

4. Ejecutar el comando en la Terminal funciona perfectamente rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ backups-only@XX.XX.XX.XX:/backups/desktop/

5. La especificación manual de la ruta a la clave del usuario de copias de seguridad no tiene ningún efecto 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. Reemplazar el comando que no funciona con un comando de prueba simple funciona echo "Hello world" > ~/Desktop/test.txt

7. Gritar / insultar a la computadora no tuvo ningún efecto (pero me hizo sentir mejor temporalmente).

Editar 1:

Aquí está mi archivo crontab y el script que llama.

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

y

#!/bin/bash

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

Edición 2:

Solo para aclarar, /var/log/auth.logen el servidor de destino contiene la línea Sep 11 08:23:01 <hostname> CRON[24421]: pam_unix(cron:session): session closed for user rootEsto es confuso porque ya no estoy ejecutando cron cada minuto localmente, pero todavía aparece una nueva entrada cada minuto en los registros del servidor. Los archivos de Crontab para todos los usuarios (incluido el root) en el servidor están vacíos y no hacen nada.

Además, el usuario 'solo copias de seguridad' se creó solo en el servidor y con derechos limitados, con una clave SSH dedicada copiada a mi máquina de escritorio. Supongo que este es el camino a seguir porque todo funciona cuando se ejecutan los comandos manualmente.

El archivo crontab publicado anteriormente es para mí, el usuario 'tom' en mi máquina de escritorio. Mi intención es que llame al script que debe iniciar sesión en el servidor como usuario 'solo copias de seguridad'. Acabo de intentar ejecutar el script de copia de seguridad (en lugar del comando dentro de él) y se conectó y funcionó correctamente. Lo ejecuté en mi escritorio como usuario 'tom', el mismo usuario que creó el trabajo cron que no funcionará. Aquí está la salida del registro del servidor correspondiente a ese inicio de sesión exitoso

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

Como todo funciona bien desde la línea de comandos, el error Permission denied (publickey)significa que la parte SSH rsyncestá utilizando un archivo de identidad diferente al nombre de usuario especificado.

A partir del comentario de Jan sobre la pregunta original, podemos especificar el archivo de identidad en el rsynccomando usando -e 'ssh -i /path/to/identity.file' ....

El uso del siguiente comando para comenzar con un entorno nuevo en cron y especificar la ruta completa al archivo aparentemente resuelve el 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/"

_{Todavía estoy realmente interesado en este hallazgo. Probablemente tenga que ver con cron, el hecho de que comienza con variables de entorno mínimas y el agente ssh. Voy a configurar el mismo escenario en un par de días para probarlo e informar.}

Acabo de resolver este problema que me ha mantenido ocupado.

No se puede conectar en RSYNC a través de SSH, a pesar de haber estipulado la identidad para SSH ... No se hace nada ... Rsync dice "permiso denegado" y ssh me dice "read_passphrase: no se puede abrir / dev / tty: Ningún dispositivo o dirección de este tipo"

Pero leí una publicación que explicaba que el crontab tiene su propio entorno que no es lo mismo que root. Ya lo sabía, pero no entendía el impacto que podría tener en SSH al usar el SSH-AGENT

Pero mis intercambios de claves SSH se realizan con PassPhrase ... así que si el entorno es diferente y mi RSYNC sobre SSH espera una frase de contraseña que no se puede ingresar => La información de depuración SSH también indica el error:

"debug1: read_passphrase: no se puede abrir / dev / tty: No existe tal dispositivo o dirección" => Bueno, sí, no TTY = no frase de contraseña = no permitido

En mi máquina, utilizo "Llavero" para que se inicie el agente SSH, de modo que no tenga que volver a ingresar la frase de contraseña cada vez que intento una conexión remota. Keychain genera un archivo que contiene la siguiente información

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

==> El comando SSH-AGENT devuelve la misma información.

Entonces, al final, es esta información relacionada con la sesión actual la que permite autenticaciones futuras de la sesión actual, sin la necesidad de ingresar la frase de contraseña porque ya se hizo previamente y se memorizó ...

==> La solución está ahí ... es suficiente en la secuencia de comandos iniciada por el crontab, y para "fuente" el archivo que contiene esta información o para hacerlo en la línea de comandos ds el crontab ...

ejemplo: 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 use el comando "source /home/foo/keychain/foo.server.org-sh" en el script que inicia una conexión mediante SSH.

=> Con este abastecimiento, no más preocupaciones. La información de SSH_AUTH_SOCK y SSH_AGENT_PID se carga en el entorno de Crontab y, por lo tanto, se conoce que el RSYNC sobre SSH funciona sin ningún problema.

Me ha mantenido ocupado pero ahora funciona :)

Advertencia para aquellos que usan SSH Agent Forwarding:

Si ve este comportamiento al depurar un script en un host remoto, es porque incluso con el -e "ssh -i /path/to/key"indicador, ssh usará su clave local (reenviada) en lugar de la del servidor.

Ejemplo concreto: tengo un script en el servidor de desarrollo que extrae datos del "servidor de datos" usando rsync sobre ssh. Cuando inicio sesión en el servidor de desarrollo y lo ejecuto, todo está bien, pero cuando ejecuto desde cron, obtengo el permiso denegado. Añadiendo algo de verbosidad al proceso SSH (marca -vv) noté lo siguiente:

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

Lo que me dio pistas aquí es que, por pura casualidad, tengo un nombre de usuario diferente en el host local ("nighty") que en el servidor de desarrollo ("juanr").

Observe cómo marca la clave en el servidor de desarrollo como "explícita", pero aún utiliza la clave reenviada de mi computadora portátil para iniciar sesión. Hacer una ssh-copy-iden este momento no resuelve nada, porque simplemente reinstala la clave reenviada en lugar de la del desarrollador servidor. Si usa ssh-copy-id con el agente de reenvío, es necesario especificar qué tecla se debe instalar con la bandera -i: ssh-copy-id -i ~/.ssh/id_rsa.pub user@host.

¿Ya has probado el viejo truco de limpiar los archivos de host? Quiero decir:

rm ~/.ssh/known_hosts

Vale la pena intentarlo, ya que ssh lo reconstruirá y eliminarás las cosas obsoletas. Por supuesto, también puede eliminar las partes que pertenecen a una determinada IP / Host.

Más preguntas: ¿Su trabajo cron se ejecuta bajo su UID o se ejecuta como usuario cron o root?

Use el rrsyncscript junto con una clave ssh dedicada de la siguiente manera:

Servidor remoto

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

Computadora LOCAL

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

Computadora remota

cat id_remote_backup.pub >> authorized_keys

Anteponga a la línea recién agregada lo siguiente

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

Para que el resultado se vea como

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

LOCAL

Ponga en su crontabsiguiente script con xpermiso:

#!/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 

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

Para probar y depurar, agregue a la parte ssh "ssh -v" de esta manera, puede obtener el modo detallado con información útil.

Editar: desde la página del manual:

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

Creo que no ha configurado el archivo sshd_config correctamente. Verifique eso PermitRootLogin yesy PubkeyAuthentication yes para el mantenimiento remoto.