Столкнулась со случаем блокировки SSH-протокола.
У меня есть несколько зарубежных VPS, одни используются по прямому назначению - как хостинг, другие - как VPN, среди которых есть новые серверы с VLESS, и один старый сервер с OpenVPN и Shadowsocks.
Вчера случайно произвела попытку подключения по протоколу Shadowsocks (промахнулась кнопкой в клиенте). Подключение по Shadowsocks было заблокировано. Каково же было мое удивление, когда после этого я не смогла зайти на этот сервер по SSH.
Выяснилось следующее:
- Предположительно, блокируется только доступ к серверам, где были замечены и ранее заблокированы детектируемые ТСПУ VPN-протоколы. Ко всем остальным серверам (VLESS и обычный хостинг) доступ имеется. Конкретно в моем случае, заблокировался только доступ к одному серверу, на котором находится OpenVPN и Shadowsocks.
- Доступ блокируется только при попытке авторизации по SSH-ключу. Попытки смены ключа на другой и попытки смены типа ключа (с RSA на ED25519) результатов не дали. При этом авторизация по паролю проходит - соединение устанавливается, и в дальнейшем не разрывается (тестовое подключение провисело всю ночь).
- Снятый дамп трафика показал, что в какой-то момент после определенного пакета начинают блокироваться все пакеты в обе стороны, соединение разрывается по тайм-ауту после нескольких ретрансмишнов. Каких-либо “левых” пакетов в соединение не подсовывают, просто полная блокировка.
- Проблема точно в ТСПУ, а не в сервере, т.к. SSH-подключение через VPN происходит успешно.
Провайдер Билайн Москва, хостинг Scaleway, порт SSH нестандартный.
Вот скриншоты дампов с клиента и сервера. Видно, что пакет №19 отправляется сервером и не доходит до клиента, после этого никакие пакеты уже не проходят в обе стороны
Смените провайдера VPS. IP был замечен.
Так я об этом буквально и пишу - IP был замечен в использовании OpenVPN и Shadowsocks, после чего последовала блокировка SSH.
Просто это что-то новенькое. Раньше SSH подобным образом не блокировался. К тому же это похоже на новую т.н. “сигнатурную” блокировку - блокировка наступает не при любом соединении и не сразу, а только при попытке авторизации по ключу.
Ещё летом через мобильный интернет Мегафон и МТС была заблокирована авторизация по ключу по SSH почти на все IP Scaleway и OVH. Несколько дней назад такое же было замечено уже на проводном интернете в Москве, но тут IP Scaleway не абсолютно все заблокированы.
Т.е. это вряд ли связано с Shadowsocks, т.к. блокируется SSH и на серверах, где нет никаких VPN и подобных сервисов.
Интересно. Может быть и совпадение. Однако у меня без проблем работает SSH на сервера OVH и Hetzner, где нет никакого VPN. Заблокированным оказался только сервер в Scaleway с VPN.
Никакие смены портов не помогут. Скорее всего авторизация по ключу похожа на что-то запрещённое, и поэтому блокируется. Т.е. к IP Scaleway почему-то пристальное внимание, и когда там ещё передаётся что-то похожее на запрещённое, то блокируют.
До того, как на моих тестовых устройствах на билайне начали портить любые TCP соединения, я с начала августа, то есть с момента блокировки YouTube, наблюдал на билайне разрыв TCP по паттернам.
Тестировал простым TCP клиент-сервером на Node.js. Если первые два пакета от клиента были размером больше определенного, соединение разрывалось, но только на портах отличных от 22, 80 и 443. Это до сервера в Hetzner.
Можете попробовать на каком-то из этих трех портов подключиться по ключу. Возможно, у вас такая же ситуация.
Вот клиент и сервер, которыми тестировал.
Если клиент отправлял первые два пакета размером больше 24 и 8, то подключение после них отрезалось.
Если отправлял, например, 10 и 10 байт, то всё ок. Проверял это на разных серверах в Hetzner с разными IP.
client.js (1.1 KB)
server.js (832 Bytes)
Такое поведение приводило к смешной ситуации, когда, например, через мобильный билайн нельзя было играть в Minecraft на серверах, которые расположены в Hetzner, но только на серверах новых версии, потому что в их протоколе первые пакеты стали попадать под этот «фильтр».
ну хз чем там отличается авторизация по ключу от парольной в трафике, но мен кажется у тпсу есь определённые сиганатуры типа эсэсаш 22 порт (его не над трогать(пока что)) а те кто меняет порт на нестандартный ето ссзб if u ask me
@Mortemium no sexism just a cheap provocation)
В линукс коммьюнити смена 22 порта на другой всегда считался security through obscurity и как видишь они были правы. Хакерам из ркн пофиг на каком порту, у них порт сканеры для всех
security through bullshit if you ask me 
кончено ркну пофиг они прост блочат всё нестандартное вот и всё
знайю я все ети советы не работать понт рутом менять порт нани стандартный как по мне самый вредный совет так как он бесполезный и тока лиш добовляет гемора (имхо)
Провела пару тестов.
- Смена IP-адреса VPS на другой из того же датацентра не помогла - все равно блок.
- Внезапно помогла смена порта SSH с нестандартного на стандартный 22. На порту 22 блокировки нет.
- Помимо этого также нет блокировки, если использовать для авторизации вместо rsa-sha2-256/rsa-sha2-512 - устаревший алгоритм ssh-rsa (отключенный по умолчанию в openssh >=8.8 и полностью выпиленный из putty/kitty последних версий)
Отступление по поводу порта 22 и security through obscurity - смена порта нужна скорее затем, чтобы системные логи не замусоривались тоннами сообщений о попытках подбора паролей. Пресекает 99% ботов.
могу посоветовать fail2ban для противостоянию перебору
А прокинуть ssh over https не варик?
Вы имеете ввиду с помощью чего-то типа sslh - чтобы был ssh и https на одном порту? Я думаю, не поможет, т.к. идет анализ по какой-то сигнатуре, и блочат соединение когда видят какие-то определенные пакеты.
АНАЛлиз идет по портам в первую очередь, сама же подтвердила постом выше. Через sslh мультиплексор можно засунуть сразу всё и иметь большой запас по свободным непалевным портам, если вдруг че.
Когда началась Обсуждение: Блокировка Jabber/XMPP в России я с помощью sslh вешала XMPP + HTTPS на 443 порт. Не помогло. HTTPS работал, а XMPP все равно блокировался.
Здесь скорее всего имеет место быть просто вайтлист на 22 порт.
Любопытная ситуация. Выглядит как будто обмен ключами + нестандартный порт определяется тспу как недетектируемый трафик.
Ради интереса, попробуйте ssh туннель сделать и повесить 22 порт на shadowsocks.
Либо наоборот, детектируется как ssh и целенаправленно блокируется. Но непонятен выбор критериев. Почему именно нестандартный порт + авторизация по ключам (с паролями все работает) + с использованием актуальных алгоритмов (уже упомянула, что при использовании устаревшего алгоритма ssh-rsa блокировки нет).
Но это предположение, вопрос пока открытый.
хехе what did i tell you) (пальцем в небо но всё же))
значит там какойто fingerprint у их насроен если смена на другие ciphers помогает
ана счёт замусоривания лолгов у тебе и так стоит авторизация по ключу right? дальше накручиваеш fail2ban есть режим paranoid или как то так для jail’а и есть ещё вот такая тема геоблок яу себя на впсках насроил и теперь (почти) тишина
ето оверкилл какойто надо буит тож глянуть 
Не знаю, работает ли на форуме обмен файлами, но если вдруг кто захочет протестировать, вот скрипты для Node.js
TCP client: client.js - Pastebin.com
TCP server: server.js - Pastebin.com
Сервер: node server.js 0.0.0.0 10000 (или другой порт)
Клиент: с тестируемого провайдера подключиться node client.js 0.0.0.0 10000 30 10
30 и 10 — это размеры первого и второго TCP пакета в байтах, которые отправит клиент после подключения. Мой билайн блокировал, если это больше 24 и 9 соответственно.
Дальше будет просто обмен ping/pong в консоли.
Если блок есть, то пинги либо остановятся, либо даже не начнутся.
У меня билайн блокировал вот такие простейшие TCP соединения до Hetzner со случайными данными внутри, никаких сложных детектов протоколов у меня вообще не было, просто блок в зависимости от размера первых двух пакетов с исключением для портов 22, 80 и 443.
Beeline использует L2TP в своей внутренней сети.
Его же рекомендует их техслужба для доступа к VPS.
Он разве не deprecated еще лет 15 назад?