Помилка віддаленого переадресації порту SSH

Продовження: Схоже, швидка серія відключень, що збігається з декількома місяцями роботи кожного сервера, ймовірно, збігається і просто служить для виявлення фактичної проблеми. Причина, через яку не вдалося відновити зв'язок, майже напевно пояснюється значеннями AliveInterval (відповідь Касперда). Використання параметра ExitOnForwardFailure повинно дозволяти належному виникненню тайм-ауту перед повторним підключенням, що повинно вирішити проблему в більшості випадків. Пропозиція MadHatter (сценарій вбивства), мабуть, найкращий спосіб переконатися, що тунель може знову підключитися, навіть якщо все інше вийде з ладу.

У мене є сервер (A) за брандмауером, який ініціює зворотний тунель на декількох портах до невеликого DigitalOcean VPS (B), щоб я міг підключитися до A через IP-адресу Б. Тунель працював послідовно близько 3 місяців, але раптово вийшов з ладу чотири рази за останні 24 години. Те ж саме трапилося ще раз у іншого постачальника VPS - місяці бездоганної роботи, а потім раптом багато швидких збоїв.

У мене є скрипт на машині A, який автоматично виконує тунельну команду ( ssh -R *:X:localhost:X address_of_Bдля кожного порту X), але коли вона виконується, вона каже Warning: remote port forwarding failed for listen port X.

Заходивши в sshd /var/log/secureна сервері, показує ці помилки:

bind: Address already in use
error: bind: Address already in use
error: channel_setup_fwd_listener: cannot listen to port: X

Для вирішення потрібен перезавантаження VPS. До цього часу всі спроби відновити з'єднання дають повідомлення про "віддалене переадресація порту не вдалося" і не спрацюють. Зараз до точки, коли тунель триває лише близько 4 годин до зупинки.

У системі VPS нічого не змінилося, і це одноразова користувальницька машина, яка служить лише кінцевою точкою зворотного тунелю. Він працює OpenSSH_5.3p1 на CentOS 6.5. Здається, що sshd не закриває порти на своєму кінці, коли з'єднання втрачено. Мені не вдається пояснити, чому або чому це раптом станеться зараз через місяці майже ідеальної роботи.

Для уточнення спершу мені потрібно з’ясувати, чому sshd відмовляється слухати порти після виходу з ладу тунелю, що, мабуть, викликано тим, що sshd залишає порти відкритими і ніколи їх не закриває. Це, здається, є основною проблемою. Я просто не впевнений, що може змусити його так поводитися через місяці поведінки, як я очікував (тобто закриваю порти відразу і дозволяю сценарію знову підключатися).

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

Існує три способи таких розривів зв'язку:

• Одну з двох кінцевих точок перезавантажили, а інший кінець з'єднання повністю не працює.
• Одна з двох кінцевих точок закрила з'єднання, але в той час, коли з'єднання було закрито, на з’єднанні стався тимчасовий відключення. Відключення тривало кілька хвилин після закриття з'єднання, і, таким чином, інший кінець ніколи не дізнався про закрите з'єднання.
• З'єднання все ще є повністю функціональним в обох кінцевих точках ssh-з'єднання, але хтось поставив десь між ними стан, який призупинив з'єднання через неробство. Цей видатний пристрій буде або NAT, або брандмауером. Брандмауер, про який ви вже згадували, є головним підозрюваним.

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

Ви повинні вивчити ClientAliveIntervalключове слово для sshd_configта ServerAliveIntervalінтервал для ssh_configабо ~/.ssh/config.

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

Якщо клієнт знову підключиться до того, як з'єднання припиниться на сервері, ви можете опинитися в ситуації, коли новий ssh-з'єднання живе, але не має переадресації порту. Щоб уникнути цього, вам потрібно використовувати ExitOnForwardFailureключове слово на стороні клієнта.

Ви можете знайти процес, що зв'язує порт на цьому сервері

sudo netstat -apn|grep -w X

Здається, це дуже ймовірно, що це напівпрогноз sshd, але навіщо робити припущення, коли можна мати дані? Це також хороший спосіб для сценарію знайти PID, щоб відправити сигнал 9 до того, як спробувати знову підняти тунель.

Для мене, коли sshтунель відключається, потрібне деякий час, щоб з'єднання було скинуто, тому sshпроцес продовжує блокувати, залишаючи мене без активних тунелів, і я не знаю, чому. Рішення для вирішення проблеми полягає в тому, щоб вивести sshна задній план -fі нерестовити нові з'єднання, не чекаючи, коли старі з'єднання будуть скинуті. -o ExitOnForwardFailure=yesМоже бути використані для НТА кількості нових процесів. -o ServerAliveInterval=60Підвищує надійність вашого поточного з'єднання.

Ви можете повторювати sshкоманду часто, скажімо, в a cronабо або в циклі у вашому сценарії, наприклад, у наступному, ми виконуємо sshкоманду кожні 3 хвилини:

while (1)
do
    ssh -f user@hostname -Rport:host:hostport -N -o ExitOnForwardFailure=yes -o ServerAliveInterval=60
    sleep 180
done

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

ssh <server>
while true; do  sleep 60; done&
exit

Ваш ssh вийде, але фактично не закриє сеанс - до тих пір, поки віддалений процес не завершиться (чого не буде, оскільки це цикл "в той час як справжній"). Можливо, відбувається щось подібне - ваш сеанс має "застряглий" процес, породжений ssh. Порт залишається у використанні, і тому він не може бути використаний локальним процесом.