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

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

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

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

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

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

Что если нужно по несколько окон для каждого сервера?
Не знаю как в tmux, а у меня вот такое сокращение для присоединения к серверу с одновременным поднятием screen на сервере или с присоединением к существующей сессии screen:
alias server1='mosh root@server1 -- screen -xRR -D'
Ну так и с tmuxʼом можно точно так же. (Я испытал это, но вернулся на screen по привычке.) Символ переключения настраивается, и можно и на одном хосте несколько сессий — точно так же, как у screen. Стиль другой, но понятный.

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


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


Host my-terminal-server.com
  ForwardAgent yes

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

Вообще вопрос проброса ключей и прост и сложен одновременно, многие моменты, как регулярно выясняется, не ясны большинству начинающих пользователей. И если делать вещи «в лоб», как описано во многих инструкциях, можно напороться на проблемы. Лишь часть из них:
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 переменная будет указывать на старый, который был при запуске сессии.
Тоже использую tmux и иногда надо войти сразу на кучу серверов и сделать там что-нибудь одинаковое, написал вот такую утилитку pastebin.com/wV8Lt54W

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

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

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

Для быстрого просмотра в начале пути — можно и напрямую с серверов, но если счёт идёт реально на десятки и сотни нод, то имеет смысл задумать о централизованном хранилище логов. Реально облегчает задачу поиска узкого места!
Бонусом идёт возможность навесить алёрты на возникновение ошибок или превышение ззаданного количества определённых сообщений в единицу времени.
А как решается проблема отвала по неактивности между терминальным и конечными серверами?

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

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

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


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

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


/etc/ssh/sshd_config


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

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

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

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

Всё-таки нестандартный порт немного снижает количество попыток проникнуть на сервер.
В моём случае после применения нестандартного порта для SSH попытки проникновения прекратились совсем. Уже лет семь не ломятся. Пока был порт 22, попытки подбора пароля шли постоянно. Мне кажется, ломателям логично не тратить время на перебор стандартных комбинаций паролей, ведь если хозяин сервера поменял порт, то и пароль у него точно не qwerty123.
UFO landed and left these words here
Поддерживаю! На свежих 5 VPS, пока не поменял порт, за день было до 5к неудачных логинов, после смены порта = 0.

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


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

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

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

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

ssh google oauth

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

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

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

как по мне, у screen только один существенный минус: в одной сессии нельзя создать больше ~30 окон. Хотя, может я ошибаюсь и это тоже настраивается.
На Ubuntu вот умолчательный максимум 100, вообще оно давно регулируется в конфиге (параметр maxwin).

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


Host *
    ServerAliveInterval 30
    ServerAliveCountMax 2

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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


  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 с нативной интеграцией.

Mosh не работает с midnight commander. И не может даже теоретически.

Погоди, как это не работает? Только что проверил на открытой mosh-сессии — вроде всё работало. А что именно не так?
Открывая крышку ноутбука, все мои десятки SSH-сессий сразу доступны


Проезжая мимо станции, с меня слетела шляпа (Ц) ;)

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

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

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

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

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


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

Раз используете терминальный сервер, то в /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 по вкусу.

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

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

возможно, глупый вопрос: но что значит открывает? udp же не имеет connect в том же смысле что и tcp
Only those users with full accounts are able to leave comments. , please.