(Топ-постинг в данном случае намеренный) Что-то я глянул на описание autossh, который упоминался в начале, и...
Это проблемы модели использования. autossh - это не просто костыль, это костыль для увеличения устойчивости функциональности, которая вообще не укладывается в изначальную модель работы ssh. С самим ssh, в смысле, с выполнением команд на удаленном хосте, в т.ч. интерактивно, хитрее. Он, конечно, менее устойчив, чем sh. В модели использования sh все-таки подразумевается, что ситуация, когда выполнение команды прервано по вторичным причинам, ненормальна. У самого sh, кстати, и "по первичным" тоже. В смысле, его модель не замечает неудачного завершения непоследней команды в пайпе, в результате в bash, zsh и пр. встраивают для этого, опять же, костыли. При этом в нем предусмотрено, что такая ситуация _бывает_ - для выполнения работ, которые могут длиться дольше, чем сеанс связи, еще с доисторических времен есть nohup. Если я правильно ошибаюсь, в иксах с этим гораздо хуже, xlib при обрыве соединения с сервером тупо дергает abort(). SIGHUP хоть перехватить можно и вежливо завершиться... И тут я считаю, что правильный подход - это UNIX way. Отдельно выполнение команды на удаленном хосте через зашифрованный канал, отдельно защита от обрыва. Конечно, в качестве минимальной защиты от обрыва для терминального соединения screen или tmux представляется некоторым overkill'ом, но если подумать, то почти нет. С одной стороны, защита от обрыва терминальному мультиплексору дается практически даром - все необходимое для этого все равно реализуешь для мультиплексирования, осталось только SIGHUP перехватить. С другой - для восстановления интерактивного сеанса после обрыва нужна почти вся та же функциональность, что для мультиплексирования, потому что воссоединиться могут совершенно с другого терминала. То есть для удаленного шелла в ssh бессмысленно встраивать механизм реконнектов - либо не встраивать вообще, либо встраивать функциональность хотя бы tmux почти целиком. Я предпочту первый вариант. А вот когда в ssh появились туннели, тут-то и появилась совершенно другая модель. OpenVPN, разумеется, сам занимается реконнектами :) autossh, по сути, непригоден для функциональности remote shell, если на том конце нету screen, и крайне слабо осмыслен, если screen на том конце есть. А вот для туннелей - да. Но тоже, кстати, большой вопрос. Про OpenVPN я практически уверен (хотя честно скажу - документацию не читал...), что при обрыве соединения сервер тоже не кладет туннель, во всяком случае, довольно долго. А как с этим у ssh, я не знаю... Все-таки механизм туннелей ssh - это VPN либо для бедных, либо для "вот сейчас на коленке". Когда требуется быстро, а не надежно. ИГ> Это не проблемы tcp, и не проблемы ssh. Это проблемы пользователя. И ИГ> вопрос как их решить только начинается. >>> Но твои придирки некорректны, просто потому, что для пользователя есть >>> протокол ssh для удаленного терминального доступа, а какая там иерархия >>> стандартов за этим словом кроется, его не волнует. >> >> Мои придирки предметны, их суть не зависит от того, переписываюсь я >> со специалистом по сетям или же с чайником. Мы выяснили, что под >> "проблемами протокола ssh" пользователь имел в виду проблемы tcp >> как протокола нижнего уровня, и на этом вопрос исчерпан. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87fvmvu685....@wizzle.ran.pp.ru
