☰

cronjob abriendo y luego cerrando INMEDIATAMENTE el túnel ssh

tag-icon • tag-icon linux bash ssh cron tunnel
cronjob abriendo y luego cerrando INMEDIATAMENTE el túnel ssh

Estoy intentando escribir un script que abra un túnel SSH a un servidor público. Tengo todo escrito y funcionando correctamente, pero la conexión no parece llegar a mi servidor. Los registros dicen cosas como:

Jun 8 21:00:01 <hostname> CRON[xxxx]: session opened for user <user> by (uid=0)
Jun 8 21:00:01 <hostname> CRON[xxxx]: session closed for user <user>

Una y otra vez, con 0-1 segundos de por medio. Quiero que esta conexión diga abierta... ¿Cómo puedo mantenerla abierta?

Mi código se ve así para el cron (Sí, sé que se ejecuta cada minuto):

* * * * * /bin/bash /home/<user>/ssh

Mi código para el check-in es:

sshpass -p <password> ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null <user>@<url> -p <port> -R222<random_number>:localhost:22

Entonces, nuevamente, ¿cómo puedo mantener abierta esta conexión? Tengo un mecanismo para eliminarlo en el momento adecuado en otro script, pero a menos que ejecute el comando anterior manualmente desde la línea de comandos, cron lo elimina inmediatamente.

Respuesta1

Hay varios errores en su secuencia de comandos crontab.

  1. El que está causando las desconexiones es el hecho de que el script no solo necesita permiso de ejecución, sino también el bit suid establecido (sudo chmod 4755 /pah/to/script)siestá ejecutando el script de shell como root.

  2. Los entornos crontab son muy diferentes a los de los usuarios. Por lo tanto siempre es necesario utilizarcaminos completosa los comandos:

    /usr/bin/sshpass -p <password> /usr/bin/ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null <user>@<url> -p <port> -R222<random_number>:localhost:22

  3. Deberías agregar las banderas-t -thaciasshcomando (sí, dos veces) porque esto suprime el error de que no se puede asignar un tty.

  4. Si bien estoy seguro de los errores anteriores, hay uno quepodríacausar problemas, no estoy seguro y no tengo tiempo para probarlo: tienes dos-pagbanderas en su comando, y no estoy seguro de que el shell las interprete correctamente. Si yo fuera tú, colocaría elsshcomando, con todas sus opciones, entre comillas simples o dobles, solo para probar.

La objeción anterior y el uso de una contraseña abierta podrían evitarse si utilizaras claves criptográficas, en cuyo caso podrías agregar a tu.ssh/configarchiva las siguientes lineas:

   Host ShortName
             HostName The.Full.HostName.com
             User yourname
             Port your-non-standard-port
             IdentityFile /path/to/crypto/keyù
             IdentitiesOnly yes

y luego la frase se convertiría en

  /usr/bin/ssh -t -t -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -R222<random_number>:localhost:22 ServerName

información relacionada