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

У меня вопрос по обратному туннелю 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

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 минут (для автоматизации решения проблемы). Потому что, если у вас есть успешное соединение, это нарушит успешное соединение. Так что я думаю, что это будет сделано вручную.

Другие вопросы по тегам