cronjob abrindo então IMEDIATAMENTE fechando túnel ssh

Question

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

Mais e mais, com 0-1 segundo entre eles. Eu quero que essa conexão seja aberta ... Como posso manter isso em aberto?

Meu código se parece com isso para o cron (Sim, eu sei que está sendo executado 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 matá-lo em um momento apropriado em outro script, mas a menos que eu execute o comando acima manualmente a partir da linha de comando, cron imediatamente mata-lo.

    

Answer 1

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 ) < strong> if você está executando o shell script como root.

2. Os ambientes crontab são muito diferentes dos usuários. Por isso, é sempre necessário usar caminhos completos para os 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 os sinalizadores -t -t ao comando ssh (sim, duas vezes) porque isso suprime o erro que um tty não pode ser alocado.

4. Embora eu tenha certeza dos erros anteriores, há um que pode causar problemas, não tenho certeza e não tenho tempo para testá-lo: você tem dois sinalizadores> -p em seu comando, e não tenho certeza se eles foram corretamente interpretados pelo shell. Se eu fosse você, colocaria o comando ssh , com todas as suas opções, dentro de aspas simples ou duplas, só para tentar.

A objeção anterior e o uso de uma senha aberta podem ser evitados se você usar chaves criptográficas, nesse caso você pode adicionar ao seu arquivo .ssh / config 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 o one-liner se tornaria

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