Порты netstat обратного туннеля SSH

Question

У меня вопрос по обратному туннелю SSH.
У меня есть сервер Ubuntu с установленным sshd.
Я открываю обратный туннель SSH с удаленной машины. На этой машине соединение перезапускается каждый раз, когда туннель прерывается.

Всякий раз, когда открывается туннель, на сервере SSH я вижу два соединения, когда я использую netstat . Одно соединение прослушивает порт внутреннего сервера. Другой слушает на внешнем порту. Последний - туннель SSH.

Как пример:

учитывая 203.0.113.10: мой SSH-сервер и 10.34.23.12 мой удаленный ПК, 5000 порт на моем удаленном ПК, к которому я хотел бы получить доступ

ssh -R 1122:localhost:5000 serveruser@203.0.113.10

Теперь на стороне сервера есть два прослушивающих соединения, которые выглядят так

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

Я использую / запускаю команду nc с сервера, чтобы проверить работоспособность туннеля

nc -z -v -w5 127.0.0.1 1122

Иногда случается, что внешнее соединение умирает, поэтому мой вывод netstat будет

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

Есть ли способ проверить, какой туннель не имеет прослушивания внешнего порта?

Я имею в виду, есть ли способ проверить, когда умирает мой порт 1122?
Моим решением было бы уничтожить процесс sshd, связанный с туннелем без какого-либо внешнего порта (10.34.23.12:62734). Проблема в том, что у меня есть другой SSH-туннель на этой машине, который я не хотел бы убивать, поэтому killall sshd не будет вариантом.

Спасибо!

Изменить 1:

Возможное решение: команда netstat -lptun (и предложенный Полом netstat -pant) выполняет связывание, которое мне нужно для решения этой проблемы. Сейчас я тестирую это решение в производстве.

#!/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

Что вы подразумеваете под "обратным" туннелем?

Параметр -R относится к дистанционно инициируемому туннелю, а не параметр -L, который относится к локально инициируемому туннелю.

Таким образом, с точки зрения клиента SSH, параметр -R будет прослушивать трафик на удаленном конце (что означает сервер SSH). Когда компьютер, на котором работает сервер SSH, получает трафик через указанный порт (1122), этот компьютер отправит эту информацию через программное обеспечение SSH. В частности, он отправит эту информацию через туннель SSH. Когда информация отправляется через туннель SSH, она шифруется, как и весь трафик SSH. Кроме того, к этой информации добавлено небольшое примечание, которое (перефразировано здесь, чтобы сказать) "отправляет трафик на локальный порт 5000".

Когда трафик на другом конце туннеля SSH (в этом примере мы сейчас говорим о компьютере, на котором работает клиент SSH) получает трафик, он видит примечание о том, куда будет идти трафик. Итак, этот компьютер достигает локального порта 5000. Это момент времени, когда имя хоста "localhost" будет разрешено. Итак, в этом примере "localhost" будет ссылаться на клиента SSH. (Напротив, если вы используете вместо этого -L, использование "localhost", как этот, все равно будет интерпретироваться конечным получателем трафика через туннель, поэтому SSH-сервер будет интерпретировать фразу "localhost".)

Теперь лучше всего понять, почему туннель рушится. Я обычно использовал -L (локальные) туннели, но я просто игнорировал их в течение многих дней, прежде чем (иногда) решил использовать один, и он прекрасно работает. Я предположил бы, что туннель может быть разрушен любым концом. Проверьте обе стороны для регистрации. Вы можете проверить документацию OpenSSH, чтобы узнать, есть ли какое-то время ожидания, с которым вы имеете дело.

Если вы хотите пойти по неприемлемому пути обхода проблемы (вместо ее устранения), убив sshd и перезапустив его, вы можете сделать это. Как уже отмечалось, вы не хотите использовать killall sshd потому что может быть другое соединение sshd. Вы можете попробовать pkill чтобы устранить любую программу, соединяющуюся с 203.0.113.10 (или это 10.34.23.12?) или номер порта (1122), но, опять же, это может привести к ложным срабатываниям. У вас есть более безопасный способ обойти проблему; это даже включает ваш предложенный подход перезапуска сервера.

Вы можете использовать sshd, используя пользовательский файл конфигурации (-f configuration file), или вы можете указать информацию о конфигурации в командной строке (используя -o). например:

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

(Кроме того, вы должны включить другие необходимые параметры в этой командной строке.)

Это помещает идентификационный номер процесса в этот файл при запуске sshd. Тогда ты можешь:

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

(Примечание: вам, возможно, придется гадить с разрешениями. Я намеренно не беспокоюсь об этом, чтобы мой ответ был простым. Убедитесь, что sshd может создать файл, и вы можете успешно его cat когда захотите его kill . Запустите тесты и внесите все необходимые изменения.)

Примечание. Возможно, вы НЕ хотите просто автоматически перезапускать туннель каждые 5 минут (для автоматизации решения проблемы). Потому что, если у вас есть успешное соединение, это нарушит успешное соединение. Так что я думаю, что это будет сделано вручную.