☰

cronjob abrindo e fechando IMEDIATAMENTE o túnel ssh

tag-icon • tag-icon linux bash ssh cron tunnel
cronjob abrindo e fechando IMEDIATAMENTE o túnel ssh

Estou tentando escrever um script que abra um túnel SSH para um servidor público. Tenho tudo escrito e funcionando corretamente, mas a conexão não parece estar chegando ao meu servidor. Os registros dizem coisas 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>

Repetidamente, com 0-1 segundos entre eles. Quero que esta conexão diga aberta.... Como posso manter isso aberto?

Meu código fica assim para o cron (sim, eu sei que está rodando a cada minuto):

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

Meu código para o check-in é:

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

Então, novamente, como posso manter essa conexão aberta? Eu tenho um mecanismo para eliminá-lo em um momento apropriado em outro script, mas a menos que eu execute o comando acima manualmente na linha de comando, o cron o mata imediatamente.

Responder1

Existem vários erros no seu script crontab.

  1. O que está causando as desconexões é o fato de que o script precisa não apenas de permissão de execução, mas também do conjunto de bits suid (sudo chmod 4755 /pah/to/script)sevocê está executando o shell script como root.

  2. Os ambientes crontab são muito diferentes dos dos usuários. Portanto, é sempre necessário usarcaminhos completosaos 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. Você deve adicionar as bandeiras-t -tpara osshcomando (sim, duas vezes) porque isso suprime o erro de que um tty não pode ser alocado.

  4. Embora eu esteja certo dos erros anteriores, há um quepodercausar problemas, não tenho certeza e não tenho tempo para experimentar: você tem dois-psinalizadores em seu comando e não tenho certeza se eles foram interpretados corretamente pelo shell. Se eu fosse você, colocaria osshcomando, com todas as suas opções, entre aspas simples ou duplas, só para tentar.

A objeção anterior e o uso de uma senha aberta poderiam ser evitados se você usasse chaves criptográficas, caso em que você poderia adicionar ao seu.ssh/configarquive as seguintes linhas:

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

e então a linha única se tornaria

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

informação relacionada