Re: Проблемы протокола ssh (Re: и об облаках)
(Топ-постинг в данном случае намеренный)
Что-то я глянул на описание 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
>> как протокола нижнего уровня, и на этом вопрос исчерпан.
Reply to: