Периодически читая статьи, посвящённые SSH, обратил внимание, что их авторы порой не имеют понятия, как работает этот протокол. В большинстве случаев они ограничиваются рассмотрением темы генерации ключей и описанием опций основных команд. Даже опытные системные администраторы часто несут полную ахинею при обсуждении вопросов работы SSH, выдавая опусы в стиле: передаваемые данные шифруются открытым SSH-ключом клиента, а расшифровываются закрытым, или: для шифрования данных при передаче используется алгоритм RSA.
Попытаюсь внести немного ясности в работу протокола SSH, а заодно рассмотреть роль алгоритма RSA и ключей авторизации пользователя…
Алгоритм протокола SSH можно разделить на три уровня, каждый из которых располагается над предыдущим: транспорт (открытие защищённого канала), аутентификация, подключение. Для целостности картины я также добавлю уровень установки сетевого соединения, хотя официально этот уровень находится ниже SSH.
1. Установка TCP-соединения
Не буду подробно останавливаться на принципе работы стека TCP/IP, так как эта тема достаточно хорошо задокументирована в Рунете. При необходимости вы легко найдёте информацию.
На этом этапе происходит сетевое подключение клиента к серверу на TCP-порт, указанный в опции Port (по умолчанию: 22) в файле конфигурации сервера /etc/ssh/sshd_config.
2. Открытие защищенного канала
2.1 Обмен идентификационными данными
После установки TCP-соединения, клиент и сервер (далее по тексту – стороны) обмениваются версиями SSH-протокола и другими вспомогательными данными, необходимыми для выяснения совместимости протоколов и для выбора алгоритмов работы.
2.2 Выбор алгоритмов: обмена ключами, шифрования, сжатия и т.п.
При работе SSH используется довольно много алгоритмов, одни из них используются для шифрования, вторые для обмена ключами, третьи для сжатия передаваемых данных и т.п. На этом шаге стороны отсылают друг другу списки поддерживаемых алгоритмов, наибольший приоритет имеют алгоритмы в начале каждого списка. Затем сравнивают алгоритмы в полученных списках с алгоритмами, имеющимися в системе, и выбирают первый совпавший в каждом списке.
Список доступных алгоритмов обмена ключами на стороне клиента (используются для получения сессионного ключа) можно посмотреть командой:
ssh -Q kexСписок доступных в системе симметричных алгоритмов (используются для шифрования канала):
ssh -Q cipherСписок типов ключей для авторизации у клиента:
ssh -Q key-cert2.3 Получение сессионного ключа шифрования
Процесс получения сессионного ключа может отличаться в зависимости от версии алгоритма, но в общих чертах сводится к следующему:
- Сервер отсылает клиенту свой ключ (DSA, RSA или т.п. согласно договорённости между сторонами, произведёнными в п.2.2).
- Если клиент производит соединение с данным сервером впервые (о чем говорит отсутствие записи в файле /home/username/.ssh/known_hosts у клиента), то пользователю будет задан вопрос о доверии ключу сервера. Если же соединение с данным сервером уже устанавливалось ранее, то клиент сравнивает присланный ключ с ключом, записанным в /home/username/.ssh/known_hosts. Если ключи не совпадают, то пользователь получит предупреждение о возможной попытке взлома. Впрочем, эту проверку можно пропустить, если вызвать ssh с опцией StrictHostKeyChecking:
Также, если пользователю нужно удалить старый ключ сервера (например, когда есть точная уверенность, что ключ был изменён на сервере), то используется команда:ssh -o StrictHostKeyChecking=no username@servername
ssh-keygen -R servername
- Как только клиент определился с доверием к ключу сервера, с помощью одной из реализаций (версия определяется в п.2.2) алгоритма Диффи-Хеллмана клиент и сервер генерируют сеансовый ключ, который будет использоваться для симметричного шифрования канала.
Сеансовый ключ создается исключительно на период жизни канала и уничтожается при закрытии соединения.
3. Аутентификация клиента
И только теперь, когда клиент и сервер установили канал для зашифрованной передачи данных, они могут произвести аутентификацию по паролю или ключам.
В общих чертах, аутентификация посредством ключей происходит следующим образом:
- Клиент отсылает серверу имя пользователя (username) и свой публичный ключ.
- Сервер проверяет в файле /home/username/.ssh/authorized_keys наличие присланного клиентом открытого ключа. Если открытый ключ найден, то сервер генерирует случайное число и шифрует его открытым ключом клиента, после чего результат отправляется клиенту.
- Клиент расшифровывает сообщение своим приватным ключом и отправляет результат серверу.
- Сервер проверяет полученный результат на совпадение с тем числом, которое он изначально зашифровал открытым ключом клиента, и в случае совпадения считает аутентификацию успешной.
4. Уровень подключения
После проведения всех вышеперечисленных процедур, пользователь получает возможность передавать команды серверу или копировать файлы.
На этом уровне обеспечивается: мультиплицирование каналов (возможность работы множества каналов к одному серверу за счет объединения их в один канал), туннелирование и т.п.
От теории к практике
Ну а теперь, думаю, у читателей назрел вполне закономерный вопрос: а зачем нужно знать все эти тонкости работы SSH-протокола, если для повседневной работы достаточно знаний команд создания ключей (ssh-keygen), открытия терминальной сессии (ssh), передачи файлов (scp)?
В качестве ответа, можно вспомнить тему о смене стандартного порта SSH на какой-то другой, которая постоянно становится причиной холивара на Хабре…
В собственной практике я не припомню ни одного смотрящего во внешнюю сеть сервера, который бы ежедневно не подвергался долбёжке на 22-й порт. В ситуации, если SSH у вас работает на стандартном порту (и ничем дополнительно не защищён), даже если аутентификация исключительно по ключам и никакие подборы паролей не пугают, то по причине постоянно валящихся запросов от недобросовестных клиентов сервер всё равно вынужден совершать массу бесполезной работы: устанавливать TCP-соединение, выбирать алгоритмы, генерировать сессионный ключ, отправлять запросы аутентификации, писать лог-файл.
В ситуации же, когда на 22-м порту ничего нет, или порт защищён с помощью iptables (либо надстройками над ним типа fail2ban), то злоумышленник будет дропнут ещё на этапе установки TCP-соединения.
Наиболее интересно описанное выглядит в виде таблицы*
| Конфигурация | Вероятность взлома | Потери от флуда** |
|---|---|---|
| 22 порт, авторизация по паролю, без защиты |
высокая | высокие |
| 22 порт, авторизация по ключам, без защиты |
средняя*** | высокие |
| 22 порт, авторизация по ключам, защита на основе ограничения неудачных попыток авторизации |
низкая | средние**** |
| Нестандартный порт, авторизация по паролю, без защиты |
высокая | низкие |
| Нестандартный порт, авторизация по ключам, без защиты |
средняя*** | низкие |
| Нестандартный порт, авторизация по ключам, защита на основе ограничения неудачных попыток авторизации |
низкая | низкие |
* — значения параметров (высокий, средний, низкий) носят относительный характер и служат только для сравнения показателей.
** — имеется ввиду расход ресурсов сервера (процессор, диск, сетевой канал и т.п.) на обработку лавины запросов, обычно идущих на 22-й порт.
*** — произвести взлом, если для авторизации используются RSA-ключи, очень сложно, однако неограниченное количество попыток авторизации делает это возможным.
**** — количество попыток авторизации ограничено, но серверу всё равно приходится обрабатывать их от большого количества злоумышленников.
Дополнительные материалы
Комментарии (50)
onix74
09.10.2018 08:36Круто! В начале статьи всех «неучей» — в пух и прах!..
А на деле-то что? Всё то же, только воды побольше. И даже версию ssh, в которой работают приведённые в п.2.2 примеры, не удосужился указать.
$ cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.10 (Santiago) $ lsb_release -d Description: Oracle Linux Server release 6.10 $ ssh -V OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013 $ ssh -Q kex ssh: illegal option -- Q usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec] [-D [bind_address:]port] [-e escape_char] [-F configfile] [-I pkcs11] [-i identity_file] [-L [bind_address:]port:host:hostport] [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port] [-R [bind_address:]port:host:hostport] [-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]] [user@]hostname [command]
И чем автор лучше тех «неучей»?o-pod Автор
09.10.2018 08:57+1$ ssh -V
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
5 лет не обновлять пакет — наверное, это круто в плане безопасности!onix74
09.10.2018 09:00Хороший ответ. Почему я другого не ожидал?
Надо же сразу все сервера да на самую последнюю версию.o-pod Автор
09.10.2018 09:43-1Прошу прощение, если чем-то обидел. Не могу судить объективно о вашем сервере, может он реально у вас спрятан во внутренней сети, и shh-доступа к нему снаружи нет. Тогда действительно можно сильно не переживать за обновления, говнотрафик на 22 порт и дополнительную защиту.
А на версию вашего OpenSSH указал лишь по причине отсутствия возможности проверить описанные команды на старых пакетах, ограничившись последней реализацией из репозитория Ubuntu 18.04 LTS.ghostinushanka
09.10.2018 12:04Пройдите пожалуйста вот на этот сайт, почитайте, пролистайте до changelog.
Далее приносите извинения.
Вы просто [] (я бы сюда вставил словечко пожестче, но хабр) не знаете о том как поддерживаются пакеты в RHEL семействе и выставляете это на всеобщее обозрение.
Мало того что воды 99% и по сути от топика никакой информации, так ещё и комментарий про «5 лет не обновлять...». Что ещё больше удивляет, так это соотношение плюсов к минусам у комментариев на данный момент. Что, никого не удивило что в самой последней версии «шестой шапки» будет валяться пакет который не получал обновлений пять (ПЯТЬ КАРЛ) лет?! У того самого кроваво-энтерпрайзного оракла где платятся огромные деньги за поддержку? И никто гугло-яндексом воспользоваться не захотел?
P.S. Если из тона моего сообщения складывается ощущение, что у меня что называется «пригорело», вы правы. Комментарий onix74 очень в точку.freezl
09.10.2018 12:39А почему Вы решили, что там стоит 5.3p1-123, а не 5.3p1-2? Ну и версия openssl c «Build date» от 2013 года как бы намекает (актуальная то Wed Mar 22 22:47:09 2017)
ghostinushanka
09.10.2018 14:43Так что же, кому и о чём намекает?
[root@localhost ~]# cat /etc/redhat-release
CentOS release 6.10 (Final)
[root@localhost ~]# rpm -q openssh
openssh-5.3p1-123.el6_9.x86_64
[root@localhost ~]# ssh -V
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
Оно правда так сложно скачать 450 мегабайт минимальный образ той же CentOS и самому посмотреть? Сколько это времени займёт? 15 минут максимум?
Тот факт что тенденция «проще написать голословный коммент вместо того чтобы самому проверить, а заодно и чему-то научиться» уже и на Хабре прокатывает мне не нравится категорически.iig
09.10.2018 14:56Так что же, кому и о чём намекает?
Там выше по треду была строкаOpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
Эта строка намекает, что где-то существуют системы с несвежим ПО. А ваша ссылка намекает, что обновление таких систем возможно.ghostinushanka
09.10.2018 15:02Это троллинг? Или глупость? Или туннельное видение?
Вы может заметите всё-же что в моём сообщении присутствуют одновременно и самая свежая версия пакета, и та самая строка с 2013-м годом и поймёте наконец что наверное надо свои знания дополнить о том как оно в RHEL семействе устроено чтобы не бросаться голословными заявлениями?iig
09.10.2018 15:23наверное надо свои знания дополнить о том как оно в RHEL семействе устроено
Пожалуй, да.
А то я смотрю на www.openssl.org/source/old/1.0.1 — там 2013-Feb-11 15:34:45 openssl-1.0.1e.tar.gz
Последняя версия openssl-1.0.1 — 2016-Sep-22 10:35:26 openssl-1.0.1u.tar.gz
openssh динамически линкуется с libcrypto.so
OpenSSL 1.0.1e-fips 11 Feb 2013 — это оттуда.
Теперь я готов слушать, как оно в RHEL и почему на 3 года протушая библиотека для криптографии это норма ;)ghostinushanka
09.10.2018 15:27Троллинг, ясно, ничего, снова дам ссылку на rpmfind на openssl пакет.
Читаем changelog, смотрим даты, думаем. Те кому надо сделают выводы.iig
09.10.2018 15:37Забавно придумано… Наверное, есть в этом смысл, накатывать патчи по одному, но минорную версию софта принципиально не менять.
То есть в RHEL нельзя верить тому, что выводит $program --version?amarao
09.10.2018 15:58Можно. Просто у rhel специальная политика по неполомке совместимости на время жизни дистрибутива.
iig
09.10.2018 17:34OpenSSL 1.0.1e-fips 11 Feb 2013
А на самом деле там OpenSSL, собранный не в 2013 году из исходников, слабо относящихся к 1.0.1e 2013 года. openssl верить нельзя ;)
Crystal_HMR
11.10.2018 11:32+1Оно правда так сложно скачать 450 мегабайт минимальный образ той же CentOS и самому посмотреть? Сколько это времени займёт? 15 минут максимум?
ну допустим. Скачал, посмотрел.
rpm -q openssh openssh-7.4p1-16.el7.x86_64 ssh -V OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017
Разница в том, что это седьмой центос. А у вас шестой. Шестому уже более семи лет, но мейтененс апдейты должны быть до 20го года. К сожалению, у меня нет шестого центоса, что бы посмотреть, приехали ли в репы более новые (ну или хотя бы не настолько старые) версии пакетов, но если нет — то это повод поговорить с меинтейнерами.
Если вам это нужно, конечно же.
Мне кажется, что если все статьи на хабре будут с указаниями "с какой версии это начало работать" — они станут очень большими. Всё, что пишется — должно основываться на текущих stable релизах. Не вина автора, что кто-то не обновился.
o-pod Автор
09.10.2018 13:11Мало того что воды 99% и по сути от топика никакой информации
ghostinushanka, было бы неплохо, если кроме троллинга вы бы немного про недочёты или ошибки В СТАТЬЕ обмолвились.
комментарий про «5 лет не обновлять...»
Как вы считаете, можно ли ставить в упрёк использование мной опций, которых не было в пакете 5-летней давности?ghostinushanka
09.10.2018 14:49За меня и до меня достаточно чётко написал Karroplan, что не так с содержанием «статьи» следуя её заголовку.
в пакете 5-летней давности
Вы вообще почитали что написано по приведённой мной ссылке? Пакету никаких 5 лет нет и не было. Или, что вероятнее, вы путаете версию пакета с версией приложения.
Ваше заявление о том что у onix74 «старый и необновлённый пакет» на 136% голословно и в корне неверно.
onix74
09.10.2018 15:01Как вы считаете, можно ли ставить в упрёк использование мной опций, которых не было в пакете 5-летней давности?
Упрёк был не в незнании опций. Упрёк был в том, что Вы в самом начале статьи обвинили некоторых неназванных админов в некомпетентности, но при этом сами даже не предоставили данные об окружении, в котором работаете. Обычно, такие вводные исключают разночтения.
iig
09.10.2018 11:54Давно протухший openssl… За последние несколько лет было несколько неприятных уязвимостей…
Planet_Dust
09.10.2018 11:565 лет не обновлять пакет — наверное, это круто в плане безопасности!
Не спешите так резко ругать, некоторый коммерческий софт очень сильно может быть привязан к конкретным версиям ядра Linux и версиям пакетов. Сам с этим сталкивался неоднократно, тем более тут Oracle Linux, в каких-то случаях конкретный релиз БД Oracle, необходимый для софта, на другой версии может и не завестись.onix74
09.10.2018 12:02Не-не-не! Так не пойдёт! Нужно обновлять всё и сразу. Вот как только выпустили — сразу надо ставить. Сервера ведь существуют для того, чтобы постоянно обновлять ПО на них.
Karroplan
09.10.2018 09:55+1и где в статье хоть слово об «алгоритме работы ssh»? ни грамма не описан ни мультиплексор каналов, ни просто возможности ssh по работе с несколькими разнородными потоками внутри одного подключения. рассмотрена какая-то мелочь, а заголовок достоен желтейшей прессы.
o-pod Автор
09.10.2018 10:07ни грамма не описан ни мультиплексор каналов, ни просто возможности ssh по работе с несколькими разнородными потоками внутри одного подключения.
Пару грамм есть в п.4
;)
pae174
09.10.2018 10:52> по причине постоянно валящихся запросов от недобросовестных клиентов сервер всё равно
> вынужден совершать массу бесполезной работы
Это не самое страшное :-) Исчерпанее очереди полуоткрытых соединений гораздо неприятнее — она там по дефолту очень маленькая.
pae174
09.10.2018 11:02> Сеансовый ключ создается исключительно на период жизни канала и уничтожается при закрытии соединения.
Первоначальный сеансовый ключ может и не дожить до закрытия соединения — это называется Rekey.
pae174
09.10.2018 11:21+1> стороны отсылают друг другу списки поддерживаемых алгоритмов, наибольший приоритет
> имеют алгоритмы в начале каждого списка
Эти списки у себя рекомендуется почистить так как в них по дефолту входят всякие там NIST и MD5.
Planet_Dust
09.10.2018 11:51А чего принципиально нового несёт эта статья? В мануалах/хэндбуках большинства адекватных дистров алгоритмы работы SSH итак расписаны.
Плюс в таблице не учтена защита фаерволом, а она самая как ни крути эффективная.
catharsis
09.10.2018 13:09+1но в known_hosts хранятся отпечатки (fingerprint) ключей, а не ключи.
Если бы сервер первым делом отправлял ключ, а клиент просто проверял его по known_hosts, это бы никак не защищало от MITM.
PS поменяйте заголовок на «Алгоритм аутентификации в SSH» — большинство претензий в комментариях исчезнет.
o-pod Автор
09.10.2018 13:17catharsis, спасибо, ценное замечание!
При первой же возможности будет исправлено.
scruff
09.10.2018 13:22Нестандартный порт+ пароль — высокая? Тогда исправьте «стандартный порт+пароль»= нет безопасности
boloto
09.10.2018 15:29Я уверен, что вы это знаете, но все таки.
Ключей в authorized_keys для одного имени может быть несколько.
Тогда они проверяются просто по очереди.
Vindicar
09.10.2018 15:52Статья оборвалась на середине — получили мы сеансовый ключ, а дальше-то что? Где сам рабочий процесс? Пункт 4 — это так, заметка на полях.
Тогда уж называть статью «Алгоритм установления SSH соединения и сопутствующие вычислительные затраты», или что-то в этом духе.
Другое дело, что статья, видимо, писалась как оправдание практике вешать SSH на нестандартный порт — для личной VPS сам так делаю, как раз по указанным причинам (флуд от ботов, ограничить доступ по диапазону IP не нахожу целесообразным в моем конкретном случае).o-pod Автор
09.10.2018 16:01статья, видимо, писалась как оправдание практике вешать SSH на нестандартный порт
Vindicar, именно так вначале и планировалось, но потом получилось, что контента про SSH гораздо больше, чем про практические аспекты.
называть статью «Алгоритм установления SSH соединения и сопутствующие вычислительные затраты», или что-то в этом духе.
Про заголовок замечание справедливое, в ближайшем будущем подправлю!
BalinTomsk
09.10.2018 21:26По-хорошему в такой статье должно показать реальный пример со шарковскими скриншотами дампа и диаграммой протокола обмена.
Darkhon
09.10.2018 21:30если для авторизации используются RSA-ключи
Сейчас уже чаще не RSA, а ECDSA или Ed25519
Arris
09.10.2018 23:01Совершенно не рассмотрен вариант:
— стандартный порт
— авторизация по паролю
— защита на основе ограничения неудачных попыток авторизации (fail2ban)
Azimuth
10.10.2018 00:43Если открытый ключ найден, то сервер генерирует случайное число и шифрует его открытым ключом клиента, после чего результат отправляется клиенту.
Клиент расшифровывает сообщение своим приватным ключом и отправляет результат серверу.
Результат отправляется в незашифрованном виде?
При дальнейшей работе сервер продолжает шифровать отправляемые данные открытым ключом клиента? А клиент как шифрует отправляемые данные?
gecube
10.10.2018 01:00На этом уровне обеспечивается: мультиплицирование каналов (возможность работы множества каналов к одному серверу за счет объединения их в один канал), туннелирование и т.п.
Что, простите? Какое такое мультиплицирование? Это про мультики для взрослых? Правильно — мультиплексирование. Т.е. именно уплотнение канала связи.
YourChief
10.10.2018 01:27*** — произвести взлом, если для авторизации используются RSA-ключи, очень сложно, однако неограниченное количество попыток авторизации делает это возможным.
Нет, не делает.
Ограничение количества попыток — такая себе мера. Представьте себе, каким количеством IP-адресов обладает одна физическая машина, имеющая префикс IPv6 /64 или даже /48. Аналогично, ботнеты координировано долбят машины с разных адресов. Все эти ухищрения с портами и лимитами разве что понижают нагрузку, генерируемую настойчивым атакующим. С безопасностью оно напрямую не связано.
В статье очень много пробелов. В частности, для того, чтобы блок данных с параметрами KEX-алгоритма не был целиком подменён посредником, он тоже имеет криптографическую связь с ключами сервера. Не рассказано для чего HMAC-алгоритмы нужны.
Клиент расшифровывает сообщение своим приватным ключом и отправляет результат серверу.
Не результат, как раз, а HMAC от результата.
Если клиент производит соединение с данным сервером впервые (о чем говорит отсутствие записи в файле /home/username/.ssh/known_hosts у клиента), то пользователю будет задан вопрос о доверии ключу сервера.
Ну это тоже не догма. Модель TOFU (trust on first use) — действительно слабое место всех систем, которые ещё ни разу не обменивались ключами. Однако этого можно (и нужно) избегать. Есть целый ряд механизмов:
- Ручное или полуручное наполнение known_hosts со сверкой отпечатка.
- Использование записей SSHFP в DNS. Если ответ DNS подтверждён DNSSEC, то тогда SSH даже не задаёт вопроса о доверии ключу.
- Использование сертификатов (не ключей) для аутентификации подлинности ключей серверов. Для аутентификации клиентов тоже работает, то есть в конечном счёте можно аутентифицироваться по ключу, которого на сервере нет, но на котором стоит подпись единственного УЦ, знакомого серверу.
Про SSH можно писать много и интересно — это очень многозадачный и многогранный инструмент. Даже основы можно подать лучше (пример).
авторизация по паролю
Вероятность взлома
высокая
Аутентификация по паролю тоже бывает разная: есть keyboard-interactive, есть password. При этом ни одну из них нельзя сразу охарактеризовать как небезопасную: достаточно длинный нетривиальный пароль может иметь больше энтропии, чем ключ RSA-2048.
В случае с keyboard-interactive вообще может быть задействована двухфакторная аутентификация, например реализованная вот так с помощью google authenticator (TOTP).
Соответственно, ваша таблица с мнениями по поводу безопасности для разных случаев весьма спорная.
P.S. Для любителей всё файрволить и больших сторонников портнокинга ещё предложу простой скрипт, использующий подписанные UDP-пакеты для открытия портов. Прелесть в том, что DROP для UDP извне неотличим от принятия пакета открытым сокетом, поэтому внешне такой сервер себя никак не выдаёт.iig
10.10.2018 08:34Вот бы ещё договориться, в каких попугаях измерять безопасность… ;) Чтобы как-то объективно сравнить разные способы аутентификации..
o-pod Автор
10.10.2018 13:01YourChief, спасибо за дополнения и хорошую критику.
Ну это тоже не догма. Модель TOFU (trust on first use) — действительно слабое место всех систем, которые ещё ни разу не обменивались ключами. Однако этого можно (и нужно) избегать. Есть целый ряд механизмов:
Ручное или полуручное наполнение known_hosts со сверкой отпечатка.
Имеете ввиду отправлять открытый ключ или его отпечаток через другой канал связи (почта, месенджер и т.п.)?YourChief
10.10.2018 15:10Да, если сервер автоматически устанавливается, то можно в конце установки отправить отпечаток, если вручную — то сравнить и добавить то, что в консоли.
vladislav_starkov
10.10.2018 15:54Dear Автор,
Позвольте внести каплю критики для Вашей статьи.
Вы пишите так, что можно подумать, что SSH это OpenSSH дистрибутив и CLI утилиты к нему.
В то время, как на самом деле, SSH это стандартизированный IETF протокол, описанный в RFC 4251 (и дополнительных), а OpenSSH это просто одна из имплементаций протокола.
Т.е. у вас все смешалось в кучу: протокол, одна из рабочих реализаций протокола (OpenSSH), аргументы командной строки для CLI утилиты из дистрибутива OpenSSH (хотя вы же прекрасно понимаете, что в других версиях ПО от других «вендоров» в CLI утилитах могут быть (и будут) реализованы совсем другие ключи командной строки) и пр.
Пишите ясней и не смешивайте кегли, вафли и драже в одной тарелке.
xgbaggins
По моему опыту 99+% фонового ssh флуда отсеиваются просто отключением всех устаревшых алгоритмов включая RSA в sshd_config, скрипт кидди лень обновлять свой софт. Ну и fail2ban помогает тоже