autossh em / etc / inittab

Question

Eu configurei o túnel ssh para conectar um computador de destino atrás do NAT. Eu coloquei o seguinte em / etc / inittab no computador:

tu:2345:respawn:/usr/bin/autossh -M 20000 -f -n -N -T -R 6790:localhost:22 [email protected]

Funciona, ou seja, posso conectar-me emitindo ssh -p 6790 me @ localhost. Mas de vez em quando recebo a seguinte mensagem no computador de destino:

INIT: Id "tu" respawning too fast, disabled for 5 minutes

Em / var / log / secure no servidor, posso ver o seguinte:

Oct 29 03:11:15 vm sshd[19725]: Accepted publickey for me from 90.179.155.74 port 37416 ssh2
Oct 29 03:11:15 vm sshd[19727]: Received disconnect from 90.179.155.74: 11: disconnected by user
Oct 29 03:17:04 vm sshd[20892]: Accepted publickey for me from 90.179.155.74 port 40116 ssh2
Oct 29 03:17:15 vm sshd[20896]: error: bind: Address already in use
Oct 29 03:17:19 vm sshd[20896]: error: channel_setup_fwd_listener: cannot listen to port: 20000

E isso continua. Alguma ideia do que pode estar errado?

    

Answer 1

Ok, encontrei a resposta. Se o autossh for chamado com a opção -f, ele se forçará como um daemon e o processo pai será encerrado. Daí, init reaparece novamente ... e novamente ...

Eu acho que eu não deveria ter usado o autossh, mas apenas o ssh, porque o respaw é feito pelo init e não há, eu acho, nenhuma necessidade de outro auto-reconhecimento por autossh. Eu mudei a linha para apenas tu:2345:respawn:/usr/bin/ssh -n -N -T -R 6791:localhost:22 [email protected]

Também adicionei

ServerAliveInterval 15
ServerAliveCountMax 2

em / etc / ssh / ssh_config para manter a conexão ativa.

Acho que essa configuração pode funcionar muito bem.

    

Answer 2

Se usar o bom e velho ssh em vez de autossh , como você diz em sua própria resposta, funciona bem, ótimo, você pode parar de ler.

Eu tenho estado muitas vezes na situação que nenhuma quantia de afinação de configuração de ssh / sshd ajudaria, de vez em quando meu túnel fiel seria cair em oposição a bater suavemente, não importa o que. Em todas essas situações autossh funcionou como um encanto.

Então, se você retornar a autossh , aqui está como eu o uso. Em vez de inittab , eu o executo dentro de uma sessão screen . Crie um script simples, vamos chamá-lo de autossh.sh :

#!/bin/sh
tunnelsite=autossh-host1
if ! screen -ls | grep -F .$tunnelsite >/dev/null; then
    screen -d -m -S $tunnelsite autossh -N $tunnelsite
fi

O script apenas verifica se existe uma sessão de tela com o nome dado já em execução, saia dela sim, caso contrário, crie-a.

Programe um cron job para executar periodicamente:

*/15 * * * * AUTOSSH_PORT=0 /path/to/autossh.sh

O AUTOSSH_PORT=0 é apenas para solucionar um problema estranho que eu tive em um Mac OS X. Você pode omitir isso, mas estou usando esse método no Linux também sem problemas.

Por fim, uma dica de segurança: a menos que você já esteja fazendo isso, eu estou usando uma chave ssh dedicada para autenticar o túnel com autossh e restringindo a autorização de chave em .ssh/authorized_keys com essas opções:

command="/bin/false",no-agent-forwarding,no-X11-forwarding,no-pty ssh-rsa AAAA...

Dessa forma, mesmo que sua chave seja comprometida, ela só poderá ser usada para criar o túnel.

Espero que isso ajude. Na verdade, tenho um projeto de script no GitHub para facilitar essa configuração. link