Если ваша работа требует держать множество 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-подключения.
Комментарии (55)
helgihabr
23.10.2019 16:41+1Т.е. вы используете tmux у себя и потом запускаете tmux на каждом сервере? Т.к. часто нужно более одного терминала на каждом сервере.
Давно поглядываю на tmux, но на серверах, зачастую, предустановлен screen, поэтому переход затрудняется.
zhovner
23.10.2019 16:48+1Нет, tmux запускается только на терминальном сервере. Каждая SSH-сессия живет в отдельном окне тмукса. Предполагается что связь между серверами достаточно стабильна.
helgihabr
23.10.2019 18:01+1Что если нужно по несколько окон для каждого сервера? Т.е. я подлючился к серверу А и мне нужно несколько консолей на нем, так же для сервера Б. Сейчас я использую screen у себя и screen на сервере, чтобы можно было переключится внутри серверного screen.
zhovner
23.10.2019 18:42+1В tmux можно поделить окно на несколько pane-ов и в каждом открыть еще одну SSH сессию. Я тупо открываю несколько коннектов к одному серверу в одном окне.
mikhailian
23.10.2019 23:08Что если нужно по несколько окон для каждого сервера?
Не знаю как в tmux, а у меня вот такое сокращение для присоединения к серверу с одновременным поднятием screen на сервере или с присоединением к существующей сессии screen:
alias server1='mosh root@server1 -- screen -xRR -D'
zhovner
23.10.2019 17:01+1В статье не описывает проброс SSH-ключей на терминальный сервер через ssh agent. Это бы позволило использовать приватный ключ находящийся на локальном компьютере при подключении к серверам через терминальный сервер, так будто бы он лежал на терминальном сервере.
Это можно настроить так:
~/.ssh/config
Host my-terminal-server.com ForwardAgent yes
Я не уверен насколько это хороший способ. Сам лично я предпочитаю держать зашифрованный приватный ключ на терминальном сервере и вводить от него пароль при подключении к другим серверам.
wizard_s
24.10.2019 09:32Вообще вопрос проброса ключей и прост и сложен одновременно, многие моменты, как регулярно выясняется, не ясны большинству начинающих пользователей. И если делать вещи «в лоб», как описано во многих инструкциях, можно напороться на проблемы. Лишь часть из них:
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 переменная будет указывать на старый, который был при запуске сессии.
lagutas
23.10.2019 17:56+1Тоже использую tmux и иногда надо войти сразу на кучу серверов и сделать там что-нибудь одинаковое, написал вот такую утилитку pastebin.com/wV8Lt54W
AndreyKov9
23.10.2019 21:09+2Я думаю лучше для таких случаев использовать ansible
lagutas
23.10.2019 21:20Чтобы что-нибудь сконфигурить да, а чтобы логи погрепать сразу на десятке серверов нет
sevmax
23.10.2019 22:02Для логов с десятков серверов лучше использовать лог-агрегаторы вроде ELK, GrayLog, Splunk, Loggly и тому подобных.
lagutas
23.10.2019 22:18+2Ну камон, вот приспичило чего-нибудь на коленках глянуть, инфраструктуру поднимать на десяток человеко-часов или глянуть по быстрому через несколько pane в tmux?)))
sevmax
24.10.2019 00:31Для быстрого просмотра в начале пути — можно и напрямую с серверов, но если счёт идёт реально на десятки и сотни нод, то имеет смысл задумать о централизованном хранилище логов. Реально облегчает задачу поиска узкого места!
Бонусом идёт возможность навесить алёрты на возникновение ошибок или превышение ззаданного количества определённых сообщений в единицу времени.
ky0
23.10.2019 18:36А как решается проблема отвала по неактивности между терминальным и конечными серверами?
zhovner
23.10.2019 18:44OpenSSH не закрывает коннект просто по неактивности. Настройки KeepAlive касаются только самого подключения на уровне TCP.
ky0
23.10.2019 19:30Я и не только про SSH говорю, собственно. Хотя и там зачастую бывает настроен таймаут.
zhovner
23.10.2019 19:59Я и не только про SSH говорю, собственно
А про что еще можно говорить в этом контексте?
Хотя и там зачастую бывает настроен таймаут.
Я ошибся, действительно автоматический дисконнект по idle можно настроить:
/etc/ssh/sshd_config
ClientAliveInterval 300 # таймаут пять минут ClientAliveCountMax 0
Но так делать неправильно, если вы запустите какую-то команду, которая будет выполняться дольше этого таймаута, она просто сломается и не выполнится.
polyanin
23.10.2019 18:54+3Всё-таки нестандартный порт немного снижает количество попыток проникнуть на сервер.
maikus
23.10.2019 19:57+2В моём случае после применения нестандартного порта для SSH попытки проникновения прекратились совсем. Уже лет семь не ломятся. Пока был порт 22, попытки подбора пароля шли постоянно. Мне кажется, ломателям логично не тратить время на перебор стандартных комбинаций паролей, ведь если хозяин сервера поменял порт, то и пароль у него точно не qwerty123.
dikkini
23.10.2019 23:02+1Поддерживаю! На свежих 5 VPS, пока не поменял порт, за день было до 5к неудачных логинов, после смены порта = 0.
nikolayvaganov
23.10.2019 19:59+1Поэтому я ограничиваю idle сессии.
- При взломе сервера дальнейшая компрометация остальных систем только дело времени
- При увольнении сотрудника смена паролей и ключей бесполезна, так как он остаётся залогинен.
Nokse
23.10.2019 23:23Особого выигрыша нет, как мне кажется.
При взломе сервера дальнейшая компрометация остальных систем только дело времени
Если с сервера можно ходить на другие сервера — то независимо от наличия висящих сессий взлом этого сервера даст доступ к остальным серверам, вопрос только во времени.
При увольнении сотрудника смена паролей и ключей бесполезна, так как он остаётся залогинен.
Если сессии сотрудника висят на сервере, но сотрудника уволили — то убиваем все процессы принадлежащие юзеру, потом самого юзера. Всё, профит. Главное — сразу организовать схему с терминальным сервером.nikolayvaganov
24.10.2019 09:33Если с сервера можно ходить на другие сервера — то независимо от наличия висящих сессий взлом этого сервера даст доступ к остальным серверам, вопрос только во времени.
ssh google oauth
Если сессии сотрудника висят на сервере, но сотрудника уволили — то убиваем все процессы принадлежащие юзеру, потом самого юзера. Всё, профит. Главное — сразу организовать схему с терминальным сервером.
аккаунты могут быть не только личные
gangstarcj
23.10.2019 20:34-4Неужто вы свой отрицательный рейтинг решили поднять статьями на хабре? Жаль только качество и сервис этим не поднять.
ForeverYoung
23.10.2019 21:01Кроме перечисленного, я лично использую еще http://byobu.co/ (фактически кастомный конфиг дляtmux/screen с неким "автозапуском")
conductor
23.10.2019 21:09Пользуюсь tmux уже несколько лет, и как ни странно, он уже много раз крашился(попросту вылетал). Это при том, что от разрабов OpenBSD, и проецируется как более качественная(в плане кода) и современная альтернатива screen'у. Подумываю над обратным переходом к скрину.
ElegantBoomerang
25.10.2019 11:31Если сможете записать лог сервера и заслать авторам на ГитХаб, разработчики оценят. Но вообще ни разу не слышал ни у кого проблем с Tmux, кроме известной истории с systemd.
Nokse
23.10.2019 23:26как по мне, у screen только один существенный минус: в одной сессии нельзя создать больше ~30 окон. Хотя, может я ошибаюсь и это тоже настраивается.
arthuriantech
24.10.2019 00:17В свое время, после перехода на 3G, меня достали постоянные обрывы SSH сессий по таймауту. В конечном счете полностью снял проблему тремя строками в ~/.ssh/config:
Host * ServerAliveInterval 30 ServerAliveCountMax 2
Раннее я пробовал пользоваться mosh, но, как оказалось, он не работает с прокруткой окна и не умеет монтировать удаленную ФС как sshfs. Пришлось выбросить.
kiba
24.10.2019 01:49Немного непонятно, в чем здесь сакральный смысл использования Mosh, если с терминальным сервером всё равно одно единственное подключение используется, а вся работа по сохранению рабочей среды лежит на tmux. Так ли необходимо жертвовать безопасностью в угоду получения минимального преимущества?
zhovner
24.10.2019 02:48Так ли необходимо жертвовать безопасностью
Почему вы считаете что mosh менее безопасен чем обычный ssh?
в чем здесь сакральный смысл использования Mosh
Я закрываю-открываю ноутбук по несколько раз в день. Без mosh мне бы приходилось сначала убивать зависшее соединение и потом заново подключаться и вводить пароль. Это раздражает. Мне нравится когда, например, почтовый клиент всегда открыт а не требует каких-то манипуляций каждый раз перед использованием. Так и с терминалом.
kiba
24.10.2019 07:13Почему вы считаете что mosh менее безопасен чем обычный ssh?
я не утверждаю такое, но в любом случае, mosh — это дополнительный потенциальный вектор атаки.
Я закрываю-открываю ноутбук по несколько раз в день
Ок, я понял. Возможно, я не обращаю на такие мелочи внимания, потому что в основном работаю с десктопа, и в случае если надо отключить сеть — просто свернул бы tmux-сеанс и разорвал бы ssh-сессию перед этим. В случае переавторизации по ключу — пароль вводить не надо, т.ч. потери времени минимальны.
amarao
24.10.2019 08:03Альтернативно, достаточно иметь vpn-соединение и пускать ssh-трафик через него. В этом случае каждый раз ssh продолжает работать с того же самого (vpn-ip), и разрывов не происходит. Если выключен keepalive, то ноутбук после suspend/resume прекрасно продолжит сессию даже если ноут пару суток пролежал в отключке.
DmitryKoterov
24.10.2019 10:33+1Даже если сервер что-то шлет в stdout? Мне кажется, он получит “broken pipe” через несколько килобайт.
amarao
24.10.2019 10:50Если у вас что-то шлёт в stdout на сервере (т.е. запущено) надолго, то вы используете сервер "не так". Обычно консоли открыты "в середине дебага" (т.е. ничего не происходит). Если происходит — screen/nohup/systemd.
firk
24.10.2019 22:16Поддерживаю, по-моему это очевидный способ. И он лучше сразу по двум причинам:
1) вместо замены механизмов безопасности ssh на непроверенные механизмы mosh, тут ssh никуда не девается, но дополнительно обёртывается в её один слой безопасности (который даже если и дырявый, то максимум что может испортить это сбросить соединение)
2) виртуальные экраны (tmux, screen) иногда плохо себя ведут при запуске в них чего-то чуть более сложного чем обычный шелл; аналогично видимо и с самим mosh; а в случае ssh over vpn всё будет обычно
13werwolf13
24.10.2019 09:09Существует такая весччь как byobu, по сути конфиг для tmux (tmux на стероидах). Всё то-же самое что и tmux но с удобными хоткеями и удобным тюнингом строки состояния с кучей информативных вариаций.
WebMonet
24.10.2019 09:24Добавлю пару капель в бочку меда про tmux
1. окна tmux умеют как-то совсем страшно ломаться после попадания на stdout бинарных данных. Приходится на ощупь кастовать заклинание
stty sane; printf '\033k%s\033\\\033]2;%s\007' "`basename "$SHELL"`" "`uname -n`"; tput reset; tmux refresh
2. Работал с ноутбука в tmux, потом залез с телефона, потом возвращаюсь в ноутбук, а там все окна стали меньше, не на «фулл-скрин».zhovner
24.10.2019 10:52Работал с ноутбука в tmux, потом залез с телефона, потом возвращаюсь в ноутбук, а там все окна стали меньше, не на «фулл-скрин».
В этом случае нужно подключаться с опцией -d, тогда старую сессию отключит и окна будут нормального размера.
tmux attach -d
DmitryKoterov
24.10.2019 10:40+2Еще две копейки к статье:
- Mosh не работает с midnight commander. И не может даже теоретически.
- Есть ему альтернатива, EternalTerminal, и в нем mc ok. Работает он по tcp (а не по udp), но, как легко увидеть, протокол тут вообще ни при чем — можно сделать хоть поверх http. Есть у EternalTerminal, правда, и недостаток (неисправимый даже теоретически): если сервер решил передать 1 гб данных после закрытия крышки, то при открытии крышки весь этот гигабайт честно приедет в консоль и там отрисуется (не делайте tail -f с EternalTerminal). В mosh такой проблемы нет, ибо он имеет свой собственный скрин-буфер (почему mc и не работает).
- У tmux-а есть нативная интеграция с iterm2 (привет маководам). Табы терминала автоматически и прозрачно преобразуются в окна tmux-а и наоборот, причем даже плиточная раскладка сохраняется. И с EternalTerminal это работает тоже.
Мой выбор долгое время был EternalTerminal+tmux+iterm2 с нативной интеграцией.
iig
24.10.2019 11:47Открывая крышку ноутбука, все мои десятки SSH-сессий сразу доступны
Проезжая мимо станции, с меня слетела шляпа (Ц) ;)
a-l-e-x
24.10.2019 12:38Если кому интересно посмотреть — один из вариантов конфигурации tmux:
github.com/samoshkin/tmux-config
dim2r
24.10.2019 13:01Чем-то похоже на команду screen.
Там тоже можно создавать перманентные сессии и потом подключаться к ним.
linuxize.com/post/how-to-use-linux-screen
AirCommanderStarscream
24.10.2019 16:02Статья хороша, но небольшое НО — на сетевом оборудовании обычно настраивается ssh-таймаут, чтоб неактивные сессии убивались, по очевидным причинам.
Bessnov
24.10.2019 19:23Очень простой вопрос про безопасность такого решения.
Вы просто открываете крышку ноутбука и сразу доступны все консоли серверов? Причём, везде настроена авторизация по ключам и отключены запросы паролей?
Ноутбук такая мобильная вещь.
А что будет если вы оставите его без присмотра или ноутбук в результате криминала окажется в чужих руках?
Да это просто дырищща с точки зрения безопасности!
maikus
24.10.2019 21:08Вместо ssh использовал VNCscraping+OpenVPN. Довольно удобно оказалось, и разрывы ничего не портят. Хотя, с каким-нибудь домашним роутером так не получится связаться, наверное.
Dima4ka
25.10.2019 05:34А чем byobu не устраивает?
Также с точки зрения безопасности напрягает формулировка «логинимся все на одного пользователя»
click0
25.10.2019 09:52Раз используете терминальный сервер, то в /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 по вкусу.
Undiabler
Что насчет безопасности самого mosh протокола? Насколько можно судить по доступной информации, эта udp надстройка совершенно кастомная и никогда не проходила аудит.
zhovner
Трафик mosh шифруется AES-128, обмен ключами происходит по обычному SSH в момент подключения. Насколько сам протокол хорошо сделан, я конечно не знаю.