Вопросы Теги

Как обратное Соединение SSH может быть сохранено доступным в течение долгого времени?

У меня есть сервер, и у меня есть рабочий стол, который находится позади неловкой сети. Для доступа к моему рабочему столу удаленно, у меня есть он, поддерживают обратное соединение SSH к моему серверу, и затем я могу SSH к своему серверу и SSH на рабочий стол через любой обратный-SSH порт, который он использует.

А именно, мой рабочий стол запускает крошечный скрипт Bash как это:

#!/bin/bash
while true; do
    ssh -X -R 19123:localhost:22 http://www.example.pro/
    sleep 1000
done

Затем на сервере рабочий стол является доступным использованием команды как следующее:

ssh localhost -p 19123

Это, кажется, хорошо работает. Соединение сохраняется и восстанавливается надежно, и я могу выполнить команды и т.п. на сервере от рабочего стола, проверив, что соединение действительно живо.

Однако через некоторое время, как несколько дней, рабочий стол становится недоступным с сервера. На рабочем столе соединение живо, но на сервере возвращается следующее сообщение об ошибке:

ssh: connect to host localhost port 19123: Connection refused

Кто-либо может предположить то, что могло бы происходить? И что еще более важно, кто-либо может предложить, как это может быть предотвращено, учитывая, что сервер не может быть перезапущен регулярно и т.п.?

0
задан 12 July 2018 в 10:28

2 ответа

Имейте свой ssh, отправляют пакет проверки активности время от времени для помощи.

В Вашем ~/.ssh/config файл добавляет следующее:

Host *
ServerAliveInterval 15

Это должно быть установлено и на сервере и на клиенте.

Можно изменить то число выше на что-либо, что Вы хотите. Это установлено в течение каждых 15 секунд, и мои серверные соединения, кажется, остаются в живых без любых проблем.

Надеюсь, это поможет!

3
ответ дан 28 October 2019 в 08:50

Как @Terrance говорит, необходимо использовать проверку активности для хранения соединения открытым. Однако для увеличения устойчивости я также рекомендовал бы использовать autossh контролировать соединения SSH. Поскольку это не установлено по умолчанию, необходимо будет установить его с sudo apt install autossh.

С установленным, можно затем выполнить его как так:

/usr/bin/autossh -f -o "ServerAliveInterval 900" -TN -R30582:localhost:5724 tunnel@bobsrockets.io

Это создает туннель ssh к tunnel@bobsrockets.io. Обратите внимание что любые опции это autossh не понимает передаются до ssh самостоятельно.

Это также не выделяет псевдотерминал, который экономит на ресурсах.

Это хорошо, но мы можем пойти один лучше. Для создания этого постоянным и автоматическим мы можем настроить systemd сервис. Создайте файл внутри /etc/systemd/system с суффиксом .service, и вставленный это что-то вроде этого:

[Unit]
Description=SSH tunnel

[Service]
Type=forking
Environment=AUTOSSH_PIDFILE=/var/run/ssh-tunnel/ssh-tunnel.pid
PIDFile=/var/run/ssh-tunnel/ssh-tunnel.pid
ExecStartPre=/bin/mkdir -p /var/run/ssh-tunnel
ExecStartPre=-/bin/chown username:username /var/run/sbrl-ssh-tunnel
ExecStart=/bin/sh -c 'until ping -c1 bobsrockets.io &>/dev/null && sleep 5; do :; done && /usr/bin/autossh -f -o "UserKnownHostsFile /home/username/.ssh/known_hosts" -o "IdentityFile /home/username/.ssh/ssh-tunnel_ed25519" -o "PubkeyAuthentication=yes" -o "PasswordAuthentication=no" -o "ServerAliveInterval 900" -TN -R30582:localhost:5724 -p 7261 ssh-tunnel@bobsrockets.io'

[Install]
WantedBy=network-online.target

Несколько вещей знамениты здесь:

  • username должен быть заменен учетной записью локального пользователя это autossh будет работать под
  • Я отключаю аутентификацию по паролю и включаю аутентификацию с открытым ключом здесь, так, чтобы она могла запуститься без любого внешнего вмешательства. Удостоверьтесь, что Вы создаете специальную учетную запись на сервере (ssh-tunnel в моем примере), который не имеет оболочки для него, чтобы войти в систему, и удостовериться, Вы настраиваете открытый ключ и тестируете ее прежде, чем установить этот сервисный файл.
  • -p 7261 используется для определения целевого порта на удаленном сервере для соединения с. Обновите его в случае необходимости, иначе удалите если не требуемый.
  • Я указываю местоположение known_hosts файл с UserKnownHostsFile опция, работая как systemd сервис autossh не кажется способным найти его иначе. Удостоверьтесь, чтобы Вы указали на него на подходящее known_hosts файл так, чтобы соединение SSH могло быть открыто автоматически.
  • Я использую немного сценариев оболочки (until ping -c1 bobsrockets.io &>/dev/null && sleep 5; do :; done) гарантировать, что это ожидает, пока мы не можем достигнуть целевого узла прежде, чем запустить autossh. Я встретился с проблемами иначе.
  • -f используется здесь для получения autossh разветвляться. Это избегает бесполезного sh процесс от лжи вокруг.

Источники

  • Я вел блог об этом здесь
  • Я первоначально прочитал эту статью, которая объясняет еще некоторые различные варианты autossh более подробно, должны Вы нуждаться в них.
2
ответ дан 28 October 2019 в 08:50

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

Похожие вопросы: