LINUX.ORG.RU

Чтоб вы знали: autossh - полное дерьмо

 


2

2

Многие пользуются SSH-туннелем из-за его простоты.
Для удобства его использования некий гавнюк кодеромаратель по имени Carson Harding изобрел утилиту autossh, которая якобы поддерживает его в устойчивом состоянии.
Так вот, за год использования этой чудной утилиты могу с уверенностью заявить то, что никто о ней до сих пор не написал правду:
- утилита autossh на самом деле - полное дерьмо. Поскольку совершенно не выполняет обещанную функцию - поддержание ssh-туннеля в работоспособном состоянии.

В реале SSH-канал часто рвется, за день около 5-10 раз, и его приходится постоянно перезапускать, при этом приходится каждый раз менять служебный порт на новый, поскольку после обрыва он не освобождается.
Причем, до того, как оборваться, канал досаждает драцкими зависаниями, т.е. обрыва еще нет, но канал «замораживается», и данные по нему не проходят. Через некоторое время он восстанавливается, а потом все повторяется сначала.
Такие заморозки/разморозки повторяются по несколько раз, а потом канал рвется окончательно, и процедуру приходится выполнять заново, меняя служебный порт.

Тем, кто хочет намекнуть на плохой исходный канал: не извольте беспокоится, канал 100 Mbps с великолепным устойчивым пингом и практически ничем не занят, кроме серфинга.
Подозреваю, что неустойчивость SSH-туннеля прежде вызвана спецификой самого SSH, ну не создавался он для туннеля, но ведь autossh призвана повысить эту устойчивость, но не тут-то было.

Многие писаки только описывают autossh, например, этот: http://debuntu.ru/note/avtopodnyatie-tunneley-s-pomoshchyu-autossh
но похоже, никто им реально постоянно не пользуется.


В-общем, хваленый autossh достал по самое не могу, его только фтопку и никуда больше.
Лучше подскажите простенький скрипт для перезапуска обычного использования SSH-туннеля в случае его обрыва.
Помнится, кто-то здесь вроде обещал такой? :)


В завершение типичная картинка работы этой чудной утилиты: http://savepic.su/5310595.png

★★★

почти поверил, а теперь давай ссылки на парочку твоих багрепортов, чисто почитать ответы, что этот оголтелый негодяй тебе ответил.

redhat ()

Еще дифирамбы от очередного «знатока» autossh :

Использование autossh для поддержания терминального соединения по ssh

Вообще autossh предназначен не столько для поддержания тоннеля сколько для автоматического перезапуска ssh при работе на плохом канале. Дело в том, что если произошла потеря пакета, в то время как вы были подключены удаленно к серверу по ssh, то ваш терминал ssh тупо зависает и висит пока не отработает таймаут, выставленный в настройках ssh.
Autossh умеет проверять жив ли канал, и быстренько перезапускать ssh. Для этого autossh при запуске ssh создает дополнительно ssh-тоннель и передает сама себе через этот тоннель пакеты, как только пакеты перестают проходить – тут же происходит перезапуск ssh.
Если добавить к этому делу еще и screen, то получится, что плохой канал будет минимально влиять на нашу работу.
Как это сделать на практике – напишу позже как появится время..
http://test.valynkin.ru/articles/46/kak-sdelat-tonnel-ssh-probros-porta-i-avt...



Думаю, и у этого афтора время так и не нашлось, поскольку писать, собственно, не о чем.

chukcha ★★★ ()
Ответ на: комментарий от zolden

А я бы поразился вашему успеху. Если бы он, конечно, был ;)

chukcha ★★★ ()
Ответ на: комментарий от annulen

Спасибо большое!
Вот тут нашел понятное описание -
http://www.masiev.com/news/mosh-mobile-shell-kak-sovershennaja-alternativa-ssh
и даже пакет в Epel.

Насколько понял, это только клиент, а сервер все тот же SSH-демон? Тогда остается неясность, потому что непонятно, кто виноват в том, что обычный ssh-туннель рвется - клиент, сервер, или оба вместе.

А вы уже пробовали этот 'Mosh'?

chukcha ★★★ ()
Ответ на: комментарий от chukcha

Насколько понял, это только клиент, а сервер все тот же SSH-демон?

Нет, на сервере тоже mosh. Как бы он иначе по UDP данные отправлял через TCP-шный SSH :)

annulen ★★★★★ ()
Ответ на: комментарий от annulen

Неа, не было проблем со стабильностью соединения

Так у меня сами SSH-соединения тоже стабильны, можно законнектится, заскриниться, и коннект будет хоть с месяц висеть.

А вот SSH-туннель на том же канале редко когда держится больше часа, рассыпается.

chukcha ★★★ ()

