☰

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

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

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

El servidor de destino está configurado para acceso mediante clave SSH (sin contraseña). Dado que mi clave SSH principal para ese servidor está protegida con una frase de contraseña, hecreó una segunda clave SSH (no protegida con contraseña) + usuario para usar en copias de seguridad desatendidas- De esta manera no tengo que estar presente para ingresar mi 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 he llegado mientras se ejecuta la solución de problemas

env -i sh -c "rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ [email protected]:/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 este problema aún más?

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

  1. Cron definitivamente se está ejecutandops aux | grep cron

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

  3. SSH en Terminal al servidor remoto mientras trabaja el usuario de respaldossh [email protected]

  4. Ejecutar el comando en Terminal funciona perfectamentersync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ [email protected]:/backups/desktop/

  5. Especificar manualmente la ruta a la clave de usuario de copias de seguridad no tiene ningún efectorsync -lrstRO --delete --exclude 'lost+found' -e 'ssh -i /home/tom/.ssh/backups-only' /Backups/auto-daily-backups/./ [email protected]:/backups/desktop/

  6. Reemplazar el comando que no funciona con un comando de prueba simple funcionaecho "Hello world" > ~/Desktop/test.txt

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

Edición 1:

Aquí está mi archivo crontab y el script al 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/./ [email protected]:/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 ejecuto cron cada minuto localmente, pero todavía aparece una nueva entrada cada minuto en los registros del servidor. Archivos crontab paratodoLos 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 en mi computadora de escritorio. Supongo que este es el camino a seguir porque todo funciona cuando se ejecutan los comandos manualmente.

El archivo crontab publicado arriba es para mí, el usuario 'tom' en mi computadora de escritorio. Mi intención es que llame al script que debería iniciar sesión en el servidor como usuario "solo para copias de seguridad". Intenté ejecutar el script de respaldo (en lugar del comando que contiene) 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á el resultado 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

Respuesta1

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

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

Usar el 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/./ [email protected]:/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. Configuraré el mismo escenario en un par de días para probarlo e informar.

Respuesta2

Acabo de solucionar este problema que me tenía ocupado..

No se puede conectar en RSYNC sobre 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: no hay dispositivo ni dirección de este tipo"

Pero leí un post que explicaba que el crontab tiene su propio entorno que no es lo mismo que root. Eso ya lo sabía pero no entendía el impacto que podría tener en SSH al usar 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 de 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 = sin contraseña = no permitido

En mi máquina uso "Keychain" para iniciar 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, son estas informaciones relacionadas con la sesión actual las que permiten futuras autenticaciones de la sesión actual, sin necesidad de introducir la contraseña porque ya se ha hecho previamente y está memorizada...

==> La solución está ahí...basta con el script lanzado por el crontab, y "obtener" el archivo que contiene esta información o hacerlo en la línea de comando ds el crontab...

ejemplo: 14 09 * * *. /home/foo/.keychain/foo.serveur.org-sh && scp -vvv -P 22 /tmp/mon_fic/toto.sh[correo electrónico protegido]:. >>/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 usando SSH.

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

Me ha mantenido ocupado pero ahora funciona :)

Respuesta3

Advertencia para quienes utilizan el reenvío de agentes SSH:

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 una secuencia de comandos 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 lo ejecuto desde cron, me deniegan el permiso. Al agregar algo de detalle al proceso SSH (flag -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 la pista 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 usa la clave reenviada desde mi computadora portátil para iniciar sesión. Hacer una ssh-copy-iden este punto no resuelve nada, porque simplemente reinstala la clave reenviada en lugar de la del desarrollador. servidor. Si usa ssh-copy-id con reenvío de agente, debe especificar qué clave instalar con el indicador -i: ssh-copy-id -i ~/.ssh/id_rsa.pub user@host.

Respuesta4

¿Has probado ya el viejo truco de limpiar los archivos de hosts? Quiero decir:

rm ~/.ssh/known_hosts

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

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

información relacionada