Комментарии 63
Давно поглядываю на tmux, но на серверах, зачастую, предустановлен screen, поэтому переход затрудняется.
Нет, tmux запускается только на терминальном сервере. Каждая SSH-сессия живет в отдельном окне тмукса. Предполагается что связь между серверами достаточно стабильна.
В tmux можно поделить окно на несколько pane-ов и в каждом открыть еще одну SSH сессию. Я тупо открываю несколько коннектов к одному серверу в одном окне.
В статье не описывает проброс 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 переменная будет указывать на старый, который был при запуске сессии.
Чтобы что-нибудь сконфигурить да, а чтобы логи погрепать сразу на десятке серверов нет
Ну камон, вот приспичило чего-нибудь на коленках глянуть, инфраструктуру поднимать на десяток человеко-часов или глянуть по быстрому через несколько pane в tmux?)))
Бонусом идёт возможность навесить алёрты на возникновение ошибок или превышение ззаданного количества определённых сообщений в единицу времени.
dsh –aM –c uptime
OpenSSH не закрывает коннект просто по неактивности. Настройки KeepAlive касаются только самого подключения на уровне TCP.
Я и не только про SSH говорю, собственно
А про что еще можно говорить в этом контексте?
Хотя и там зачастую бывает настроен таймаут.
Я ошибся, действительно автоматический дисконнект по idle можно настроить:
/etc/ssh/sshd_config
ClientAliveInterval 300 # таймаут пять минут
ClientAliveCountMax 0Но так делать неправильно, если вы запустите какую-то команду, которая будет выполняться дольше этого таймаута, она просто сломается и не выполнится.
Поэтому я ограничиваю idle сессии.
- При взломе сервера дальнейшая компрометация остальных систем только дело времени
- При увольнении сотрудника смена паролей и ключей бесполезна, так как он остаётся залогинен.
При взломе сервера дальнейшая компрометация остальных систем только дело времени
Если с сервера можно ходить на другие сервера — то независимо от наличия висящих сессий взлом этого сервера даст доступ к остальным серверам, вопрос только во времени.
При увольнении сотрудника смена паролей и ключей бесполезна, так как он остаётся залогинен.
Если сессии сотрудника висят на сервере, но сотрудника уволили — то убиваем все процессы принадлежащие юзеру, потом самого юзера. Всё, профит. Главное — сразу организовать схему с терминальным сервером.
Если с сервера можно ходить на другие сервера — то независимо от наличия висящих сессий взлом этого сервера даст доступ к остальным серверам, вопрос только во времени.
ssh google oauth
Если сессии сотрудника висят на сервере, но сотрудника уволили — то убиваем все процессы принадлежащие юзеру, потом самого юзера. Всё, профит. Главное — сразу организовать схему с терминальным сервером.
аккаунты могут быть не только личные
Кроме перечисленного, я лично использую еще http://byobu.co/ (фактически кастомный конфиг дляtmux/screen с неким "автозапуском")
В свое время, после перехода на 3G, меня достали постоянные обрывы SSH сессий по таймауту. В конечном счете полностью снял проблему тремя строками в ~/.ssh/config:
Host *
ServerAliveInterval 30
ServerAliveCountMax 2Раннее я пробовал пользоваться mosh, но, как оказалось, он не работает с прокруткой окна и не умеет монтировать удаленную ФС как sshfs. Пришлось выбросить.
Так ли необходимо жертвовать безопасностью
Почему вы считаете что mosh менее безопасен чем обычный ssh?
в чем здесь сакральный смысл использования Mosh
Я закрываю-открываю ноутбук по несколько раз в день. Без mosh мне бы приходилось сначала убивать зависшее соединение и потом заново подключаться и вводить пароль. Это раздражает. Мне нравится когда, например, почтовый клиент всегда открыт а не требует каких-то манипуляций каждый раз перед использованием. Так и с терминалом.
Почему вы считаете что mosh менее безопасен чем обычный ssh?
я не утверждаю такое, но в любом случае, mosh — это дополнительный потенциальный вектор атаки.
Я закрываю-открываю ноутбук по несколько раз в день
Ок, я понял. Возможно, я не обращаю на такие мелочи внимания, потому что в основном работаю с десктопа, и в случае если надо отключить сеть — просто свернул бы tmux-сеанс и разорвал бы ssh-сессию перед этим. В случае переавторизации по ключу — пароль вводить не надо, т.ч. потери времени минимальны.
_
Альтернативно, достаточно иметь vpn-соединение и пускать ssh-трафик через него. В этом случае каждый раз ssh продолжает работать с того же самого (vpn-ip), и разрывов не происходит. Если выключен keepalive, то ноутбук после suspend/resume прекрасно продолжит сессию даже если ноут пару суток пролежал в отключке.
Даже если сервер что-то шлет в stdout? Мне кажется, он получит “broken pipe” через несколько килобайт.
Поддерживаю, по-моему это очевидный способ. И он лучше сразу по двум причинам:
1) вместо замены механизмов безопасности ssh на непроверенные механизмы mosh, тут ssh никуда не девается, но дополнительно обёртывается в её один слой безопасности (который даже если и дырявый, то максимум что может испортить это сбросить соединение)
2) виртуальные экраны (tmux, screen) иногда плохо себя ведут при запуске в них чего-то чуть более сложного чем обычный шелл; аналогично видимо и с самим mosh; а в случае ssh over vpn всё будет обычно
1. окна tmux умеют как-то совсем страшно ломаться после попадания на stdout бинарных данных. Приходится на ощупь кастовать заклинание
stty sane; printf '\033k%s\033\\\033]2;%s\007' "`basename "$SHELL"`" "`uname -n`"; tput reset; tmux refresh2. Работал с ноутбука в tmux, потом залез с телефона, потом возвращаюсь в ноутбук, а там все окна стали меньше, не на «фулл-скрин».
Работал с ноутбука в tmux, потом залез с телефона, потом возвращаюсь в ноутбук, а там все окна стали меньше, не на «фулл-скрин».
В этом случае нужно подключаться с опцией -d, тогда старую сессию отключит и окна будут нормального размера.
tmux attach -d
Еще две копейки к статье:
- Mosh не работает с midnight commander. И не может даже теоретически.
- Есть ему альтернатива, EternalTerminal, и в нем mc ok. Работает он по tcp (а не по udp), но, как легко увидеть, протокол тут вообще ни при чем — можно сделать хоть поверх http. Есть у EternalTerminal, правда, и недостаток (неисправимый даже теоретически): если сервер решил передать 1 гб данных после закрытия крышки, то при открытии крышки весь этот гигабайт честно приедет в консоль и там отрисуется (не делайте tail -f с EternalTerminal). В mosh такой проблемы нет, ибо он имеет свой собственный скрин-буфер (почему mc и не работает).
- У tmux-а есть нативная интеграция с iterm2 (привет маководам). Табы терминала автоматически и прозрачно преобразуются в окна tmux-а и наоборот, причем даже плиточная раскладка сохраняется. И с EternalTerminal это работает тоже.
Мой выбор долгое время был EternalTerminal+tmux+iterm2 с нативной интеграцией.
Открывая крышку ноутбука, все мои десятки SSH-сессий сразу доступны
Проезжая мимо станции, с меня слетела шляпа (Ц) ;)
github.com/samoshkin/tmux-config
Там тоже можно создавать перманентные сессии и потом подключаться к ним.
linuxize.com/post/how-to-use-linux-screen
Статья хороша, но небольшое НО — на сетевом оборудовании обычно настраивается ssh-таймаут, чтоб неактивные сессии убивались, по очевидным причинам.
Вы просто открываете крышку ноутбука и сразу доступны все консоли серверов? Причём, везде настроена авторизация по ключам и отключены запросы паролей?
Ноутбук такая мобильная вещь.
А что будет если вы оставите его без присмотра или ноутбук в результате криминала окажется в чужих руках?
Да это просто дырищща с точки зрения безопасности!
А чем byobu не устраивает?
Также с точки зрения безопасности напрягает формулировка «логинимся все на одного пользователя»
не забываем внести:
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
Терминальный сервер для админа; Ни единого SSH-разрыва