Пользуюсь autossh давно, в таком формате: sshfs -o reconnect,compression=yes,transform_symlinks,ServerAliveInterval=45,ServerAliveCountMax=2,ssh_command='autossh -M 1203'

Не понимаю о чем ты говоришь.

entefeed ☆☆☆ ()
Ответ на: комментарий от chukcha

Теперь, когда ты выгововорился и успокоился, может, наконец, расскажешь об исходной задаче и зачем там туннель?

zolden ★★★★★ ()

Тем, кто хочет намекнуть на плохой исходный канал: не извольте беспокоится, канал 100 Mbps с великолепным устойчивым пингом

Откуда такие дятлы берутся, у которых на 100Mbps «ни одного разрыва»?

anonymous ()
Ответ на: комментарий от zolden

Это можно. Использую вместо классического VPN-туннеля, подымая на удаленном сервере sshd, на локальном компьютере организовываю socks с помощью скрипта:

export AUTOSSH_DEBUG=1
export AUTOSSH_GATETIME=0
export AUTOSSH_PORT=20033
autossh -N -C -D 7777  tun@81.110.110.110
less
exit

На браузере прописываю прокси как socks5 с портом 7777 и хожу по Интернету, но как уже говорилось, недолго.

Пользуюсь autossh давно, в таком формате:

sshfs -o reconnect,compression=yes,transform_symlinks,ServerAliveInterval=45,ServerAliveCountMax=2,ssh_command='autossh -M 1203'

Непонятная для меня конструкция. Пояснишь?

chukcha ★★★ ()
Ответ на: комментарий от chukcha

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

zolden ★★★★★ ()
Ответ на: комментарий от zolden

Теперь, когда ты выгововорился и успокоился

А ты, однако, психолог :))

chukcha ★★★ ()

Уверен, что многочисленные open failed: connect failed: ... вызваны не падением канала, а тем, что sshd не может сделать connect() к удаленным адресам по разным причинам. В свете этого, а также того, что ТС путает понятия туннель и socks proxy, советую ему курить мануалы.

anonymous ()
Ответ на: комментарий от chukcha

SSH-туннель на том же канале редко когда держится больше часа, рассыпается.

Есть мнение что всё-таки твой канал фигня. Потому что я туннелями(без autossh) на своём сраном ADSL пользуюсь спокойно и ничего не разваливается. Тупит, да, потому что исходящий 30кб/сек не особо способствует скорости, но не разваливается

Pinkbyte ★★★★★ ()

Ну ты лошара!

anonymous ()
autossh -M 0 -f -N -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" ...

Через месяц неактивности может отвалиться, достаточно на сервере прибить SSH-процесс.

УМВР короче.

Black_Roland ★★★★ ()

картинка работы этой чудной утилиты: http://savepic.su/5310595.png

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

anonymous ()
Ответ на: комментарий от anonymous

А почему этот «дерьмо-канал» месяц держит обычный SSH коннект и не разваливается?

chukcha ★★★ ()
Ответ на: комментарий от chukcha

Т.е. в твоем случае vpn===ssh? для серфинга по инету?

SSH как бы вообще штука не быстрая. SSH Попробуйте найти предел при передаче по sftp. Постоянные разрывы нужно искать strace. Нормуль. в соседней ветки подсказали использовать.

Strace

P.S. Извините, но я считаю немного извращением «vpn===ssh. для серфинга по инету.»

pic0 ()
Ответ на: комментарий от pic0

P.S. Извините, но я считаю немного извращением «vpn===ssh. для серфинга по инету.»

Типа «Лёлик, это же неэстетично? Задо дешево, надежно и практично! :))

Если разваливатся OpenVPN, трафик прет по открытому каналу, и это не всегда заметишь.
При обрыве SSH канал просто прекращает работать, и это сразу видно.
Я уже не говорю о сложности настройки OpenVPN.

SSH как бы вообще штука не быстрая.

Серьезно? А почему же по SFTP данные часами качаются со скоростью 10 Мбит/сек и не чирикают?

С самим SSH все нормально, это проблема с организацией туннеля на нем содержит какую-то непонятную загадку.
Специально для вас снял картинки SSH-туннеля, когда он начинает разваливаться, и в этот же момент - ping канала.
Причем в этот раз он вообще ничем не нагружался.

Как видите, с качеством канала все в порядке:
http://savepic.su/5420389.png

Чего не скажешь о SSH-туннеле, который начинает валиться сам по себе без всяких видимых причин:
http://savepic.su/5376354.png

chukcha ★★★ ()
Последнее исправление: chukcha (всего исправлений: 2)

А, так это ты дебиан-инсталлятор ниасилил?

Ну ладно инсталлятор, но это - сам напиши если не нравится. З.Ы.: не пользовал.

