LINUX.ORG.RU
Форум — General  

SSH на слабом соединении

 , ,


2

3

Часто приходится админить штуковинцы, сидящие где-то на унылом GPRS, с огромным пингом и потерями под 50%. Оно в целом работает, но имеет сильно выраженная печаль, а именно: при хоть сколько-то активном использовании интернетов (когда в консоль выводится больше пары строк) сессия зависает и с 70% вероятностью больше не восстанавливается. Соответственно, мне становится грустненько.
Поведение одинаковое на разных штуковинцах, немного разнится лишь количество строк, после вывода которого всё портится.
SSH работает через OpenVPN по юди-пай. Подробности никому не интересны, причины, как и всегда, лишь в нас самих.
Что делать и что делать, и что вообще в таких случаях нормальные люди делают?

удваиваю предыдущих ораторов, mosh

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

Have you installed mosh on your server?

Чуда не произошло, там не то что пакет установить, пинговать часто нельзя:(

izzholtik ★★★
() автор топика

SSH работает через OpenVPN

ну попа, что ещё сказать. Так-то ещё можно поираться с параметрами OpenVPN (сжатие влючить, если нет).

Каштан

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

Можно попробовать заскриптовать ssh, чтобы за долю секунды попытался отправить все нужные команды и уйти в фон, что-то вроде 

su
пароль
apt -y install mosh &

и повторить попытку в n раз если не успеет скачать пакет (но он маленький).

token_polyak ★★★★
()

По тэцэпэ на слабом каналн не надёжнее будет?

Tanger ★★★★★
()

SSH работает через OpenVPN по юди-пай

На плохих каналах openvpn лучше работает по tcp.
Ну и ещё какой в настройках задан tun-mtu?

imul ★★★★★
()

Знакомая проблема, 10 лет назад тоже мучился. В начале патчил ядро, TCP_RTO_MAX (вроде так этот дефайн назывался) ставил на маленькое число типа 10 секунд - зависанил было сильно меньше. Может быть в современных ядрах оно уже в sysctl. Потом написал свой софт для исправления ситуации.

Но если TCP_RTO_MAX достаточно пропатчить на одной стороне, чтобы хоть как-то всё заработало, то для кастомного софта его серверная половина должна быть там, куда подключаешься - не уверен что тебе такое подойдёт.

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

ну, да. Я тут страдаю, редактируя конфиги sed'ом, какие скачивания)

izzholtik ★★★
() автор топика

Логиниться на сервер, запускать сессию screen или tmux, работать в ней. После разрыва аттачиться к сессии заново и продолжать с того места, где закончил.

anonymous
()

Дробите работу на легкоповторяемые кусочки, минимизируйте пребывание в онлайне. Обходитесь без чрезмерной секретности, дайте облегченные права на доступ к конфигам. Типа скачать конфиг, отредактировать у себя, загрузить. Минимизируйте накладные расходы протоколов, пользуйте FTP для загрузки конфигов в буфер, потом копируйте его в систему. Про TCP вам уже написали.

vaddd ★☆
()

не использовать сотовую связь

burato ★★★★★
() 
# ~/.ssh/config

Host *
##ForwardX11 yes
#ForwardX11Trusted yes
#ForwardX11Timeout 7d
# ConnectTimeout = 3m
Compression = yes
ServerAliveInterval 120

# @see https://www.tecmint.com/speed-up-ssh-connections-in-linux/
AddressFamily = inet


autossh -M 0 -o "ServerAliveInterval=30" -o "ServerAliveCountMax=3" -p SSH-PORT username@example.com

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

Похоже на проблему с MTU. Уменьшите TCP MSS на сервере (где модем). Проще всего это сделать через iproute2.

$ sudo ip route change default via … dev … advmss 1200

ValdikSS ★★★★★
()

Что делать и что делать, и что вообще в таких случаях нормальные люди делают?

увольняются

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