Як надійно тримати тунель SSH відкритим?

Я використовую тунель SSH з роботи, щоб обійти різні ідотичні брандмауери (це нормально з моїм начальником :)). Проблема полягає в тому, що через деякий час ssh-з'єднання зазвичай висить, і тунель порушений.

Якби я міг хоча б автоматично контролювати тунель, я міг би перезапустити тунель, коли він висить, але я навіть не придумав, як це зробити.

Бонусні бали тому, хто може мені підказати, як запобігти моєму ssh-зв’язку, звісно!

Здається, що вам потрібно автошшш . Це дозволить контролювати ssh-тунель і перезапустити його за потребою. Ми використовуємо його пару років, і, здається, він працює добре.

autossh -M 20000 -f -N your_public_server -R 1234:localhost:22 -C

Детальніше про параметр -M тут

Усі стаціонарні брандмауери забувають про з'єднання після того, як деякий час не бачать пакет для цього з'єднання (щоб запобігти переповненню таблиць стану, коли обидва кінці загинули, не закриваючи з'єднання). Більшість реалізацій TCP надсилатиме пакет збереженого пакету через довгий час, не чуючи з іншого боку (2 години - це загальне значення). Якщо, однак, є потужний брандмауер, який забуде про з'єднання перед тим, як пакети зберігатимуть можливість збереження, довгоживуче, але непрацююче з'єднання загине.

Якщо це так, рішення полягає в тому, щоб не допустити з’єднання в режимі очікування. У OpenSSH є параметр під назвою ServerAliveInterval, який може бути використаний для запобігання з’єднанню в режимі очікування занадто довго (як бонус, він виявить, коли однолітник помер раніше, навіть якщо з'єднання не працює).

На власному комп'ютері Mac або Linux налаштуйте ваш ssh кожен раз на 3 хвилини. Відкрийте термінал і перейдіть у свій будинок свого невидимого .ssh:

cd ~/.ssh/ 

потім створіть конфігураційний файл 1 рядка за допомогою:

echo "ServerAliveInterval 180" >> config

Ви також повинні додати:

ServerAliveCountMax xxxx (high number)

за замовчуванням - 3, тому ServerAliveInterval 180 припинить надсилання через 9 хвилин (3 з 3-хвилинного інтервалу, визначеного ServerAliveInterval).

Я використовував наступний сценарій Bash, щоб продовжувати нерестувати нові тунелі ssh, коли попередній відмирає. Використання сценарію зручно, коли ви не хочете або не можете встановити додаткові пакети або використовувати компілятор.

while true
do
  ssh <ssh_options> [user@]hostname
  sleep 15
done

Зауважте, що для автоматичного встановлення з’єднання для цього потрібен файл ключів, але це теж справа з автосмішкою.

Systemd ідеально підходить для цього.

Створіть файл служби, /etc/systemd/system/sshtunnel.serviceщо містить:

[Unit]
Description=SSH Tunnel
After=network.target

[Service]
Restart=always
RestartSec=20
User=sshtunnel
ExecStart=/bin/ssh -NT -o ServerAliveInterval=60 -L 5900:localhost:5900 user@otherserver

[Install]
WantedBy=multi-user.target

(Змініть команду ssh відповідно до)

• це буде працювати як користувач, sshtunnelтому переконайтеся, що користувач спочатку існує
• проблему, systemctl enable sshtunnelщоб встановити його для запуску під час завантаження
• питання, systemctl start sshtunnelщоб розпочати негайно

Оновлення січня 2018 року : деякі дистрибутиви (наприклад, Fedora 27) можуть використовувати політику SELinux для запобігання використанню SSH від systemd init; у цьому випадку для створення необхідних винятків потрібно створити спеціальну політику.

Мені впевнено здається, що ви все неправильно трактуєте ServerAliveCountMax. Як я розумію, документи, кількість повідомлень на сервері, що живуть, може залишатися без відповіді без припинення з'єднання. Тож у таких випадках, як ми тут обговорюємо, встановлення високого значення просто гарантуватиме, що висяче з'єднання не буде виявлено та припинено!

Просте встановлення ServerAliveInterval повинно бути достатнім, щоб вирішити проблему, коли брандмауер забув про з'єднання, а залишення ServerAliveCountMax низьким дозволить початковому кінці помітити помилку і припинити, якщо з'єднання все-таки не вдасться.

1) для того, щоб з'єднання постійно залишалося відкритим при звичайних обставинах; 2) для виявлення відмови з'єднання та вихідної сторони для виходу з ладу; 3) для повторної видачі команди ssh щоразу виходи (як це робиться від платформи, сценарій "в той час як справжній", запропонований Jawa, є одним із способів, на OS XI фактично налаштований запущений елемент).

Завжди використовуйте ServerAliveIntervalпараметр SSH у випадку, якщо проблеми з тунелем породжуються минулими сеансами NAT.

Завжди використовуйте метод повторного зашивання, якщо зв’язок повністю знижується, тут у вас є щонайменше три варіанти:

• програма autossh
• bash script ( while true do ssh ...; sleep 5; done) не видаляйте команду сну, sshможе швидко вийти з ладу, і ви відновите занадто багато процесів