deep-purple ★★★★★ ()
Ответ на: комментарий от chukcha

Если разваливатся OpenVPN, трафик прет по открытому каналу, и это не всегда заметишь. При обрыве SSH канал просто прекращает работать, и это сразу видно. Я уже не говорю о сложности настройки OpenVPN.

Ipsec настрой настоящий. И вообще выложи, что ты хочешь получить.

Серьезно? А почему же по SFTP данные часами качаются со скоростью 10 Мбит/сек и не чирикают?

Перепутал теплое с мягким? Что ты имеешь ввиду? RFC 4253 - это читал? Смотри сколько всего

pic0 ()

Чтоб вы знали: autossh - полное дерьмо

И что бы вы знали также о sshuttle, о котором живописали на хабре в https://habrahabr.ru/post/318694/ - дерьмо еще хуже!!!

Да, при его использовании образуется не SOCKS, как делает SSH-туннель, а полноценный VPN-канал для все портов и приложений.
Но! Мало того, что он сыпится так же зашибецки, как SSH-туннель -

client: warning: closed channel 8 got cmd=STOP_SENDING len=0
client: warning: closed channel 9 got cmd=STOP_SENDING len=0
client: warning: closed channel 10 got cmd=STOP_SENDING len=0
client: warning: closed channel 28 got cmd=DATA len=2048
cclient: warning: closed channel 13 got cmd=EOF len=0
client: warning: closed channel 14 got cmd=EOF len=0
client: warning: closed channel 17 got cmd=STOP_SENDING len=0
client: warning: closed channel 28 got cmd=DATA len=2048
client: warning: closed channel 15 got cmd=EOF len=0
client: warning: closed channel 17 got cmd=EOF len=0
client: warning: closed channel 49 got cmd=STOP_SENDING len=0
client: warning: closed channel 50 got cmd=STOP_SENDING len=0
client: warning: closed channel 50 got cmd=EOF len=0
client: warning: closed channel 2 got cmd=STOP_SENDING len=0

Гораздо хуже другое - VPN-канал образуется не сразу после выдачи команды sudo sshuttle -r chucha@92.92.92.92 0.0.0.0/0, а примерно через 90-120 секунд, а до этого - обычный голяк!

Т.е., не зная этого, можно вляпаться по самое не хочу.
Короче, ненадежное дерьмо.

И что за мода пошла нынче - пописывать статейки, описывая только плюсы, а о минусах замалчивать?
Они иногда бывают важнее плюсов. Да-с!

chukcha ★★★ ()

У тебя хреновый канал. Какой-то из роутеров на пути дропает тебе TCP (например, у него память кончается и он чистит память NAT или что-то типа того). Не строй туннель на tcp.

legolegs ★★★★★ ()
Ответ на: комментарий от chukcha

У меня аналогичный кейс и канал похуже, но ссх рвется в основном только раз в сутки когда провайдер коннект резететает. Автоссх не пользую. Может стоит выснить чего у тебя там подвисает?

ya-betmen ★★★★★ ()

Ну ты это, готов убить-то всех этих говнюков и писак?

Deleted ()
Ответ на: комментарий от legolegs

legolegs:
Ок, предположим, что канал хреновый, но только ты в твоем сообщении забыл сказать, на что влияет эта хреновость - на то, что долго устанавливается VPN-канал, или на частые ошибки в нем?

ya-betmen:
У меня SSH на том же «хреновом» канале тоже держится сутками без проблем.
Но я рассказываю не о SSH, а о ssh-туннеле и sshuttle-туннеле - как говорится, прочуствуйте разницу! :)
И что такое здесь «кейс»?

Anakros:
Вбил в игнор. Флудерасты здесь не нужны.

chukcha ★★★ ()
Последнее исправление: chukcha (всего исправлений: 3)

Чувак, я чувствую твою боль и полностью с тобой солидарен! Да, autossh был выкинут полностью из использования для туннелей у меня году езё в 2006-м. Но стоит таки разобраться почему сам ssh отваливается, почитать man на него и внедрить несколько опций, позволяющих раньше оборвать сломавшийся канал. А проблемы конечно может усугублять поведение tcp на некоторых изощренно-настроенных каналах наших провайдеров. Например элементарный path mtu discovery может рандомно не работать. Следует таки провести анализ ситуации, дабы улучшить её.

А так, я использовал SSH VPN через tun/tap и ping'ом другой стороны (большим пакетом) проверял наличие жизни, и дропал при отсутствии оного. Потом мне надоело и я ушел на OpenVPN/UDP + ipv6.

slapin ★★★★★ ()
Ответ на: комментарий от slapin

