Comments 31
Важное уточнение: скрипт не является заменой полноценного решения в стиле Zabbix, Nagios и тд.
А разве заббикс позволяет каким либо образом сохранять контекст после обрыва ssh? Это же система мониторинга просто
Ага, я с mosh уже лет 10 как забыл, что такое обрывы сессий.
Спасибо за комментарий! Согласен, есть mosh, с данным решением я не спорил, но он не даёт гибкости. Писать скрипты - как хобби. Я выливаю всё, что делаю, в статьи на Хабр, кому-то моё решение может помочь, быть полезным и тд.
Mosh - "монолит", который сложнее адаптировать под специфические задачи.
В плане удобства для большинства пользователей - согласен с Вами, решение идеальное, но это же не подразумевает бесполезность статьи из-за того, что такое решение уже есть на "рынке". Если мы будем зацикливаться на уже существующих - как придумывать новое? Фактически всему есть аналоги.
Я из того поколения в котором каждый админ писал свой биллинг, каждый делал свой дистрибутив OS на базе ядра Linux.
И я знаю, что не нужно плодить сущности без надобности
Есть mosh, есть `autossh -t domain.tld "screen -RDA"`. И не нужно плодить бесполезные портянки. Ты просто тратишь свое время, а время это единственное, что мы никогда не можем вернуть.
Используй готовые решения и не мучайся, а время трать на что-то более полезное, мой тебе совет с высоты возраста и опыта
Что только люди не придумают что б не использовать mosh
screen
Спасибо за комментарий! Согласен, есть mosh, с данным решением я не спорил, но он не даёт гибкости. Писать скрипты - как хобби. Я выливаю всё, что делаю, в статьи на Хабр, кому-то моё решение может помочь, быть полезным и тд.
Mosh - "монолит", который сложнее адаптировать под специфические задачи.
В плане удобства для большинства пользователей - согласен с Вами, решение идеальное, но это же не подразумевает бесполезность статьи из-за того, что такое решение уже есть на "рынке". Если мы будем зацикливаться на уже существующих - как придумывать новое? Фактически всему есть аналоги.
Посылать сигнал я-живой через 30 сек:
ssh -o ServerAliveInterval=30 user@some.host.com
Или так:
На сервере в sshd_config:
ClientAliveCountMax 99999
ClientAliveInterval 30
На клиенте в ~/.ssh/config или глобально в ssh_config:
ServerAliveInterval 30
ServerAliveCountMax 99999
А как это работает с двухфакторкой? Наверно никак? (Как и другие варианты)
Спасибо за комментарий! Честно сказать, не тестировал. Вероятнее всего, в этом плане скрипты - не идеальное решение.
Предположу, что можно попробовать настроить вход не по двухфакторной, а для конкретного SSH-ключа, если политика безопасности позволяет.
Это вы безопасникам кастомера расскажите, как можно
(но скорее они сами вам расскажут, а потом то что они не рассказали доскажет ваш менеджер)
А мы тут сами все знаем как настроить)
Когда сервер свой то можно что угодно, только вот 99% работы как раз-то не на своем, а там двухфактора и привет.
Не уловил, где он "восстанавливает предыдущее окружение". Я уж не говорю про "восстановит создание бэкапа". Рестартануть SSH я и сам могу, "вверх-Enter". Главная беда обычно в том, что запущенная в SSH-сессии интерактивная программа к этому моменту уже рухнула по SIGHUP, значения всяких переменных потерялись, текущий путь забылся, вся история команд сдохла. Рестарт SSH ничего этого не вернёт.
Я себе для таких задач EternalTerminal поднимаю, он удерживает контекст практически всегда. Но, к сожалению, он должен устанавливаться в том числе и на сервер, что не всегда возможно.
Спасибо за комментарий! Решения в статье действительно не идеальны. Мой посыл оказался неудачен, бывает. Постараюсь подробнее погружаться в тему в дальнейшем.
Я себе для таких задач EternalTerminal поднимаю, он удерживает контекст практически всегда. Но, к сожалению, он должен устанавливаться в том числе и на сервер, что не всегда возможно.
Изучу, погляжу, спасибо! И прошу прощения за потраченное время на не самую удачную статью. В своих решениях я использую принцип "адаптивности", с чем скрипты справляются отлично. Понадобилось логирование - дописал, необходим мониторинг с уведомлениями - сделал. При написании не подразумевал, что в большинстве ситуаций при обрывах используют mosh\screen\EternalTerminal.
% apt info autossh
Package: autossh
Version: 1.4g-1+b1
Priority: optional
Section: net
Source: autossh (1.4g-1)
Maintainer: Axel Beckert abe@debian.org
Installed-Size: 94.2 kB
Depends: openssh-client | ssh-client, libc6 (>= 2.14)
Enhances: openssh-client, ssh-client
Homepage: https://www.harding.motd.ca/autossh/
Tag: implemented-in::c, interface::daemon, network::hiavailability,
network::server, protocol::ssh, role::program, use::login, use::monitor
Download-Size: 35.4 kB
Description: Automatically restart SSH sessions and tunnels
autossh is a program to start an instance of ssh and monitor it, restarting it
as necessary should it die or stop passing traffic. The idea is from rstunnel
(Reliable SSH Tunnel), but implemented in C. Connection monitoring is done
using a loop of port forwardings. It backs off on the rate of connection
attempts when experiencing rapid failures such as connection refused.
mosh, screen, tmux. Для кого вообще эти утилиты написаны были? Нет, надо скриптами извращаться
Вот лично я, скажем, так и не смог всеми этими утилитами пользоваться. Во всяком случае, не в качестве постоянной замены SSH. Очень уж они неудобны и ограничены, ломают интеграцию с графическими терминалами.
Что мешает в графическом терминале тупо запустить tmux
? Это и отвязка от зависимости качества соединения с инициатором при копировании, и сохранение контекста сессии. При обрыве достаточно `tmux a -t0` при условии, что сессия поднималась тупо командой tmux
Мешает невозможность нормальной прокрутки содержимого. Возможно, я просто не умею его готовить, но когда я пытался нагуглить решения, нашёл только использование встроенного буфера самого tmux'а с довольно неудобными сочетаниями клавиш и невозможностью задействовать стандартную прокрутку из графического интерфейса моей операционки (со стандартными клавишами, колёсиком мыши и пр.).
А что, screen отменили?
Спасибо за комментарий! Ни screen, ни mosh не отменяли. Моё решение рассчитано на дополнительный функционал, который каждый потенциально может адаптировать под себя. До публикации мне казалось, что тема достаточно интересная. Статья вышла неудачная, признаю. Прошу прощения.
Оффтоп. На удаленном сервере у меня в автозапуске создание tmux сессии
tmux new-session -s q -d 'export LC_ALL=en_US.utf8 &&'
При подключении к серверу по ssh сразу попадаю в открытую tmux сессию с помощью
ssh q@193.168.02.63 -o StrictHostKeyChecking=no -o BatchMode=yes 2>&1 -t tmux a | tee ssh-session.log
Кто мне подскажет как логировать в файл без этих жутких служебных CSI последовательностей?
Спасибо за комментарий! Предположу, может попробовать ansifilter
? Что-то в стиле:
ssh q@193.168.02.63 -o StrictHostKeyChecking=no -o BatchMode=yes -t "tmux a" | ansifilter -H | tee ssh-session.log
И, насколько мне известно, есть tmux pipe-pane
,но про него подсказать ничего не могу, к сожалению, только наслышан. Вроде он логирует только после подключения.
Скрипт-реаниматор: автоматическое восстановление упавших SSH-сессий