• /etc/inittab, щоб мати доступ до коробки, що постачається та встановлюється в іншій країні, за NAT, не пересилаючи порт до коробки, ви можете налаштувати її, щоб створити туди ssh назад до вас:

  tun1:2345:respawn:/usr/bin/ssh -i /path/to/rsaKey -f -N -o "ServerAliveInterval 180" -R 55002:localhost:22 user@publicip 'sleep 365d'
  

• сценарій на початку Ubuntu, де /etc/inittabвін недоступний:

  start on net-device-up IFACE=eth0
  stop on runlevel [01S6]
  respawn
  respawn limit 180 900
  exec ssh -i /path/to/rsaKey -N -o "ServerAliveInterval 180" -R 55002:localhost:22 user@publicip
  post-stop script
      sleep 5
  end script
  

або завжди використовувати обидва методи.

Я вирішив цю проблему цим:

Редагувати

~/.ssh/config

І додайте

ServerAliveInterval 15
ServerAliveCountMax 4

Відповідно до сторінки людини для ssh_config:

ServerAliveCountMax
         Sets the number of server alive messages (see below) which may be
         sent without ssh(1) receiving any messages back from the server.
         If this threshold is reached while server alive messages are
         being sent, ssh will disconnect from the server, terminating the
         session.  It is important to note that the use of server alive
         messages is very different from TCPKeepAlive (below).  The server
         alive messages are sent through the encrypted channel and there‐
         fore will not be spoofable.  The TCP keepalive option enabled by
         TCPKeepAlive is spoofable.  The server alive mechanism is valu‐
         able when the client or server depend on knowing when a connec‐
         tion has become inactive.

         The default value is 3.  If, for example, ServerAliveInterval
         (see below) is set to 15 and ServerAliveCountMax is left at the
         default, if the server becomes unresponsive, ssh will disconnect
         after approximately 45 seconds.  This option applies to protocol
         version 2 only.

 ServerAliveInterval
         Sets a timeout interval in seconds after which if no data has
         been received from the server, ssh(1) will send a message through
         the encrypted channel to request a response from the server.  The
         default is 0, indicating that these messages will not be sent to
         the server.  This option applies to protocol version 2 only.

ExitOnForwardFailure yesє гарним доповненням до інших пропозицій. Якщо він з'єднується, але не може встановити переадресацію порту, він так само марний для вас, як ніби він взагалі не з’єднався.

У мене була потреба підтримувати тунель SSH довгостроково. Моє рішення було запущено з сервера Linux, і це лише невелика програма C, яка повторно створює ssh, використовуючи аутентифікацію на основі ключів.

Я не впевнений у висі, але в мене тунелі загинули через тайм-аути.

Я хотів би надати код для репаунер, але, здається, зараз не знаходжу його.

Хоча є такі інструменти, як autossh, який допомагає перезапустити ssh-сеанс ... що мені здається дуже корисним, це запустити команду 'screen'. Це дозволяє відновити свої сеанси ssh навіть після відключення. Особливо корисно, якщо ваш зв’язок не такий надійний, як повинен бути.

• http://www.howtogeek.com/howto/ubuntu/keep-your-ssh-session-running-when-you-disconnect/

... не забудьте позначити це "правильна" відповідь, якщо це допоможе вам k! ;-)

Трохи хак, але я люблю використовувати екран, щоб зберегти це. На даний момент у мене є віддалений вперед, який працює тижнями.

Приклад, починаючи локально:

screen
ssh -R ......

Коли застосовано віддалений вперед, і у вас є оболонка на віддаленому комп'ютері:

screen
Ctrl + a + d

Тепер у вас безперебійний віддалений вперед. Трюк - запустити екран з обох кінців

Нещодавно я мав цю проблему, тому що ці рішення вимагають від вас повторного введення пароля щоразу, коли ви використовуєте логін пароля, я використовував sshpass у циклі разом із текстовим підказом, щоб уникнути наявності пароля у пакетному файлі.

Я думав, що я поділюсь своїм рішенням щодо цієї теми на випадок, якщо хтось інший має те саме питання:

#!/bin/bash
read -s -p "Password: " pass
while true
do
    sshpass -p "$pass" ssh user@address -p port
    sleep 1
done

У мене були подібні проблеми з попереднім провайдером. Для мене це було те саме з будь-яким з'єднанням tcp, відвідуванням веб-сайтів або відправленням пошти.

Рішенням було налаштувати VPN-з'єднання через UDP (я використовував OpenVPN). Це з'єднання було більш толерантним до того, що спричинило відключення. Тоді ви можете запустити будь-яку службу через це з'єднання.

З підключенням все ще можуть виникнути проблеми, але оскільки тунель буде більш толерантним, будь-який сеанс ssh відчує коротке затримку, а не відключення.

Для цього вам знадобиться послуга VPN в Інтернеті, яку можна налаштувати на власному сервері.

Оскільки autosshне відповідає нашим потребам (він існує з помилкою, якщо він не може підключитися до сервера при першій спробі), ми написали чисту програму bash: https://github.com/aktos-io/link- з-сервером

Він створює зворотний тунель для sshd-порту (22) NODE на сервері за замовчуванням. Якщо вам потрібно виконати будь-які інші дії (наприклад, переадресація додаткових портів, надсилання електронної пошти під час з'єднання тощо), ви можете розмістити свої сценарії on-connectта on-disconnectпапки.