portas de netstat de túnel reverso SSH

Question

Eu tenho uma pergunta sobre o túnel reverso do SSH.
Eu tenho um servidor Ubuntu com o sshd instalado.
Eu abro um túnel reverso do SSH de uma máquina remota. Nessa máquina, a conexão é reiniciada toda vez que o túnel é interrompido.

Sempre que um túnel é aberto, no servidor SSH posso ver duas conexões quando estou usando netstat . Uma conexão está ouvindo a porta do servidor interno. O outro está escutando em uma porta externa. Este último é o túnel SSH.

Como exemplo:

dado 203.0.113.10: meu servidor SSH e 10.34.23.12 meu PC remoto, 5000 a porta no meu PC remoto eu gostaria de acessar

ssh -R 1122:localhost:5000 [email protected]

Agora do lado do servidor eu tenho duas conexões de escuta, que se parece com isso

tcp6    0    :::1122              :::*                 LISTEN
tcp6    0    0 203.0.113.10:22    10.34.23.12:62734    ESTABLISHED

Eu uso / executo o comando nc do servidor, para verificar se o encapsulamento funciona

nc -z -v -w5 127.0.0.1 1122

Às vezes acontece que a conexão externa morre, então minha netstat de saída será

'tcp6    0    0 203.0.113.10:22    10.34.23.12:62734    ESTABLISHED'

Existe uma maneira de verificar qual túnel não tem uma porta externa escutando?

Quero dizer, há uma maneira de verificar quando meu porto 1122 morre?
Minha solução seria matar o processo sshd ligado ao túnel sem qualquer porta externa (10.34.23.12:62734). O problema é que eu tenho um outro túnel SSH nesta máquina que eu não gostaria de matar, então killall sshd não seria uma opção.

Obrigado!

Editar 1:

Solução possível : O comando netstat -lptun (e o netstat -pant sugerido por Paul) faz a ligação necessária para tentar resolver isso. Agora estou testando essa solução em produção.

#!/bin/sh
for pid in 'lsof -i -n | egrep '\<ssh\>' | awk '{print $2}''; do
  foundpid="$(netstat -lptun | grep :::11 | grep $pid)"
  if [ -z "$foundpid" ]
  then
    echo PID does not have any external port, killing the pid $pid
    kill $pid
  fi
done

    

Answer 1

O que você quer dizer com túnel "reverso"?

O parâmetro -R refere-se a um túnel iniciado remotamente, em vez do parâmetro -L que se refere a um túnel iniciado localmente.

Portanto, da perspectiva do cliente SSH, o parâmetro -R escutará o tráfego no terminal remoto (o que significa o servidor SSH). Quando o computador que executa o servidor SSH recebe tráfego na porta especificada (1122), esse computador envia essa informação através do software SSH. Especificamente, enviará essa informação através do túnel SSH. Conforme as informações são enviadas pelo túnel SSH, elas são criptografadas como todo o tráfego SSH. Além disso, uma pequena nota é adicionada a essa informação, que é (parafraseada aqui para dizer) "enviar o tráfego para a porta localhost 5000".

Quando o tráfego na outra extremidade do túnel SSH (neste exemplo, estamos falando agora do computador que executa o cliente SSH) recebe o tráfego, ele vê a nota sobre onde o tráfego irá. Então, esse computador alcança a porta 5000 localhost. Esse é o momento em que o nome do host "localhost" é resolvido. Portanto, neste exemplo, o "localhost" se referirá ao cliente SSH. (Em contraste, se você usou -L em vez disso, usando "localhost" como esse ainda seria interpretado pelo tráfego de recebimento final sobre o túnel, então a frase "localhost" seria interpretada pelo servidor SSH.)

Agora, sua melhor aposta é descobrir por que o túnel continua em colapso. Eu tenho usado normalmente túneis -L (locais), mas eu os ignorei por muitos dias antes (às vezes) decidindo usar um, e funciona muito bem. Eu presumo que o túnel possa ser desmoronado por qualquer um dos lados. Verifique os dois lados para os logs. Você pode querer verificar a documentação do OpenSSH para ver se existe algum tipo de timeout com o qual você está lidando.

Se você quiser ir a rota incompreensível de contornar o problema (ao invés de consertá-lo), matando o sshd e reiniciando, você pode fazer isso. Como observado, você não quer usar killall sshd porque pode haver outra conexão sshd. Você poderia tentar o pkill para eliminar qualquer programa que se conecta ao 203.0.113.10 (ou é 10.34.23.12?) Ou o número da porta (1122), mas, novamente, isso poderia levar a alguns falsos positivos. Você tem uma maneira mais segura de contornar o problema; Envolve até mesmo a mesma proposta de reiniciar o servidor.

Você poderia ter o sshd usando um arquivo de configuração personalizado ( -f configuration file ), ou você pode especificar informações de configuração na linha de comando (usando -o ). por exemplo:

sshd -o PidFile /var/run/sshd-remPC-tunnel.pid

(Além disso, você incluiria suas outras opções desejadas nessa linha de comando).

Isso coloca o número de identificação do processo nesse arquivo quando você inicia o sshd. Então você pode:

kill $( cat /var/run/sshd-remPC-tunnel.pid )

(Nota: Você pode precisar de permissão. Eu estou muito intencionalmente não me importando com isso, para manter minha resposta simples. Certifique-se de que sshd possa criar o arquivo, e você pode com sucesso cat quando você deseja kill it. Execute testes e faça as alterações necessárias.)

Nota: Você provavelmente NÃO quer apenas reiniciar automaticamente o túnel a cada 5 minutos (para automatizar a correção do problema). Porque, se você tiver uma conexão bem-sucedida, isso interromperá a conexão bem-sucedida. Então, imagino que isso seria algo planejado para ser feito manualmente.