slapin:
Спасибо за понимание! К сожалению, я уже тоже убедился в том, что каналы VPN на основе SSH как правило, довольно нестабильны.
В зависимости от канала к ним нужен чересчур индивидуальный подход, что довольно напрягает и делает бессмысленным его использование.

Просто эта хвалебная хабровская статейка меня возмутила, и я решил проинформировать лоровцев, что с этим «шаттлом» так же все хреново, как и с ssh-туннелем.

А так, я использовал SSH VPN через tun/tap и ping'ом другой стороны (большим пакетом) проверял наличие жизни, и дропал при отсутствии оного. Потом мне надоело и я ушел на OpenVPN/UDP + ipv6.

Похоже, примерно тоже самое делает autossh, но реального толку с этого я не обнаружил.

chukcha ★★★ ()
Последнее исправление: chukcha (всего исправлений: 1)

Я когда-то давно щупал сие творчество душевно нестабильных, не могу вспомнить, чем именно не понравилось, но в итоге плюнул и просто запихал в крон строчку

 * * * * * if ((`netstat -lnp | grep 8888 | wc -l` < 1)) ;then ssh -f server1 -L 8888:server2:80 -N;fi 
и забыл о проблемах :-)

sand_circle ()
Ответ на: комментарий от chukcha

от зависона не поможет у меня они висели и нихрена не слали по много часов с autossh, пока не прикрутил прибивалку (ну и ключики ssh немного улучшают ситуацию, но не лечат все случаи).

slapin ★★★★★ ()
Ответ на: комментарий от anonymous

Нет, у тебя плохой маршрут

Маршруты в Интернете, как и начальство, не выбирают :)

chukcha ★★★ ()
Ответ на: комментарий от slapin

Проблемы например бывали когда провайдер делал хитрый дисконнект со своей стороны, ничто не помогало пока не положишь ethernet и не поднимешь снова по DHCP, при этом IP адрес не менялся. А ещё ограничения по количеству соединений на «100Mbit» каналах давали странные эффекты. А некоторые хитро надругивались над ip congestion и pmtu, что без жостких локальных настроек размера окна и pmtu всё работало ужасно. Ты ещё учти что обычный ssh - это интерактивный трафик, а туннель - bulk, то есть можно хорошо нагадить через QoS, например.

slapin ★★★★★ ()
Ответ на: комментарий от chukcha

я уже тоже убедился в том, что каналы VPN на основе SSH как правило, довольно нестабильны

На это потребовалась какая-то жалкая пара лет.

thesis ★★★★★ ()
Ответ на: комментарий от chukcha

А какая проблема-то решается? Может проще поднять что-то типа tinc vpn, и уже поверх него пускать всё нужное?

Deleted ()
Ответ на: комментарий от slapin

Ты ещё учти что обычный ssh - это интерактивный трафик, а туннель - bulk, то есть можно хорошо нагадить через QoS, например.

Кому нагадить - себе, провайдеру, или ssh-серверу? )

chukcha ★★★ ()
Ответ на: комментарий от chukcha

Ну себе только при особых склонностях. А провайдер вполне может. Мож у них очень важная телеконференция с Амстердамом, например. Если канал юзерский, никто ведь не гарантирует что там не будет 0Mbps в какие-то моменты. Гарантии то только юрлицам дают. Вот качаешь ты трафик непрерывно по жтому каналу целый день между 2 точками, ведро у провайдера переполняется и он дропает тебя на самое днище, где ещё рядом торренты копошатся.

slapin ★★★★★ ()
Ответ на: комментарий от slapin

А с полноценным OpenVPN такого не случается разве?

Кстати, использую сейчас эту халяву - http://www.vpngate.net/en/
Просто тихий ужас! Серваки часто меняются и редко живут больше одного дня, скорость всегда ниже плинтуса, в-общем, не свободный VPN, а его сплошная дискредитация :(

chukcha ★★★ ()
Последнее исправление: chukcha (всего исправлений: 1)
Ответ на: комментарий от chukcha

Я OpenVPN использую по прямому назначению - для объединения удялённых точек. Из плюсов - ни разу не надо было его рестартовывать из-за непонятной фигни. Задвинуть, сделать так чтобы тормозило - пожалуйста, положить вместе с каналом - не раз, заставить глючить - ни разу. Так как udp и не имеет состояния, то есть работает с любого места. Повер него и tcp и другие протоколы чувствуют себя прекрасно. Плюс провайдеры редко отслеживают «соединения» по UDP, что удобно. Но если специфические глюки на канале - достаточно восстановить канал и всё само начинает работать. Да, и я не использую сторонние VPN-сервисы, ничего про них не могу сказать.

slapin ★★★★★ ()
Ответ на: комментарий от slapin

slapin: спасибо, всё очень дельно и доходчиво, чувствуется опытный специалист по VPN :)

chukcha ★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.