Комментарии 116
С виду неплохое решение. А сколько по времени сервер держит инстанс при разрыве связи? Через сколько времени после разрыва можно гарантированно восстановить работу?
Если оконо mosh-клиента остается открытым, и удаленный сервер не перезагружался (или каким-либо другим способом mosh-server не убили) — то вечно.
Если же, терминал с клиентом закрыли, и переподключаетесь еще раз — то mosh скажет, что у вас есть detached сессия. Ну, просто предупредит. Подключиться к ней нельзя заново — из security-соображений. Можно только убить mosh-server от той сессии, чтобы не висело почем зря.
Если же, терминал с клиентом закрыли, и переподключаетесь еще раз — то mosh скажет, что у вас есть detached сессия. Ну, просто предупредит. Подключиться к ней нельзя заново — из security-соображений. Можно только убить mosh-server от той сессии, чтобы не висело почем зря.
В гифке список вайфай сетей улыбнул )))
То есть держать на сервере открытый screen с теми же целями уже не модно?
как я понимаю тут вопрос в том, что не надо делать реконнект вручную, оно само все должно сделать… плюс и screen не надо реаттачить, вообщем автоматизация процесса для ленивых…
В этом случае можно подставить такой костыль: пробросить удаленный порт на свою локальную машину при помощи autossh, и цепляться терминалом уже к нему:
Здесь:
autossh -M 7250 -N -L 2222:127.0.0.1:22 remote.com
Здесь:
- -M 7250 — указание autossh использовать этот порт для контроля наличия соединения
- -N — указание ssh соединиться без исполнения удаленных команд
- -L — проброс локального порта на удаленный
- 2222 — локальный порт, к которому привяжется порт с сервера
Не пошел мне screen, сколько не пытался к нему привыкнуть.
Да и тут он не замена: проблему лагов не решает, и реконнект прозрачный не сделаешь.
Кроме того — вот взять «восстановление сессии»: в mosh я просто открываю ноут и жду 10 секунд и могу работать. Со screen, как я понимаю — мне нужно заново переконнектиться, ввести пароль (если по паролю), запустить screen. Это в затратах на телодвижения — 0 vs 10 :) В бесконечное количество раз, тоесть )))
Да и тут он не замена: проблему лагов не решает, и реконнект прозрачный не сделаешь.
Кроме того — вот взять «восстановление сессии»: в mosh я просто открываю ноут и жду 10 секунд и могу работать. Со screen, как я понимаю — мне нужно заново переконнектиться, ввести пароль (если по паролю), запустить screen. Это в затратах на телодвижения — 0 vs 10 :) В бесконечное количество раз, тоесть )))
в ~.profile надо прописать
и screen будет запускаться автоматом в интерактивной сессии. А если уже есть сессия screen, то именно к этой сессии и будет происходить подключение.
Для долгоиграющих процессов (тесты запустили / wget / сборка) screen или tmux — единственное нормальное решение.
screen -dRR
и screen будет запускаться автоматом в интерактивной сессии. А если уже есть сессия screen, то именно к этой сессии и будет происходить подключение.
Для долгоиграющих процессов (тесты запустили / wget / сборка) screen или tmux — единственное нормальное решение.
А если сервером пользуются несколько людей (под одним юзером)? Другой человек зайдет и подключится к моей отдетаченой сессии screen?
Если сервером пользуются несколько людей под одной учеткой — это само по себе уже проблема бОльшая, чем все остальное, и это первое, что надо исправить. :-)
В общем случае, безусловно. Для каждого пользователя свой UNIX-юзер, да. Но в том частном случае, с которым приходится иметь дело мне — это внутренний сервер, который реинсталлится каждый раз после билда проекта, и регулярно приходится заходить то одним, то другим людям, проверять/исправлять какие-то вещи. В силу определенных (хардварных) причин, мне код проще запускать и тестить прямо на сервере, что я регулярно и делаю. Создавать на каждого члена компании UNIX-пользователя, просто чтобы screen не перехватывался? Ну, не, спасибо, тем более что этот сервер в такой же конфигурации должен идти в продакшн и там менеджмент доступа вообще отдельным путем регулируется.
Mosh все-таки тут правильнее этот вопрос решает, с точки зрения security. Неудобнее иногда, но правильнее.
Mosh все-таки тут правильнее этот вопрос решает, с точки зрения security. Неудобнее иногда, но правильнее.
В этом случае, проблема не в screen, а в том что сервером пользуются несколько людей (под одним юзером).
Это не проблема, а реальный юз-кейс. Если вы мне скажете, что никто не дает коллегам/другу логин/пароль на свой тестовый сервер для какой-то быстрой помощи, а заводит отдельного юзера каждый раз — то я вам не поверю, хотя, безусловно, соглашусь, что это было бы правильнее. Но люди такие люди же :)
См. ответ выше. habrahabr.ru/post/243651/#comment_8134843
См. ответ выше. habrahabr.ru/post/243651/#comment_8134843
Работа в screen не отличается от работы в обычном терминале, если не нажимать всякие разные хитрые комбинации клавиш (ctrl+a — screen, ctrl+b — tmux).
К тому же, на все подключения (до убивания процесса) будет единая история. Один пользователей или много — не принципиально. Или вы пытаетесь скрыть от коллег то, что вы там делаете?:)
Ну не запускайте тогда screen именно для этого пользователя guest. Причём тут mosh?
К тому же, на все подключения (до убивания процесса) будет единая история. Один пользователей или много — не принципиально. Или вы пытаетесь скрыть от коллег то, что вы там делаете?:)
Ну не запускайте тогда screen именно для этого пользователя guest. Причём тут mosh?
Господа, а вот что вы сейчас пытаетесь доказать? Что авторы mosh — тупые, не поняли, что могли бы просто screen использовать и, как тут замечательно написали, «вдумчиво работать в консоли»? )
Mosh — сохраняет соединение (и, как следствие — сессию и контекст), screen — только сессию, и все равно вынуждает переподключаться (да, можно ставить бесконечные keepalive на каждом SSH-сервере, тюнить и все такое — но в какой-то момент вам надоесть каждый раз под себя тюнить все сервера, особенно если они не ваши и тюнить там нельзя ничего).
Mosh — решает еще несколько проблем юзабилити remote shell, screen — нет.
По какой причине я, как пользователь remote shell, должен захотеть поменять удобный all-in-one mosh-solution, на стек решений и хаков screen/tmux/vpn/ssh-tuning/etc? При прочих равных всегда выигрывает решение, требующее меньшего количества телодвижений, не так ли?
Mosh — сохраняет соединение (и, как следствие — сессию и контекст), screen — только сессию, и все равно вынуждает переподключаться (да, можно ставить бесконечные keepalive на каждом SSH-сервере, тюнить и все такое — но в какой-то момент вам надоесть каждый раз под себя тюнить все сервера, особенно если они не ваши и тюнить там нельзя ничего).
Mosh — решает еще несколько проблем юзабилити remote shell, screen — нет.
По какой причине я, как пользователь remote shell, должен захотеть поменять удобный all-in-one mosh-solution, на стек решений и хаков screen/tmux/vpn/ssh-tuning/etc? При прочих равных всегда выигрывает решение, требующее меньшего количества телодвижений, не так ли?
У этого решения на настоящий момент есть два глобальных минуса: нет скролла и главное — нет аудита протокола.
Что касается решения «швейцарский армейский нож для расстрела урановыми ломами тушканчиков в Антарктике прямой наводкой из космоса» — это грубое нарушение KISS и Unix Way в частности. Конечно, это уже философский вопрос и вкусовщина, но когда у меня этот клятый systemd отказался перезагружать машину из-за невозможности соединиться с DBus, я долго ругался на /П[а-я]*а/g который сломал такой милый униксвейный Init и заменил его на это вот кособокое бинарное нечто с зависимостью от десктопного API.
Так что уж лучше цепочка из инструментов, каждый из которых решает свою задачу:
Что касается решения «швейцарский армейский нож для расстрела урановыми ломами тушканчиков в Антарктике прямой наводкой из космоса» — это грубое нарушение KISS и Unix Way в частности. Конечно, это уже философский вопрос и вкусовщина, но когда у меня этот клятый systemd отказался перезагружать машину из-за невозможности соединиться с DBus, я долго ругался на /П[а-я]*а/g который сломал такой милый униксвейный Init и заменил его на это вот кособокое бинарное нечто с зависимостью от десктопного API.
Так что уж лучше цепочка из инструментов, каждый из которых решает свою задачу:
- screen — удержание сессии, мультиплексор
- OpenVPN — роуминг, криптография и реконнект
- ssh — транспорт и еще раз криптография.
Про минусы принимается.
Про «лучше уж» — это уже кому-как. У меня нет возможности на большинстве серверов, с которыми приходится работать, поднимать OpenVPN. Подозрений в том, что SSP протокол тайно взломан, и есть кто-то, кто перехватит мои соединения и будет смотреть, как я пишу код на удаленном сервере — тоже пока что нет ) Поэтому для меня лично пока что вариант «запустить mosh и получить 100500 плюшек» выигрывает в сравнении с «устанавливать на сервер стек решений, хаков, учить новые комбинации клавиш, тюнить сервера и получить 100500/10 плюшек».
Но согласен, что кому-то это может быть более релевантно и решение VPN/screen/ssh будет более правильным.
Про «лучше уж» — это уже кому-как. У меня нет возможности на большинстве серверов, с которыми приходится работать, поднимать OpenVPN. Подозрений в том, что SSP протокол тайно взломан, и есть кто-то, кто перехватит мои соединения и будет смотреть, как я пишу код на удаленном сервере — тоже пока что нет ) Поэтому для меня лично пока что вариант «запустить mosh и получить 100500 плюшек» выигрывает в сравнении с «устанавливать на сервер стек решений, хаков, учить новые комбинации клавиш, тюнить сервера и получить 100500/10 плюшек».
Но согласен, что кому-то это может быть более релевантно и решение VPN/screen/ssh будет более правильным.
А разве у screen есть скролл?
Специально зашел, сделал ls -n в /dev — все прекрасно проскроллилось. Терминал guake.
У меня screen 4.01.00devel (из стандартного пакета Mint), guake 0.4.4.
Скролл никогда не работал.
ЧЯДНТ?
Может, конфиги править нужно?
Скролл никогда не работал.
ЧЯДНТ?
Может, конфиги править нужно?
У меня вот такой:
И такой /etc/screenrc
Screen version 4.02.01 (GNU) 28-Apr-14
И такой /etc/screenrc
# this is the global screenrc file. Handle with care.
termcapinfo xterm* G0:is=\E[?4l\E>:ti@:te@
termcapinfo linux me=\E[m:AX
Под скроллом вы ведь понимаете скролл мышью плюс PageUp/PageDown?
Вот что я нашёл: www.linuxscrew.com/2008/11/14/faq-how-to-scrollback-in-gnu-screen/
Но там для скроллинга требуется нажать комбинацию клавиш (кстати, помогло; теперь я могу скроллить хотя бы так :) ).
Вот что я нашёл: www.linuxscrew.com/2008/11/14/faq-how-to-scrollback-in-gnu-screen/
Но там для скроллинга требуется нажать комбинацию клавиш (кстати, помогло; теперь я могу скроллить хотя бы так :) ).
да, вам надо перейти в режим копирования:
C-a [ или C-a C-[ или C-a <ESC>
кстати, в этом режиме работает поиск: / и? (вниз и вверх)
C-a [ или C-a C-[ или C-a <ESC>
кстати, в этом режиме работает поиск: / и? (вниз и вверх)
Да, с режимом копирования уже разобрались, спасибо.
Но вот у товарища выше и скролл мышью работает.
Но вот у товарища выше и скролл мышью работает.
Если использовать guake и работать в screen локально, то прокрутка мышью будет работать, да :)
Она не будет работать на удалённой машине.
Она не будет работать на удалённой машине.
Нет, пробовал локально.
Я специально еще раз подключился к удаленной машине, подключился к сессии
вывел список кучи имен из /dev
и все прекрасно поскроллилось.
screen -x
вывел список кучи имен из /dev
ls -n /dev
и все прекрасно поскроллилось.
не совсем правильная проверка.
Сделайте так:
ctrl + a, c (создаём новую вкладку в screen)
в ней снова
ctrl + a, p
и вот тут интересное. Если вы перейдёте в режим копирования (ctrl + a, [), жмите pg up сколько угодно, у вас пустая история «сверху». А если будете крутить колёсиком — покажется буфер из другого окна. Скорее всего. Если не так — то прошу прощения, у вас всё круто работает, у меня так и не получилось это завести.
Сделайте так:
screen -x
$ ls -la
$ something1 # специальная несуществующая команда
ctrl + a, c (создаём новую вкладку в screen)
в ней снова
$ ls -la
$ something2 # специальная несуществующая команда #2
ctrl + a, p
и вот тут интересное. Если вы перейдёте в режим копирования (ctrl + a, [), жмите pg up сколько угодно, у вас пустая история «сверху». А если будете крутить колёсиком — покажется буфер из другого окна. Скорее всего. Если не так — то прошу прощения, у вас всё круто работает, у меня так и не получилось это завести.
Как говорится — УМВР — на той машине много чего открыто, в частности, несколько терминальных сессий до коммутаторов, в которых я делал
что приводит к выплевыванию всей конфигурации в пару сотен строк в терминал. Я могу свободно гулять по вкладкам по Ctrl-A-[цифра], (и после переподключений тоже, в тесте с ls я долистал до вчерашней выдачи) и мотать эти портянки логов скроллингом. Специально я ничего не настраивал, дистрибутив — OpenSuse 13.2 и там и там.
sh runni
что приводит к выплевыванию всей конфигурации в пару сотен строк в терминал. Я могу свободно гулять по вкладкам по Ctrl-A-[цифра], (и после переподключений тоже, в тесте с ls я долистал до вчерашней выдачи) и мотать эти портянки логов скроллингом. Специально я ничего не настраивал, дистрибутив — OpenSuse 13.2 и там и там.
лично я спорю с этим утверждением:
вы либо не понимаете, зачем нужен screen, либо не понимаете, как им предлагают пользоваться.
как выглядит у вас работа с mosh:
как выглядит работа в screen запущенном на сервере:
преимущество работы в screen в том, что если (когда) у вас перезагрузится ноутбук или вы зайдёте с другой машины, то вся ваша история команд и вывод на экран останется, т.к. screen хранит её у себя. Если вы не хотите ничего настраивать — работайте в screen / tmux как в обычном терминале, не лезьте в конфиг, не используйте внутрисерверные вкладки, разделение консоли и т.п… Не для вас это. Всё равно удобнее.
Когда вы запустите сборку / установку чего-то на сервере и закроете крышку, команда внутри screen всё равно продолжит выполняться. А то, как вы подключились — через mosh или ssh уже не важно.
Кроме того — вот взять «восстановление сессии»: в mosh я просто открываю ноут и жду 10 секунд и могу работать. Со screen, как я понимаю — мне нужно заново переконнектиться, ввести пароль (если по паролю), запустить screen. Это в затратах на телодвижения — 0 vs 10
вы либо не понимаете, зачем нужен screen, либо не понимаете, как им предлагают пользоваться.
как выглядит у вас работа с mosh:
- открываете ноут
- ждёте 10 секунд
- работаете
как выглядит работа в screen запущенном на сервере:
- открываете ноут
- ждёте 10 секунд
- работаете
преимущество работы в screen в том, что если (когда) у вас перезагрузится ноутбук или вы зайдёте с другой машины, то вся ваша история команд и вывод на экран останется, т.к. screen хранит её у себя. Если вы не хотите ничего настраивать — работайте в screen / tmux как в обычном терминале, не лезьте в конфиг, не используйте внутрисерверные вкладки, разделение консоли и т.п… Не для вас это. Всё равно удобнее.
Когда вы запустите сборку / установку чего-то на сервере и закроете крышку, команда внутри screen всё равно продолжит выполняться. А то, как вы подключились — через mosh или ssh уже не важно.
Это я понимаю.
Но со screen у меня не исчезает надобность реконнекта, не так-ли?
Но со screen у меня не исчезает надобность реконнекта, не так-ли?
Да, такая надобность не исчезает, потому что screen не является той самой программой, которая обеспечивает вам подключение к удалённому серверу. Это терминал. Поэтому я и написал, что это не взаимозаменяемые, а взаимодополняющие вещи.
С vim / emacs та же история. Вы можете набирать себе документик через echo. Но в редакторе на удалённом сервере-то удобнее (если нет возможности набрать локально и скопировать).
С vim / emacs та же история. Вы можете набирать себе документик через echo. Но в редакторе на удалённом сервере-то удобнее (если нет возможности набрать локально и скопировать).
Тогда можно добавить флаг -x (multiuser mode). Вот кто-то удивится, увидев что курсор сам набирает команды :)))
screen прекрасно работает вместе с mosh. Вы запускаете screen на сервере, а mosh обеспечивает вам функционал из разряда «пришёл с работы домой с ноутом, крышку открыл, соединение восстановилось».
вот что не сказали, так это то, что mosh не умеет ssh-key-forwarding. По тем же соображениям безопасности.
вот что не сказали, так это то, что mosh не умеет ssh-key-forwarding. По тем же соображениям безопасности.
Сильно сомневаюсь, что восстановилось. На работе — коннект по местной локалке с местными приватными IP. Дома — к части серверов — по внешним IP, к части — по умолчанию вообще никак, к части — через VPN (который может быть в том числе каким-нибудь ssh-based и тогда IP тоже будут уже не те).
Ну вы еще порты ssh-сервера меняйте при работе из дому и с работы, и возмущайтесь ) В вашем варианте, конечно, не будет работать.
Такое можно реализовать с использованием внешнего сервера (тогда и NAT-панчинг можно красиво сделать), но это уже совсем другой сервис.
Такое можно реализовать с использованием внешнего сервера (тогда и NAT-панчинг можно красиво сделать), но это уже совсем другой сервис.
мнэээ
я не знаю как в вашем конкретном случае это будет работать, но у меня действительно работает вот так:
я не знаю как в вашем конкретном случае это будет работать, но у меня действительно работает вот так:
- на работе сижу через ethernet, без vpn
- закрываю крышку
- иду в переговорку, переключаюсь на wifi, без vpn (продолжает работать)
- закрываю крышку
- приезжаю домой, открываю — коннекта нет. Подключаюсь через vpn — соединение само восстанавливается
Уехал в отпуск, открыл ноут, а там соединение с работой восстановилось: Р
Сколько лет я не знал про screen! Яж для сохранения сессии xrdp ставил. спасибо, теперь буду знать.
Отсутствие скроллинга — почти фатальная проблема. Часто нужны данные от вывода команды на 5-7 экранов вверх, и найти там данные проще, чем их выписывать во всякие блокнотики.
совместно с tmux или emacs в качестве мультиплексера скроллинг работает. плюс, они обещали допилить это в будущих релизах.
К тому же, tmux можно запускать при интерактивных сессиях автоматически. Вот пример из моего .zshrc:
mosh_test=$(pstree -s $PPID | egrep -o 'mosh-server')
if [[ "$mosh_test" == "mosh-server" ]]
then
STARTED_TMUX=1; export STARTED_TMUX
((tmux has-session -t remote && tmux attach-session -t remote) || (tmux new-session -s remote) ) && exit 0
echo "tmux failed to start"
fi
При наличии tmux / screen / emacs — не очень понятно, зачем нужен собственно mosh…
это параллельные вещи. mosh — замена ssh. все что Вы перечислили, работает и там и там.
Да как-то ни разу не вижу, чтобы это были параллельные вещи. mosh — это ssh + терминал-контейнер (типа tmux/screen/emacs/...), причем весьма ограниченный в отличие от упомянутых выше + собственный протокол в UDP с переоткрываемыми портами (возможно, сомнительный с точки зрения безопасности). Да, запустить в этом tmux можно (как, собственно, никто не мешает запустить tmux-в-tmux), но тогда, собственно, от mosh остается что — только автоматический реконнект?
от mosh остается собственный протокол (собственно он особенно ни на что большее и не претендует), который, как вы правильно заметили, позволяет делать автоматический реконнект (что по-моему уже является огромным плюсом), но и еще заметно уменьшать лаги при нестабильном подключении.
я конечно могу говорить только по собственному опыту, но работать с mosh при среднего качества WIFI намного приятнее чем с ssh. то же самое верно если вы часто переключаетесь между разными сетями. на страничке проекта авторы приводят результаты более объективных бенчмарков.
я конечно могу говорить только по собственному опыту, но работать с mosh при среднего качества WIFI намного приятнее чем с ssh. то же самое верно если вы часто переключаетесь между разными сетями. на страничке проекта авторы приводят результаты более объективных бенчмарков.
Ну я вижу только один очень значительный плюс — мгновенная отдача Ctrl+C.
Зато минусы меня останавливают, и желания пользоваться mosh'ем отпадает.
Зато минусы меня останавливают, и желания пользоваться mosh'ем отпадает.
Ctrl+C относительно терпимо сработает и в любом терминало-контейнере типа упомянутых выше. В крайнем случае никто не мешает переключиться на несколько секунд из этого терминала куда-то еще, чтобы не прокачивать упомянутые 500 гигабайт (хотя в реальности в tmux /… это будут уже не 500 ГБ, а какие-то их сравнительно небольшие куски, пролезшие в канал).
Для меня лично шоустоппер — это UDP и переоткрываемые порты. Я сходу могу придумать только один класс production-серверов, на котором бы у меня такое было разрешено, и то это скорее исключение, вызванное тем, что на этом классе нецелесообразно было вообще включать firewall, который бы съедал значительную часть полезных мощностей.
Для меня лично шоустоппер — это UDP и переоткрываемые порты. Я сходу могу придумать только один класс production-серверов, на котором бы у меня такое было разрешено, и то это скорее исключение, вызванное тем, что на этом классе нецелесообразно было вообще включать firewall, который бы съедал значительную часть полезных мощностей.
Статичный firewall съедает мощности?) Не поделитесь как Вам это удаётся?
Я не очень понимаю, что такое «статичный» — stateless, в смысле?..
Любой firewall, если он есть, требует какое-то время на обработку приходящего пакета. Если у меня есть web-сервер, отрабатывающий, скажем, 50K req/s в пике с мелкими запросами, весь смысл существования которого — буферизировать их на диск, внезапно только лишь загруженные инфраструктурные модули netfilter'а съедят процентов 5-6 этой производительности и будет уже ~47..48K. Наличие в цепочках порядка десятка несложных типовых правил типа «с интерфейса такого-то можно только на такой-то порт, иначе дропнуть», съест еще 3-4%. По-моему — относительно много, чтобы начать экономить.
Любой firewall, если он есть, требует какое-то время на обработку приходящего пакета. Если у меня есть web-сервер, отрабатывающий, скажем, 50K req/s в пике с мелкими запросами, весь смысл существования которого — буферизировать их на диск, внезапно только лишь загруженные инфраструктурные модули netfilter'а съедят процентов 5-6 этой производительности и будет уже ~47..48K. Наличие в цепочках порядка десятка несложных типовых правил типа «с интерфейса такого-то можно только на такой-то порт, иначе дропнуть», съест еще 3-4%. По-моему — относительно много, чтобы начать экономить.
Очень приличный плюс у mosh — это predictive local echo. Например, в электричке через 3G через mosh работать очень удобно. В отличие от ssh.
А под android клиент есть? Вроде классического ConnectBot?
Благодарю. Попробую.
Очень приятный терминал, спасибо. Смущает закрытый код, но у меня и сервер не планетарного масштаба личный.
Кстати, ни один Android SSH Client не поддерживает ни ECDSA, ни EdDSA-ключи.
Меня, кстати, несколько удивило, что ты используешь не RSA. Криптостойкость ниже?
Нет, не ниже, просто подход другой.
Ключи с эллиптической криптографией получаются меньше по размеру, а работают, как правило, быстрее.
В OpenSSH есть уже поддержка ECDSA (только NIST курвы) с версии 5.7 и EdDSA с версии 6.5.
Я стараюсь использовать везде где можно эллиптические кривые, но если у меня выбор только из NIST/Brainpool vs RSA, я выберу RSA, т.к. не доверяю первым.
safecurves.cr.yp.to/
Ключи с эллиптической криптографией получаются меньше по размеру, а работают, как правило, быстрее.
В OpenSSH есть уже поддержка ECDSA (только NIST курвы) с версии 5.7 и EdDSA с версии 6.5.
Я стараюсь использовать везде где можно эллиптические кривые, но если у меня выбор только из NIST/Brainpool vs RSA, я выберу RSA, т.к. не доверяю первым.
safecurves.cr.yp.to/
А можно где-то просветить неграмотных — чем те или иные лучше? (ключи меньше — как-то не катит на весомый аргумент). Просто академический интерес или есть реальные преимущества?
Думаю, вам будет интересно это (правда, там, в основном, конкретно про ECDSA):
blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/
blog.cloudflare.com/ecdsa-the-digital-signature-algorithm-of-a-better-internet/
blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/
blog.cloudflare.com/ecdsa-the-digital-signature-algorithm-of-a-better-internet/
Через 3Г оно работает значительно приятнее.
Для работы на тормозных соединениях.
Проблема это, когда приложение без надобности в stderr плюет то, что ожидаешь в stdout. Тогда, помимо пайпа в пейджер приходится 1>&2 делать.
Авторы, разумеется, сами над проблемой думают и планируют в mosh 1.3 чего-то придумать.
Авторы, разумеется, сами над проблемой думают и планируют в mosh 1.3 чего-то придумать.
А пока что можно сделать следующее:
1) Собрать tmux из HEAD, например с помощью «brew install --HEAD mobile-shell» (или как-то так)
2) Прописать в ~/.tmux.conf:
3) Воспользоваться терминалом с поддержкой xterm mouse events (iTerm2 к примеру) или, в случае с Terminal.app, поставить SIMBL-плагин MouseTerm, через EasySIMBL
4) Запускать mosh примерно так:
И в итоге получается tmux со включенным авто-входом в copy-режим при получении событий прокрутки мыши (выйти из copy mode можно, нажав q). Сборка mosh из HEAD нужна потому, что проброс xterm mouse events пока что нет в стабильной версии.
Отсоединяться от сервера можно по нажатию на «Ctrl+B D», чтобы оставить сессию tmux активной.
Грубо говоря, мы получаем почти такую же прокрутку мышью, как и в обычном терминале, хоть и немного лагающую, и все прелести mosh, а заодно и получить сохранение состояния соединения на сервере (благодаря tmux).
1) Собрать tmux из HEAD, например с помощью «brew install --HEAD mobile-shell» (или как-то так)
2) Прописать в ~/.tmux.conf:
new-session
set-window-option -g mode-mouse on
set -g history-limit 300000
3) Воспользоваться терминалом с поддержкой xterm mouse events (iTerm2 к примеру) или, в случае с Terminal.app, поставить SIMBL-плагин MouseTerm, через EasySIMBL
4) Запускать mosh примерно так:
mosh --no-init $hostname -- tmux a
И в итоге получается tmux со включенным авто-входом в copy-режим при получении событий прокрутки мыши (выйти из copy mode можно, нажав q). Сборка mosh из HEAD нужна потому, что проброс xterm mouse events пока что нет в стабильной версии.
Отсоединяться от сервера можно по нажатию на «Ctrl+B D», чтобы оставить сессию tmux активной.
Грубо говоря, мы получаем почти такую же прокрутку мышью, как и в обычном терминале, хоть и немного лагающую, и все прелести mosh, а заодно и получить сохранение состояния соединения на сервере (благодаря tmux).
Прошу прощения, опечатка, собрать из HEAD нужно не tmux, а mosh.
Рецепт взят отсюда: filippo.io/my-remote-shell-session-setup/
Рецепт взят отсюда: filippo.io/my-remote-shell-session-setup/
Они и прокрутку обещают сделать в 1.3, но судя по развитию репозитория это будет не скоро, если и будет когда-то.
Перезалейте джифку
С гифкой одни проблемы. Вот youtube:
www.youtube.com/watch?v=G-1cx2B13JY
www.youtube.com/watch?v=G-1cx2B13JY
Скандалы, интриги, расследования:
Вопрос: Проводился ли экспертный аудит вашего защищенного протокола обмена дейтеграммами?
Ответ: Нет. Mosh активно используется и былпроскроллен прочитан криптоманьяками, которые считают организацию протокола приемлемой. Но любой новый протокол должен быть испытан, и SSP — не исключение…
Из FAQ на Ginhub
Q: Has your secure datagram protocol been audited by experts?
No. Mosh is actively used and has been read over by security-minded crypto nerds who think its design is reasonable, but any novel datagram protocol is going to have to prove itself, and SSP is no exception...
Вопрос: Проводился ли экспертный аудит вашего защищенного протокола обмена дейтеграммами?
Ответ: Нет. Mosh активно используется и был
Из FAQ на Ginhub
А можно видео не в gif а чем-то более перематываемом и подверженном паузе?
А то отвлекся и привет.
А то отвлекся и привет.
гифка у меня не грузится. %(
А зачем такие сложности для обработки ctrl+c, если в tcp-протоколе есть специалино для этого флажок Urgent data? Потому что он плохо поддерживается? Лучше было бы его поддержку сделать.
Кроме того, висение detached-сессии на сервере — это плохо и ведет к утечкам памяти — каждая повисшая сессия чтото занимает.
Мне кажется, клиент больше представляет академическую ценность, нежели практическую. По крайней мере на данном этапе его развития — даже нет желания пробовать. Хотя для каких-то задач может он и лучше. Конечно, отсутствие скролла — большой минус.
А зачем такие сложности для обработки ctrl+c, если в tcp-протоколе есть специалино для этого флажок Urgent data? Потому что он плохо поддерживается? Лучше было бы его поддержку сделать.
Кроме того, висение detached-сессии на сервере — это плохо и ведет к утечкам памяти — каждая повисшая сессия чтото занимает.
Мне кажется, клиент больше представляет академическую ценность, нежели практическую. По крайней мере на данном этапе его развития — даже нет желания пробовать. Хотя для каких-то задач может он и лучше. Конечно, отсутствие скролла — большой минус.
Гифку заменил на youtube:
www.youtube.com/watch?v=G-1cx2B13JY
Насчет ценности — думаю, тут от характера использования SSH зависит ценность. Мне часто приходится работать долго на удаленных машинах, в том числе писать код — и нередко «передподключение» — это не просто набрать "!!" в баше, а еще и целый ритуал с переходом в нужную директорию, sudo/chroot и прочими манипуляциями. Плюс я достаточно часто нахожусь в дороге и новых местах, и «медленный интернет» для меня, увы, обыденность. Поэтому для меня лично после двух месяцев использования mosh ценность исключительно практическая, и ни капли академической :)
Для вашего характера использования ssh, возможно, иначе.
www.youtube.com/watch?v=G-1cx2B13JY
Насчет ценности — думаю, тут от характера использования SSH зависит ценность. Мне часто приходится работать долго на удаленных машинах, в том числе писать код — и нередко «передподключение» — это не просто набрать "!!" в баше, а еще и целый ритуал с переходом в нужную директорию, sudo/chroot и прочими манипуляциями. Плюс я достаточно часто нахожусь в дороге и новых местах, и «медленный интернет» для меня, увы, обыденность. Поэтому для меня лично после двух месяцев использования mosh ценность исключительно практическая, и ни капли академической :)
Для вашего характера использования ssh, возможно, иначе.
Нет, у меня все гораздо хуже с сетью. Если она медленная — она обычно еще и глючная.
Мне бы было гораздо полезней, если б оно пробивало nat и могло работать с меняющимся ip и на сервере тоже.
Т.е., исходим из того, что на клиенте и на сервере одновременно ip не меняется. И основываясь на этом, держим подключение.
Мне бы было гораздо полезней, если б оно пробивало nat и могло работать с меняющимся ip и на сервере тоже.
Т.е., исходим из того, что на клиенте и на сервере одновременно ip не меняется. И основываясь на этом, держим подключение.
Еще mosh не поддерживает форвардинг портов и иксов, что тоже сужает примнение до интерактивных терминальных сессий.
Запрос на добавление port forwarding активен с апреля 2012.
Будет хорошо, если не равнодушные читатели проголосуют за его реализацию: https://github.com/keithw/mosh/issues/120
Будет хорошо, если не равнодушные читатели проголосуют за его реализацию: https://github.com/keithw/mosh/issues/120
/usr/bin/mosh: Did not find mosh server startup message.
Не очень понял, почему ЭТО не упомянуто в списке проблем? mosh должен быть установлен на удаленном сервере, поэтому просто использовать вместо ssh не получится.
Не очень понял, почему ЭТО не упомянуто в списке проблем? mosh должен быть установлен на удаленном сервере, поэтому просто использовать вместо ssh не получится.
С главной страницы mosh: The Mosh package should be installed on both the client and server. Please find your platform below for installation instructions.
Не обязательно устанавливать mosh на сервер. Сойдет просто скомпилированный бинарник, который нужно один раз залить, а потом указывать через --server при подключении.
НЛО прилетело и опубликовало эту надпись здесь
Как я понимаю, mosh нельзя заставить работать, если доступ к удалённому серверу через ssh-тунель?
Вроде нельзя. Только если доступ к удаленному серверу на 60000-й порт открыт. Возможно есть какие-то способы, надо гуглить.
Есть минимум два дурных костыля для этого:
Оба способа убьют главное преимущество Mosh — быстрое восстановление при плохом соединении.
- Завернуть в этот туннель OpenVPN и получить обычный тоннель, по которому пойдет трафик.
- Завернуть UDP в TCP через FIFO: www.qcnetwork.com/vince/doc/divers/udp_over_ssh_tunnel.html
Оба способа убьют главное преимущество Mosh — быстрое восстановление при плохом соединении.
Советовали mosh чтобы «визуально» побороться с высоким пингом при использовании ssh, результат не обрадовал. Редактировать код опасно таким образом, mc выглядит неадекватным.
А как бы авторизацию по USB-ключу через opensc к нему прикрутить?
Ключа -I как у ssh-клиента у него нет, насколько вижу :(
Ключа -I как у ssh-клиента у него нет, насколько вижу :(
Я расскажу страшную тайну. SSH соединение через VPN (проверял на openvpn) подверженно точно такому же реконнекту. То есть я поработал с ноута через сотовый модем, закрыл ноут, уехал, через час дома по вайфаю, открыл ноут и через минуту, после автоматического реконнекта openvpn, все ssh-соединения живы.
Отлично, у меня давно, чтоб, в частности, не морочиться с антибрутфорсерами, SSH на всех серверах на специально выделенном IPv6 — адресе. И везде на клиентах IPv6 через брокеров или VPN.
Из прелестей остается только оптимизация работы с сетью, которая решается тюнингом настроек SSH и вдумчивой работой в консоли (типа не делать cat /var/log/apache/access.log, а делать less)
Остальные нюансы, вроде «пока что не поддерживает IPv6», мне сложно отнести к минусам.
Отлично, у меня давно, чтоб, в частности, не морочиться с антибрутфорсерами, SSH на всех серверах на специально выделенном IPv6 — адресе. И везде на клиентах IPv6 через брокеров или VPN.
Из прелестей остается только оптимизация работы с сетью, которая решается тюнингом настроек SSH и вдумчивой работой в консоли (типа не делать cat /var/log/apache/access.log, а делать less)
И все бы ничего, только он уже год не обновляется.
А подробнее про безопастность можно? Сами же сказали, что SSH сессия закрывается. Какое шифрование используется в MOSH сессии?
Как решается проблема забивания канала? Путем переписывания половины TCP поверх UDP и не очень умным алгоритмом а ля «много ACK не пришло, значит внесем задержку»?
Как решается проблема забивания канала? Путем переписывания половины TCP поверх UDP и не очень умным алгоритмом а ля «много ACK не пришло, значит внесем задержку»?
А сходить на сайт религия не позволяет?
> про безопастность можно?
This is accomplished using a new protocol called the State Synchronization Protocol, for which Mosh is the first application. SSP runs over UDP, synchronizing the state of any object from one host to another. Datagrams are encrypted and authenticated using AES-128 in OCB mode.
mosh.mit.edu/#techinfo
Ну все же есть на сайте.
> про безопастность можно?
This is accomplished using a new protocol called the State Synchronization Protocol, for which Mosh is the first application. SSP runs over UDP, synchronizing the state of any object from one host to another. Datagrams are encrypted and authenticated using AES-128 in OCB mode.
mosh.mit.edu/#techinfo
Ну все же есть на сайте.
> А сходить на сайт религия не позволяет?
Позволяет, но это же не я запостил в 5 раз про MOSH.
> Ну все же есть на сайте.
Как и вся эта статья, но ее же зарепостили опять.
> Datagrams are encrypted and authenticated using AES-128 in OCB mode.
Практически ничего не говорит. Вернее вообще ничего не говорит.
> Ну все же есть на сайте.
Не на сайте, а в документе: mosh.mit.edu/mosh-paper-draft.pdf
Позволяет, но это же не я запостил в 5 раз про MOSH.
> Ну все же есть на сайте.
Как и вся эта статья, но ее же зарепостили опять.
> Datagrams are encrypted and authenticated using AES-128 in OCB mode.
Практически ничего не говорит. Вернее вообще ничего не говорит.
> Ну все же есть на сайте.
Не на сайте, а в документе: mosh.mit.edu/mosh-paper-draft.pdf
Под винду единственный вариант — cygwin? Или может кто-нибудь уже запилил форк putty с поддержкой mosh?
Есть версия в Chrome chrome.google.com/webstore/detail/mosh/ooiklbnjmhbcgemelgfhaeaocllobloj?hl=en, но мне не удалось настроить в ней Kerberos-аутентификацию. Дайте знатье если найдёте решение — страдаю от отсутствия нормального терминала под Windows.
НЛО прилетело и опубликовало эту надпись здесь
… активно развивают...
Последний комит 11 месяцев назад на гитхабе.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Mosh — SSH с блекджеком и роумингом