Терминальный сервер для админа; Ни единого SSH-разрыва



    Если ваша работа требует держать множество SSH-сессий к разным серверам, вы наверняка знаете, как они легко ломаются при переключении на другой Wi-Fi или при временной потере интернета. Но что, если я скажу вам, что все эти проблемы давно решены и можно забыть про сломанные сессии и постоянные переподключения?

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



    Настройка сервера


    Идея проста и наглядно проиллюстрирована на картинке в заголовке поста: все SSH-подключения мы будем держать на специальном терминальном сервере. Этот сервер будет нашей точкой входа для управления другими серверами. При этом на конечных серверах не потребуется настройки или установки дополнительного ПО.
    Для терминального сервера подойдет почти любая конфигурация, но лучше иметь побольше оперативной памяти, чтобы хранить лог консоли внутри каждой сессии и иметь возможность в любой момент проскроллить историю вверх и посмотреть, что вы делали на сервере сессии месяц назад. Обычно 1-2ГБ памяти достаточно.

    Выбор дистрибутива


    В терминальном сервере самое главное — это uptime, ведь чем реже мы перезагружаемся, тем больше живут наши SSH-сессии. Поэтому выбираем максимально консервативный LTS (Long Term Support) дистрибутив, например стабильную ветку debian или ubuntu. Настраиваем автоматические обновления (unattended-upgrades) таким образом, чтобы внезапный перезапуск программ не стал неожиданностью.

    Настройка SSH-сервера


    Так как терминальный сервер будет открывать доступ ко всем нашим серверам разом, будет правильно его обезопасить. Для этого запретим аутентификацию с помощью паролей, оставив только доступ с помощью ключей, а так же запретим логиниться пользователем root.
    Предварительно нужно создать нового пользователя в системе.

    /etc/ssh/sshd_config
    .....
    # Запрет логиниться пользователем root
    PermitRootLogin no
    # Запрет использования паролей, только ключи
    ChallengeResponseAuthentication no
    # Если паролей нет, то и PAM не нужен
    UsePAM no
    ....
    

    Такой конфигурации вполне достаточно, чтобы защититься от массового перебора паролей, так как SSH-сервер будет просто закрывать подключение при попытке авторизоваться с паролем. Даже при большом числе подключений, они будут закрываться достаточно быстро, не создавая существенной нагрузки на сервер. На мой взгляд, с такой конфигурацией нет необходимости устанавливать дополнительные средства защиты вроде fail2ban.

    Часто начинающие админы в своих руководствах советуют менять порт SSH и вместо 22 устанавливать какой-то нестандартный вроде 2222. На мой взгляд это плохая практика, не добавляющая никакой безопасности.

    • Это не позволит защититься от перебора паролей, так как автоматические сканеры всё равно найдут SSH на любом порту и начнут долбиться.
    • Это вносит бардак, если систему администрирует несколько человек и каждый выдумывает свои порты. Когда таких систем десятки, приходится искать сканером на каком порту спрятан SSH на этот раз.
    • Это ломает встроенные ограничения безопасности в программах. Например, веб-браузеры не подключатся на порт 22, если явно указать его в HTTP, но при этом подключатся на другой нестандартный порт. Это можно использовать для срабатывания IDS/IPS систем DDoS.



    Tmux — одно окно чтобы править всеми


    Tmux — это невероятно удобная программа для управления виртуальными терминалами, без которой я просто не представляю своей работы. Поначалу он кажется запутанным и сложным, но если пересилить себя и научиться им пользоваться, вы больше не сможете от него отказаться.

    Для тех, кто не знает что такое tmux, представьте себе веб-браузер с вкладками, только вместо сайтов там консольные сессии. Можно открыть бесконечное количество вкладок и в каждой вкладке запустить свою программу. При этом он запущен на сервере, и от него в любой момент можно отключиться, при этом все запущенные вкладки и программы останутся на своём месте и к ним можно будет вернуться.

    Устанавливаем tmux, если он еще не установлен:
    apt install tmux
    

    В терминологии tmux, отдельный набор окон называется сессией. Мы будем использовать только одну сессию по умолчанию, поэтому не будем использовать названий сессий вообще. Но важно знать, что их может быть больше одной при необходимости.

    Создаем новую сессию:
    tmux new
    

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

    На панели состояния tmux отображаются названия окон (вкладок)
    В этот момент, даже если мы закроем SSH-подключение и заново подключимся к серверу, наша запущенная сессия tmux останется в прежнем состоянии, вместе со всеми запущенными программами так, будто мы ее свернули. Попробуем запустить программу top внутри сессии tmux и отключимся от неё. Для наглядности закроем полностью окно терминала и заново подключимся к серверу.

    После переподключения к серверу подключимся к нашей запущенной ранее сессии:
    tmux attach
    

    И убедимся, что запущенная программа top продолжает работать. На этом месте важно понять главный принцип: после запуска сессия tmux остается работать в фоне на сервере вне зависимости от того, подключены вы к ней или нет.

    Так как сессия tmux позволяет несколько одновременных подключений, это можно использовать для совместной работы нескольких человек на сервере, чтобы видеть в реальном времени одну и ту же консоль. Для этого все подключаются к одному серверу под одной учетной записью и вводят tmux attach. Там же можно и чатиться, прямо в командной строке. Мы часто это используем, чтобы не перекидывать друг другу лог консоли в мессенджере, а сразу работать за одним терминалом.


    Tmux умеет делить окно на несколько (каждое окно внутри вкладки называется pane), это удобно, когда нужно одновременно видеть две консоли. Например, в одном окне редактировать скрипт, а в другом смотреть лог.

    tmux позволяет создавать несколько окон внутри одного и изменять их размер

    По умолчанию, для управления tmux-ом используется хоткей Ctrl+b. После нажатия этого управляющего хоткея tmux ожидает ввода основной команды из одной буквы.

    Вот основные команды:
    Ctrl+b + c — (create) Создать новое окно (вкладку)
    Ctrl+b + <цифра> — Переместиться на вкладку номер N, где цифра это клавиша от 0 до 9. Нумерация окон начинается с нуля.
    Ctrl+b + x — закрыть текущее окно. Если будет закрыто последнее окно, сессия tmux завершится.
    Ctrl+b + w — отобразить список всех окон, по которому можно перемещаться кнопками курсора вверх-вниз и выбрать нужное, нажав enter.
    Ctrl+b + " — разделить окно пополам по горизонтали и создать новое
    Ctrl+b + % — разделить окно по вертикали и создать новое
    Ctrl+b + , — переименовать текущее окно
    Ctrl+b + вниз/вверх/влево/вправо — перемещаться по pane'ам внутри окна
    Ctrl+b + page up/page down — прокрутить скролл вверх
    Ctrl+b + / — искать по истории, как в vim или less

    Это все хоткеи, которые мне потребовались за 10 лет использования tmux. На самом деле их намного больше, но для начала лучше остановиться на этих.

    Конфиг Tmux


    Я считаю хоткей Ctrl+b неудобным, так как прожимать три клавиши для любого действия выходит слишком много. Тема конфигов tmux это отдельная область вкусовщины, и у каждого бывалого пользователя есть свое видение как правильно и удобно. Есть даже целые авторские подборки конфигов и тем для tmux.

    Для отправной точки я приведу пример своего конфига, который, как мне кажется, исправляет все сложности, мешающие быстрому освоению tmux. Конфиг располагается в домашней папке с именем ~/.tmux.conf

    # Вместо ctrl+b будет использовать одну кнопку. Нам моем macbook это самая правая клавиша в цифровом ряду
    set-option -g prefix `
    
    # Когда нужно послать символ <`> нажимаем `+a
    bind-key a send-prefix
    
    # Нумерация окон с единицы вместо ноля
    set -g base-index 1
    set-option -g base-index 1
    setw -g pane-base-index 1
    
    # Lowers the delay time between the prefix key and other keys - fixes pausing in vim
    set-option -sg escape-time 1
    
    # Лимит истории консоли в 1000 строк. Столько строк можно отскроллить вверх
    set -g history-limit 1000
    
    # Цвета статус бара
    
    # default statusbar colors
    set-option -g status-fg white
    set-option -g status-bg default
    
    # default window title colors
    set-window-option -g window-status-fg default
    set-window-option -g window-status-bg default
    
    
    
    
    # Автозапуск окон с командами при первом запуске
    #------------------
    
    # Respawn windows when PANE IS DEAD
    bind-key R respawn-window
    
    # Создать сессию default с окном local
    new -d -s default -n local
    
    # Создать окно с именем irc и командой irssi
    neww -d -n irc irssi
    
    # Создать окно с именем superserver и командой ssh root@superserver.com
    neww -d -n superserver ssh root@superserver.com
    
    # Создать окно с именем anotherserver и командой ssh root@123.123.123.123
    neww -d -n superserver anotherserver root@123.123.123.123
    


    Данная конфигурация позволяет автоматически создавать несколько окон при запуске, в которых сразу запускаются SSH-сессии. При этом не требуется вручную создавать новую сессию командой tmux new, достаточно всегда вводить tmux attach. Если сессия до этого не существовала, она будет создана.

    Автозапуск tmux


    Мы хотим, чтобы при подключении к терминальному серверу мы сразу попадали в tmux, даже если сервер был перезагружен и сессия tmux была закрыта.

    Для этого добавим в конец файла ~/.bashrc запуск tmux. Важно помнить, что такая конструкция будет работать только с конфигом выше.
    if [ ! "$TMUX" ]; then
     tmux attach
    fi
    
    if [ "$TMUX" ]; then
     export TERM=screen
    fi
    


    Это простое условие означает, что если мы не в tmux, то подключаемся к нему.

    На этом конфигурация tmux на терминальном сервере закончена. Отныне для каждого нового SSH-подключения мы будем создавать отдельное окно в tmux. И даже если соединения с терминальным сервером будет потеряно, все SSH-подключения останутся активными.

    Mosh — больше никаких разрывов


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

    Mosh — надстройка над обычным OpenSSH сервером, которая позволяет забыть о разрывах соединения. Mosh авторизуется по обычному SSH, после чего поднимается отдельный UDP-канал, который мгновенно восстанавливается после разрыва, даже если у вас сменился внешний IP-адрес.
    Так как нам нужно держать постоянное подключение к терминальному серверу, мы установим mosh только на сервер и на наш рабочий компьютер. При этом на удалённые серверы ничего устанавливать не потребуется, так как подключения к ним и так уже живут вечно в tmux.

    Устанавливаем mosh на сервер:
    apt install mosh
    


    Устанавливаем mosh на наш рабочий компьютер. Он доступен для всех основных операционных систем, но нативный клиент есть только для Unix-подобных операционных систем. Версия для Windows реализована с помощью Cygwin либо приложения Chrome.

    Я использую macOS, и устанавливаю mosh через пакетный менеджер brew:
    brew install mosh
    


    В большинстве случаев mosh не требует дополнительной настройки и работает прямо из коробки. Достаточно вместо команды ssh написать mosh:
    mosh user@my-server.com
    


    Для нестандартных конфигураций команда выглядит чуть сложнее. Например, если нужно указать порт и путь к ключу:

    mosh --ssh="ssh -p 2222 -i /path/to/ssh.key" user@my-server.com
    


    Первичную аутентификацию mosh выполняет как обычный SSH-клиент, авторизуясь на стандартный порт 22. При этом mosh-сервер изначально не слушает никаких портов, и кроме оригинального демона OpenSSH наружу никаких портов на сервере не открыто. После подключения по TCP, mosh запускается на сервере в юзерспейсе и открывает дополнительный тоннель по UDP.


    Схема работы протокола Mosh

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

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

    alias t='mosh --ssh="ssh -p 443 -i /path/to/ssh.key" user@my-server.com'
    


    Заключение



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



    Подписывайтесь на нашего разработчика в Instagram


    Хостинг-технологии
    118,88
    VDS хостинг от разработчиков для разработчиков
    Поделиться публикацией

    Комментарии 60

      +2
      Что насчет безопасности самого mosh протокола? Насколько можно судить по доступной информации, эта udp надстройка совершенно кастомная и никогда не проходила аудит.
        +2

        Трафик mosh шифруется AES-128, обмен ключами происходит по обычному SSH в момент подключения. Насколько сам протокол хорошо сделан, я конечно не знаю.

        +1
        Т.е. вы используете tmux у себя и потом запускаете tmux на каждом сервере? Т.к. часто нужно более одного терминала на каждом сервере.
        Давно поглядываю на tmux, но на серверах, зачастую, предустановлен screen, поэтому переход затрудняется.
          +1

          Нет, tmux запускается только на терминальном сервере. Каждая SSH-сессия живет в отдельном окне тмукса. Предполагается что связь между серверами достаточно стабильна.

            +1
            Что если нужно по несколько окон для каждого сервера? Т.е. я подлючился к серверу А и мне нужно несколько консолей на нем, так же для сервера Б. Сейчас я использую screen у себя и screen на сервере, чтобы можно было переключится внутри серверного screen.
              +1

              В tmux можно поделить окно на несколько pane-ов и в каждом открыть еще одну SSH сессию. Я тупо открываю несколько коннектов к одному серверу в одном окне.

                +1
                Что если нужно по несколько окон для каждого сервера?
                Не знаю как в tmux, а у меня вот такое сокращение для присоединения к серверу с одновременным поднятием screen на сервере или с присоединением к существующей сессии screen:
                alias server1='mosh root@server1 -- screen -xRR -D'
            +3

            В статье не описывает проброс SSH-ключей на терминальный сервер через ssh agent. Это бы позволило использовать приватный ключ находящийся на локальном компьютере при подключении к серверам через терминальный сервер, так будто бы он лежал на терминальном сервере.


            Это можно настроить так:
            ~/.ssh/config


            Host my-terminal-server.com
              ForwardAgent yes

            Я не уверен насколько это хороший способ. Сам лично я предпочитаю держать зашифрованный приватный ключ на терминальном сервере и вводить от него пароль при подключении к другим серверам.

              +7
              Вообще вопрос проброса ключей и прост и сложен одновременно, многие моменты, как регулярно выясняется, не ясны большинству начинающих пользователей. И если делать вещи «в лоб», как описано во многих инструкциях, можно напороться на проблемы. Лишь часть из них:
              1. проброс агента с ключами на машину, к которой есть рутовый доступ у кого-то еще потенциально может поставить под удар все ваши ключи, т.к. rw права на ваш SSH_AUTH_SOCK будут еще у кого-то кроме вас. А дальше вектор атаки прост до безобразия — SSH_AUTH_SOCK=ваш_проброшенный_сокет ssh -T git@github.com (ну или еще куда-то) и поехали. Поэтому:
              — не делаем в конфиге ForwardAgent yes в секции Host *, т.к. рано или поздно мы так неосознанно со всеми своими ключами пойдем на какой-нибудь чужой сервер
              — добавляем в агент ключи, которые реально вам нужны для текущих дел. Важные ключи в агент добавляем для разового использования. Для совсем важного лучше какой-нибудь токен с кнопкой завести.
              — Пользуемся возможностью confirmation использования ключа из агента (ssh-add -c, например) — хотя тут придется соблюдать баланс удобства и безопасности, какой-нибудь ansible может вас за один плейбук достать с подтверждениями. Так мы как минимум будем видеть, если нашим агентом кто-то захочет воспользоваться без нашего ведома.
              2. Для того, чтобы проброшенный агент работал, вам необходимо, чтобы ssh сессия была жива. Не получится запустить какой-нибудь скрипт, который регулярно должен будет куда-то логиниться с использованием проброшенных ключей, закрыть крышку ноута и поехать домой, думая, что он за это время отработает. Как только соединение оборвется, подпись запросов через сокет перестанет работать, новые ssh сессии ваш скрипт не откроет (а вы там, например, что-то регулярно с гитхабом через ssh делаете). То же самое для любителей запускать долгоживущие скрипты, использующие ваш SSH_AUTH_SOCK через nohup/tmux/screen — нет коннекта к вашему локальному агенту — нет использования ключей.
              3. SSH_AUTH_SOCK при каждом логине на сервер будет в общем случае разный. Если вам нужно, чтобы ключи продолжали работать после перелогина, надо что-то делать с персистентностью переменной сокета, например, прибивать его гвоздями к одному и тому же пути. Иначе при новом подключении путь до сокета с агентом будет другой, а в открытых сессиях в tmux SSH_AUTH_SOCK переменная будет указывать на старый, который был при запуске сессии.
              +2
              Тоже использую tmux и иногда надо войти сразу на кучу серверов и сделать там что-нибудь одинаковое, написал вот такую утилитку pastebin.com/wV8Lt54W
                +3
                Я думаю лучше для таких случаев использовать ansible
                  0

                  Чтобы что-нибудь сконфигурить да, а чтобы логи погрепать сразу на десятке серверов нет

                    0
                    Для логов с десятков серверов лучше использовать лог-агрегаторы вроде ELK, GrayLog, Splunk, Loggly и тому подобных.
                      +4

                      Ну камон, вот приспичило чего-нибудь на коленках глянуть, инфраструктуру поднимать на десяток человеко-часов или глянуть по быстрому через несколько pane в tmux?)))

                        0
                        Для быстрого просмотра в начале пути — можно и напрямую с серверов, но если счёт идёт реально на десятки и сотни нод, то имеет смысл задумать о централизованном хранилище логов. Реально облегчает задачу поиска узкого места!
                        Бонусом идёт возможность навесить алёрты на возникновение ошибок или превышение ззаданного количества определённых сообщений в единицу времени.
                  0
                  А DSH(distributed shell) не подойдет для таких целей?
                  dsh –aM –c uptime

                  0
                  А как решается проблема отвала по неактивности между терминальным и конечными серверами?
                    0

                    OpenSSH не закрывает коннект просто по неактивности. Настройки KeepAlive касаются только самого подключения на уровне TCP.

                      0
                      Я и не только про SSH говорю, собственно. Хотя и там зачастую бывает настроен таймаут.
                        0
                        Я и не только про SSH говорю, собственно

                        А про что еще можно говорить в этом контексте?


                        Хотя и там зачастую бывает настроен таймаут.

                        Я ошибся, действительно автоматический дисконнект по idle можно настроить:


                        /etc/ssh/sshd_config


                        ClientAliveInterval 300 # таймаут пять минут
                        ClientAliveCountMax 0

                        Но так делать неправильно, если вы запустите какую-то команду, которая будет выполняться дольше этого таймаута, она просто сломается и не выполнится.

                          0
                          Так делать действительно неправильно, поэтому используют переменную TMOUT.
                            0

                            Это относится уже к шелу и не совсем про ssh. Тем более если это пользовательская переменная окружения, ее можно переназначить.

                    +4
                    Всё-таки нестандартный порт немного снижает количество попыток проникнуть на сервер.
                      +6
                      В моём случае после применения нестандартного порта для SSH попытки проникновения прекратились совсем. Уже лет семь не ломятся. Пока был порт 22, попытки подбора пароля шли постоянно. Мне кажется, ломателям логично не тратить время на перебор стандартных комбинаций паролей, ведь если хозяин сервера поменял порт, то и пароль у него точно не qwerty123.
                        0
                        У меня аналогично. И не только ssh, другие сервисы тоже на нестандартных портах, в fail2ban практически пусто.
                        +1
                        Поддерживаю! На свежих 5 VPS, пока не поменял порт, за день было до 5к неудачных логинов, после смены порта = 0.
                        +2

                        Поэтому я ограничиваю idle сессии.


                        1. При взломе сервера дальнейшая компрометация остальных систем только дело времени
                        2. При увольнении сотрудника смена паролей и ключей бесполезна, так как он остаётся залогинен.
                          +1
                          Особого выигрыша нет, как мне кажется.
                          При взломе сервера дальнейшая компрометация остальных систем только дело времени

                          Если с сервера можно ходить на другие сервера — то независимо от наличия висящих сессий взлом этого сервера даст доступ к остальным серверам, вопрос только во времени.

                          При увольнении сотрудника смена паролей и ключей бесполезна, так как он остаётся залогинен.

                          Если сессии сотрудника висят на сервере, но сотрудника уволили — то убиваем все процессы принадлежащие юзеру, потом самого юзера. Всё, профит. Главное — сразу организовать схему с терминальным сервером.
                            0
                            Если с сервера можно ходить на другие сервера — то независимо от наличия висящих сессий взлом этого сервера даст доступ к остальным серверам, вопрос только во времени.

                            ssh google oauth

                            Если сессии сотрудника висят на сервере, но сотрудника уволили — то убиваем все процессы принадлежащие юзеру, потом самого юзера. Всё, профит. Главное — сразу организовать схему с терминальным сервером.

                            аккаунты могут быть не только личные
                          –6
                          Неужто вы свой отрицательный рейтинг решили поднять статьями на хабре? Жаль только качество и сервис этим не поднять.
                            0

                            Кроме перечисленного, я лично использую еще http://byobu.co/ (фактически кастомный конфиг дляtmux/screen с неким "автозапуском")

                              0
                              Пользуюсь tmux уже несколько лет, и как ни странно, он уже много раз крашился(попросту вылетал). Это при том, что от разрабов OpenBSD, и проецируется как более качественная(в плане кода) и современная альтернатива screen'у. Подумываю над обратным переходом к скрину.
                                0

                                Если сможете записать лог сервера и заслать авторам на ГитХаб, разработчики оценят. Но вообще ни разу не слышал ни у кого проблем с Tmux, кроме известной истории с systemd.

                                0
                                как по мне, у screen только один существенный минус: в одной сессии нельзя создать больше ~30 окон. Хотя, может я ошибаюсь и это тоже настраивается.
                                  +1

                                  В свое время, после перехода на 3G, меня достали постоянные обрывы SSH сессий по таймауту. В конечном счете полностью снял проблему тремя строками в ~/.ssh/config:


                                  Host *
                                      ServerAliveInterval 30
                                      ServerAliveCountMax 2

                                  Раннее я пробовал пользоваться mosh, но, как оказалось, он не работает с прокруткой окна и не умеет монтировать удаленную ФС как sshfs. Пришлось выбросить.

                                    0
                                    Немного непонятно, в чем здесь сакральный смысл использования Mosh, если с терминальным сервером всё равно одно единственное подключение используется, а вся работа по сохранению рабочей среды лежит на tmux. Так ли необходимо жертвовать безопасностью в угоду получения минимального преимущества?
                                      0
                                      Так ли необходимо жертвовать безопасностью

                                      Почему вы считаете что mosh менее безопасен чем обычный ssh?


                                      в чем здесь сакральный смысл использования Mosh

                                      Я закрываю-открываю ноутбук по несколько раз в день. Без mosh мне бы приходилось сначала убивать зависшее соединение и потом заново подключаться и вводить пароль. Это раздражает. Мне нравится когда, например, почтовый клиент всегда открыт а не требует каких-то манипуляций каждый раз перед использованием. Так и с терминалом.

                                        +1
                                        Почему вы считаете что mosh менее безопасен чем обычный ssh?

                                        я не утверждаю такое, но в любом случае, mosh — это дополнительный потенциальный вектор атаки.

                                        Я закрываю-открываю ноутбук по несколько раз в день

                                        Ок, я понял. Возможно, я не обращаю на такие мелочи внимания, потому что в основном работаю с десктопа, и в случае если надо отключить сеть — просто свернул бы tmux-сеанс и разорвал бы ssh-сессию перед этим. В случае переавторизации по ключу — пароль вводить не надо, т.ч. потери времени минимальны.
                                      0

                                      _

                                        +1

                                        Альтернативно, достаточно иметь vpn-соединение и пускать ssh-трафик через него. В этом случае каждый раз ssh продолжает работать с того же самого (vpn-ip), и разрывов не происходит. Если выключен keepalive, то ноутбук после suspend/resume прекрасно продолжит сессию даже если ноут пару суток пролежал в отключке.

                                          +1

                                          Даже если сервер что-то шлет в stdout? Мне кажется, он получит “broken pipe” через несколько килобайт.

                                            0

                                            Если у вас что-то шлёт в stdout на сервере (т.е. запущено) надолго, то вы используете сервер "не так". Обычно консоли открыты "в середине дебага" (т.е. ничего не происходит). Если происходит — screen/nohup/systemd.

                                            +1

                                            Поддерживаю, по-моему это очевидный способ. И он лучше сразу по двум причинам:
                                            1) вместо замены механизмов безопасности ssh на непроверенные механизмы mosh, тут ssh никуда не девается, но дополнительно обёртывается в её один слой безопасности (который даже если и дырявый, то максимум что может испортить это сбросить соединение)
                                            2) виртуальные экраны (tmux, screen) иногда плохо себя ведут при запуске в них чего-то чуть более сложного чем обычный шелл; аналогично видимо и с самим mosh; а в случае ssh over vpn всё будет обычно

                                            0
                                            Существует такая весччь как byobu, по сути конфиг для tmux (tmux на стероидах). Всё то-же самое что и tmux но с удобными хоткеями и удобным тюнингом строки состояния с кучей информативных вариаций.
                                              0
                                              Добавлю пару капель в бочку меда про tmux

                                              1. окна tmux умеют как-то совсем страшно ломаться после попадания на stdout бинарных данных. Приходится на ощупь кастовать заклинание
                                              stty sane; printf '\033k%s\033\\\033]2;%s\007' "`basename "$SHELL"`" "`uname -n`"; tput reset; tmux refresh


                                              2. Работал с ноутбука в tmux, потом залез с телефона, потом возвращаюсь в ноутбук, а там все окна стали меньше, не на «фулл-скрин».
                                                0
                                                Работал с ноутбука в tmux, потом залез с телефона, потом возвращаюсь в ноутбук, а там все окна стали меньше, не на «фулл-скрин».

                                                В этом случае нужно подключаться с опцией -d, тогда старую сессию отключит и окна будут нормального размера.


                                                tmux attach -d
                                                  0
                                                  Предположу, что заклинание можно заалиасить (bash alias), и тогда кастовать будет проще.
                                                  +2

                                                  Еще две копейки к статье:


                                                  1. Mosh не работает с midnight commander. И не может даже теоретически.
                                                  2. Есть ему альтернатива, EternalTerminal, и в нем mc ok. Работает он по tcp (а не по udp), но, как легко увидеть, протокол тут вообще ни при чем — можно сделать хоть поверх http. Есть у EternalTerminal, правда, и недостаток (неисправимый даже теоретически): если сервер решил передать 1 гб данных после закрытия крышки, то при открытии крышки весь этот гигабайт честно приедет в консоль и там отрисуется (не делайте tail -f с EternalTerminal). В mosh такой проблемы нет, ибо он имеет свой собственный скрин-буфер (почему mc и не работает).
                                                  3. У tmux-а есть нативная интеграция с iterm2 (привет маководам). Табы терминала автоматически и прозрачно преобразуются в окна tmux-а и наоборот, причем даже плиточная раскладка сохраняется. И с EternalTerminal это работает тоже.

                                                  Мой выбор долгое время был EternalTerminal+tmux+iterm2 с нативной интеграцией.

                                                    0
                                                    … выбор был...

                                                    А сейчас?
                                                    –1
                                                    Открывая крышку ноутбука, все мои десятки SSH-сессий сразу доступны


                                                    Проезжая мимо станции, с меня слетела шляпа (Ц) ;)
                                                      0
                                                      Если кому интересно посмотреть — один из вариантов конфигурации tmux:
                                                      github.com/samoshkin/tmux-config
                                                        0
                                                        Чем-то похоже на команду screen.
                                                        Там тоже можно создавать перманентные сессии и потом подключаться к ним.

                                                        linuxize.com/post/how-to-use-linux-screen
                                                          0

                                                          Статья хороша, но небольшое НО — на сетевом оборудовании обычно настраивается ssh-таймаут, чтоб неактивные сессии убивались, по очевидным причинам.

                                                            0
                                                            Очень простой вопрос про безопасность такого решения.
                                                            Вы просто открываете крышку ноутбука и сразу доступны все консоли серверов? Причём, везде настроена авторизация по ключам и отключены запросы паролей?

                                                            Ноутбук такая мобильная вещь.
                                                            А что будет если вы оставите его без присмотра или ноутбук в результате криминала окажется в чужих руках?

                                                            Да это просто дырищща с точки зрения безопасности!
                                                              0
                                                              Вместо ssh использовал VNCscraping+OpenVPN. Довольно удобно оказалось, и разрывы ничего не портят. Хотя, с каким-нибудь домашним роутером так не получится связаться, наверное.
                                                                0

                                                                А чем byobu не устраивает?


                                                                Также с точки зрения безопасности напрягает формулировка «логинимся все на одного пользователя»

                                                                  +1
                                                                  Раз используете терминальный сервер, то в /etc/ssh/sshd_config
                                                                  не забываем внести:
                                                                  Compression yes
                                                                  MaxSessions 20

                                                                  Также не забываем про мультипрексирование ssh, вставляем в /etc/ssh/ssh_config код:
                                                                  ControlPath ~/.ssh/ssh-mux-%r@%h:%p
                                                                  ControlMaster auto
                                                                  ControlPersist yes
                                                                  

                                                                  P.S. Не путаем конфиги sshd_config и ssh_config.
                                                                  P.P.S. Кол-во сессий и длительность ControlPersist по вкусу.

                                                                    +1
                                                                    Часто начинающие админы в своих руководствах советуют менять порт SSH и вместо 22 устанавливать какой-то нестандартный вроде 2222. На мой взгляд это плохая практика, не добавляющая никакой безопасности.

                                                                    Обычно это делается не для безопасности, а для того, чтобы логов меньше было. На 22й порт в любом случае будут чаще стучаться боты чем на 2222.
                                                                      0
                                                                      и открывает дополнительный тоннель по UDP

                                                                      возможно, глупый вопрос: но что значит открывает? udp же не имеет connect в том же смысле что и tcp
                                                                        –2
                                                                        xshell

                                                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                        Самое читаемое