Comments 52
По моему опыту 99+% фонового ssh флуда отсеиваются просто отключением всех устаревшых алгоритмов включая RSA в sshd_config, скрипт кидди лень обновлять свой софт. Ну и fail2ban помогает тоже
Круто! В начале статьи всех «неучей» — в пух и прах!..
А на деле-то что? Всё то же, только воды побольше. И даже версию ssh, в которой работают приведённые в п.2.2 примеры, не удосужился указать.
И чем автор лучше тех «неучей»?
А на деле-то что? Всё то же, только воды побольше. И даже версию 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]
И чем автор лучше тех «неучей»?
$ ssh -V
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
5 лет не обновлять пакет — наверное, это круто в плане безопасности!
Хороший ответ. Почему я другого не ожидал?
Надо же сразу все сервера да на самую последнюю версию.
Надо же сразу все сервера да на самую последнюю версию.
Прошу прощение, если чем-то обидел. Не могу судить объективно о вашем сервере, может он реально у вас спрятан во внутренней сети, и shh-доступа к нему снаружи нет. Тогда действительно можно сильно не переживать за обновления, говнотрафик на 22 порт и дополнительную защиту.
А на версию вашего OpenSSH указал лишь по причине отсутствия возможности проверить описанные команды на старых пакетах, ограничившись последней реализацией из репозитория Ubuntu 18.04 LTS.
А на версию вашего OpenSSH указал лишь по причине отсутствия возможности проверить описанные команды на старых пакетах, ограничившись последней реализацией из репозитория Ubuntu 18.04 LTS.
Пройдите пожалуйста вот на этот сайт, почитайте, пролистайте до changelog.
Далее приносите извинения.
Вы просто [] (я бы сюда вставил словечко пожестче, но хабр) не знаете о том как поддерживаются пакеты в RHEL семействе и выставляете это на всеобщее обозрение.
Мало того что воды 99% и по сути от топика никакой информации, так ещё и комментарий про «5 лет не обновлять...». Что ещё больше удивляет, так это соотношение плюсов к минусам у комментариев на данный момент. Что, никого не удивило что в самой последней версии «шестой шапки» будет валяться пакет который не получал обновлений пять (ПЯТЬ КАРЛ) лет?! У того самого кроваво-энтерпрайзного оракла где платятся огромные деньги за поддержку? И никто гугло-яндексом воспользоваться не захотел?
P.S. Если из тона моего сообщения складывается ощущение, что у меня что называется «пригорело», вы правы. Комментарий onix74 очень в точку.
Далее приносите извинения.
Вы просто [] (я бы сюда вставил словечко пожестче, но хабр) не знаете о том как поддерживаются пакеты в RHEL семействе и выставляете это на всеобщее обозрение.
Мало того что воды 99% и по сути от топика никакой информации, так ещё и комментарий про «5 лет не обновлять...». Что ещё больше удивляет, так это соотношение плюсов к минусам у комментариев на данный момент. Что, никого не удивило что в самой последней версии «шестой шапки» будет валяться пакет который не получал обновлений пять (ПЯТЬ КАРЛ) лет?! У того самого кроваво-энтерпрайзного оракла где платятся огромные деньги за поддержку? И никто гугло-яндексом воспользоваться не захотел?
P.S. Если из тона моего сообщения складывается ощущение, что у меня что называется «пригорело», вы правы. Комментарий onix74 очень в точку.
А почему Вы решили, что там стоит 5.3p1-123, а не 5.3p1-2? Ну и версия openssl c «Build date» от 2013 года как бы намекает (актуальная то Wed Mar 22 22:47:09 2017)
Так что же, кому и о чём намекает?
Оно правда так сложно скачать 450 мегабайт минимальный образ той же CentOS и самому посмотреть? Сколько это времени займёт? 15 минут максимум?
Тот факт что тенденция «проще написать голословный коммент вместо того чтобы самому проверить, а заодно и чему-то научиться» уже и на Хабре прокатывает мне не нравится категорически.
[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 минут максимум?
Тот факт что тенденция «проще написать голословный коммент вместо того чтобы самому проверить, а заодно и чему-то научиться» уже и на Хабре прокатывает мне не нравится категорически.
Так что же, кому и о чём намекает?
Там выше по треду была строка
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013Эта строка намекает, что где-то существуют системы с несвежим ПО. А ваша ссылка намекает, что обновление таких систем возможно.
Это троллинг? Или глупость? Или туннельное видение?
Вы может заметите всё-же что в моём сообщении присутствуют одновременно и самая свежая версия пакета, и та самая строка с 2013-м годом и поймёте наконец что наверное надо свои знания дополнить о том как оно в RHEL семействе устроено чтобы не бросаться голословными заявлениями?
Вы может заметите всё-же что в моём сообщении присутствуют одновременно и самая свежая версия пакета, и та самая строка с 2013-м годом и поймёте наконец что наверное надо свои знания дополнить о том как оно в RHEL семействе устроено чтобы не бросаться голословными заявлениями?
наверное надо свои знания дополнить о том как оно в 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 года протушая библиотека для криптографии это норма ;)
Троллинг, ясно, ничего, снова дам ссылку на rpmfind на openssl пакет.
Читаем changelog, смотрим даты, думаем. Те кому надо сделают выводы.
Читаем changelog, смотрим даты, думаем. Те кому надо сделают выводы.
Оно правда так сложно скачать 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 релизах. Не вина автора, что кто-то не обновился.
Очередной ответ который меня просто поразил (в негативном ключе), но давайте вежливо и по пунктам.
onix74 в первом же своём сообщении указал что у него 6.10 версия.
Почему, собственно, «у меня»? Он не у меня, а у г-на onix74. Я взял и скачал ту же версию, чтобы однозначно подтвердить, что пакет не старый, поскольку г-н freezl, сообщением выше, «как бы намекал». Вы, зачем-то, скачиваете седьмой центос. Может посмотрим какие есть ключи во freebsd тогда? Давайте сравнивать груши с грушами, а не с яблоками.
Вы сами написали что скачивали седьмой, но при этом утверждаете что нет шестого, это как? Сложно было скачать шестой а не седьмой!? Меня эти два утверждения идущие в одной «логической цепочке» на ноль поделили. Не понимаю, и возвращаюсь обратно к «сравниваем груши с грушами».
Вам ссылки на rpmfind и того что я написал не достаточно чтобы поверить какие там версии?
Иной раз у меня создаётся впечатление что отвечают так, как вы в данном случае, специально, чтобы перевести внимание от сути, на что-то другое (как ваше заявление про «обратитесь к мейнтейнеру»). А суть вот в чём:
o-pod, основываясь на строке из сообщения onix74
> OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
заявил нечто вроде «вы ССЗБ раз не обновляете пакет с 2013-го»
Мало того, что г-н o-pod не обратил внимание, что 2013й год числится у реализации OpenSSL, потому что там, в оной строке есть запятая, так ещё и не удосужился посмотреть какого-же года пакет в RHEL-based дистрибутиве.
А пакет, как оказалось, вполне себе новый, обновлённый и со всеми «бэкпортированными секурити патчами». Тобишь г-н onix74 никак, от слова совсем, не ССЗБ в плане безопасности.
Как я уже писал (и не только я, исходя из других сообщений), судя по всему г-н o-pod в кучу мешает версии приложений, версии библиотек и версии пакетов. Тем не менее, у критического сообщения про «ССЗБ» много плюсов, а у саркастического ответа «давайте всё всегда обновлять на самое новое» много минусов. И это с учётом того что я написал про версионность и патчи. Такая вот «вселенская несправедливость».
Ну и напоследок
Напоминаю что именно RedHat — крупнейший в мире поставщик «энтерпрайзных линуксов». Тех самых, которые получают патчи больше 10-ти лет и гарантируют совместимость на протяжении всего этого периода. Может тогда сами с мейнтейнерами поговорите и объясните что эта модель (бизнеса в том числе) неправильная?
P.S. Я к «Шапкам» никакого отношения не имею и никогда в самой компании не работал. Работаю (именно работаю) с RHEL-based, Debian-based и SLES-based дистрами.
ну допустим. Скачал, посмотрел.
onix74 в первом же своём сообщении указал что у него 6.10 версия.
А у вас шестой. Шестому уже более семи лет, но мейтененс апдейты должны быть до 20го года.
Почему, собственно, «у меня»? Он не у меня, а у г-на onix74. Я взял и скачал ту же версию, чтобы однозначно подтвердить, что пакет не старый, поскольку г-н freezl, сообщением выше, «как бы намекал». Вы, зачем-то, скачиваете седьмой центос. Может посмотрим какие есть ключи во freebsd тогда? Давайте сравнивать груши с грушами, а не с яблоками.
К сожалению, у меня нет шестого центоса, что бы посмотреть
Вы сами написали что скачивали седьмой, но при этом утверждаете что нет шестого, это как? Сложно было скачать шестой а не седьмой!? Меня эти два утверждения идущие в одной «логической цепочке» на ноль поделили. Не понимаю, и возвращаюсь обратно к «сравниваем груши с грушами».
что бы посмотреть, приехали ли в репы более новые (ну или хотя бы не настолько старые) версии пакетов
Вам ссылки на rpmfind и того что я написал не достаточно чтобы поверить какие там версии?
Иной раз у меня создаётся впечатление что отвечают так, как вы в данном случае, специально, чтобы перевести внимание от сути, на что-то другое (как ваше заявление про «обратитесь к мейнтейнеру»). А суть вот в чём:
o-pod, основываясь на строке из сообщения onix74
> OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
заявил нечто вроде «вы ССЗБ раз не обновляете пакет с 2013-го»
Мало того, что г-н o-pod не обратил внимание, что 2013й год числится у реализации OpenSSL, потому что там, в оной строке есть запятая, так ещё и не удосужился посмотреть какого-же года пакет в RHEL-based дистрибутиве.
А пакет, как оказалось, вполне себе новый, обновлённый и со всеми «бэкпортированными секурити патчами». Тобишь г-н onix74 никак, от слова совсем, не ССЗБ в плане безопасности.
Как я уже писал (и не только я, исходя из других сообщений), судя по всему г-н o-pod в кучу мешает версии приложений, версии библиотек и версии пакетов. Тем не менее, у критического сообщения про «ССЗБ» много плюсов, а у саркастического ответа «давайте всё всегда обновлять на самое новое» много минусов. И это с учётом того что я написал про версионность и патчи. Такая вот «вселенская несправедливость».
Ну и напоследок
то это повод поговорить с меинтейнерами
Напоминаю что именно RedHat — крупнейший в мире поставщик «энтерпрайзных линуксов». Тех самых, которые получают патчи больше 10-ти лет и гарантируют совместимость на протяжении всего этого периода. Может тогда сами с мейнтейнерами поговорите и объясните что эта модель (бизнеса в том числе) неправильная?
P.S. Я к «Шапкам» никакого отношения не имею и никогда в самой компании не работал. Работаю (именно работаю) с RHEL-based, Debian-based и SLES-based дистрами.
OpenSSL 1.0.1e-fips 11 Feb 2013
А как вы прокомментируете наличие уязвимостей в вышеобозначенной версии OpenSSL, которые были закрыты заплатками в версии 1.0.1k в начале 2015 года?
Если я правильно понял, то в редхат версия openssl совсем не 1.0.1е от 11 февраля от 2013, а версия с кучей бекпортов из более свежих версий, но при этом баннер (строчку с версией бинаря) не обновили.
Я даже ссылку на этот пакет чуть выше приводил с указанием чейнджлог почитать. Дата — версия приложения на котором основывается пакет, в который бэкпортируют обновления безопасности (не дополнительный функционал).
Г-н o-pod, это попросту означает что вы либо не читали что вам пишут, либо не вникали в суть написанного. Я даже не знаю что из этого хуже, с учётом того что вы ещё и статьи пишете, которые кого-то должны чему-то научить.
Г-н o-pod, это попросту означает что вы либо не читали что вам пишут, либо не вникали в суть написанного. Я даже не знаю что из этого хуже, с учётом того что вы ещё и статьи пишете, которые кого-то должны чему-то научить.
Мало того что воды 99% и по сути от топика никакой информации
ghostinushanka, было бы неплохо, если кроме троллинга вы бы немного про недочёты или ошибки В СТАТЬЕ обмолвились.
комментарий про «5 лет не обновлять...»
Как вы считаете, можно ли ставить в упрёк использование мной опций, которых не было в пакете 5-летней давности?
За меня и до меня достаточно чётко написал Karroplan, что не так с содержанием «статьи» следуя её заголовку.
Вы вообще почитали что написано по приведённой мной ссылке? Пакету никаких 5 лет нет и не было. Или, что вероятнее, вы путаете версию пакета с версией приложения.
Ваше заявление о том что у onix74 «старый и необновлённый пакет» на 136% голословно и в корне неверно.
в пакете 5-летней давности
Вы вообще почитали что написано по приведённой мной ссылке? Пакету никаких 5 лет нет и не было. Или, что вероятнее, вы путаете версию пакета с версией приложения.
Ваше заявление о том что у onix74 «старый и необновлённый пакет» на 136% голословно и в корне неверно.
Как вы считаете, можно ли ставить в упрёк использование мной опций, которых не было в пакете 5-летней давности?
Упрёк был не в незнании опций. Упрёк был в том, что Вы в самом начале статьи обвинили некоторых неназванных админов в некомпетентности, но при этом сами даже не предоставили данные об окружении, в котором работаете. Обычно, такие вводные исключают разночтения.
1:1
Давно протухший openssl… За последние несколько лет было несколько неприятных уязвимостей…
5 лет не обновлять пакет — наверное, это круто в плане безопасности!
Не спешите так резко ругать, некоторый коммерческий софт очень сильно может быть привязан к конкретным версиям ядра Linux и версиям пакетов. Сам с этим сталкивался неоднократно, тем более тут Oracle Linux, в каких-то случаях конкретный релиз БД Oracle, необходимый для софта, на другой версии может и не завестись.
и где в статье хоть слово об «алгоритме работы ssh»? ни грамма не описан ни мультиплексор каналов, ни просто возможности ssh по работе с несколькими разнородными потоками внутри одного подключения. рассмотрена какая-то мелочь, а заголовок достоен желтейшей прессы.
> по причине постоянно валящихся запросов от недобросовестных клиентов сервер всё равно
> вынужден совершать массу бесполезной работы
Это не самое страшное :-) Исчерпанее очереди полуоткрытых соединений гораздо неприятнее — она там по дефолту очень маленькая.
> вынужден совершать массу бесполезной работы
Это не самое страшное :-) Исчерпанее очереди полуоткрытых соединений гораздо неприятнее — она там по дефолту очень маленькая.
> Сеансовый ключ создается исключительно на период жизни канала и уничтожается при закрытии соединения.
Первоначальный сеансовый ключ может и не дожить до закрытия соединения — это называется Rekey.
Первоначальный сеансовый ключ может и не дожить до закрытия соединения — это называется Rekey.
> стороны отсылают друг другу списки поддерживаемых алгоритмов, наибольший приоритет
> имеют алгоритмы в начале каждого списка
Эти списки у себя рекомендуется почистить так как в них по дефолту входят всякие там NIST и MD5.
> имеют алгоритмы в начале каждого списка
Эти списки у себя рекомендуется почистить так как в них по дефолту входят всякие там NIST и MD5.
А чего принципиально нового несёт эта статья? В мануалах/хэндбуках большинства адекватных дистров алгоритмы работы SSH итак расписаны.
Плюс в таблице не учтена защита фаерволом, а она самая как ни крути эффективная.
Плюс в таблице не учтена защита фаерволом, а она самая как ни крути эффективная.
но в known_hosts хранятся отпечатки (fingerprint) ключей, а не ключи.
Если бы сервер первым делом отправлял ключ, а клиент просто проверял его по known_hosts, это бы никак не защищало от MITM.
PS поменяйте заголовок на «Алгоритм аутентификации в SSH» — большинство претензий в комментариях исчезнет.
Если бы сервер первым делом отправлял ключ, а клиент просто проверял его по known_hosts, это бы никак не защищало от MITM.
PS поменяйте заголовок на «Алгоритм аутентификации в SSH» — большинство претензий в комментариях исчезнет.
catharsis, спасибо, ценное замечание!
При первой же возможности будет исправлено.
При первой же возможности будет исправлено.
Нестандартный порт+ пароль — высокая? Тогда исправьте «стандартный порт+пароль»= нет безопасности
Я уверен, что вы это знаете, но все таки.
Ключей в authorized_keys для одного имени может быть несколько.
Тогда они проверяются просто по очереди.
Ключей в authorized_keys для одного имени может быть несколько.
Тогда они проверяются просто по очереди.
Статья оборвалась на середине — получили мы сеансовый ключ, а дальше-то что? Где сам рабочий процесс? Пункт 4 — это так, заметка на полях.
Тогда уж называть статью «Алгоритм установления SSH соединения и сопутствующие вычислительные затраты», или что-то в этом духе.
Другое дело, что статья, видимо, писалась как оправдание практике вешать SSH на нестандартный порт — для личной VPS сам так делаю, как раз по указанным причинам (флуд от ботов, ограничить доступ по диапазону IP не нахожу целесообразным в моем конкретном случае).
Тогда уж называть статью «Алгоритм установления SSH соединения и сопутствующие вычислительные затраты», или что-то в этом духе.
Другое дело, что статья, видимо, писалась как оправдание практике вешать SSH на нестандартный порт — для личной VPS сам так делаю, как раз по указанным причинам (флуд от ботов, ограничить доступ по диапазону IP не нахожу целесообразным в моем конкретном случае).
статья, видимо, писалась как оправдание практике вешать SSH на нестандартный порт
Vindicar, именно так вначале и планировалось, но потом получилось, что контента про SSH гораздо больше, чем про практические аспекты.
называть статью «Алгоритм установления SSH соединения и сопутствующие вычислительные затраты», или что-то в этом духе.
Про заголовок замечание справедливое, в ближайшем будущем подправлю!
По-хорошему в такой статье должно показать реальный пример со шарковскими скриншотами дампа и диаграммой протокола обмена.
если для авторизации используются RSA-ключиСейчас уже чаще не RSA, а ECDSA или Ed25519
6,2 минут в пустоту, но спасибо, что постарался…
Совершенно не рассмотрен вариант:
— стандартный порт
— авторизация по паролю
— защита на основе ограничения неудачных попыток авторизации (fail2ban)
— стандартный порт
— авторизация по паролю
— защита на основе ограничения неудачных попыток авторизации (fail2ban)
Если открытый ключ найден, то сервер генерирует случайное число и шифрует его открытым ключом клиента, после чего результат отправляется клиенту.
Клиент расшифровывает сообщение своим приватным ключом и отправляет результат серверу.
Результат отправляется в незашифрованном виде?
При дальнейшей работе сервер продолжает шифровать отправляемые данные открытым ключом клиента? А клиент как шифрует отправляемые данные?
На этом уровне обеспечивается: мультиплицирование каналов (возможность работы множества каналов к одному серверу за счет объединения их в один канал), туннелирование и т.п.
Что, простите? Какое такое мультиплицирование? Это про мультики для взрослых? Правильно — мультиплексирование. Т.е. именно уплотнение канала связи.
*** — произвести взлом, если для авторизации используются 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 извне неотличим от принятия пакета открытым сокетом, поэтому внешне такой сервер себя никак не выдаёт.
Вот бы ещё договориться, в каких попугаях измерять безопасность… ;) Чтобы как-то объективно сравнить разные способы аутентификации..
YourChief, спасибо за дополнения и хорошую критику.
Имеете ввиду отправлять открытый ключ или его отпечаток через другой канал связи (почта, месенджер и т.п.)?
Ну это тоже не догма. Модель TOFU (trust on first use) — действительно слабое место всех систем, которые ещё ни разу не обменивались ключами. Однако этого можно (и нужно) избегать. Есть целый ряд механизмов:
Ручное или полуручное наполнение known_hosts со сверкой отпечатка.
Имеете ввиду отправлять открытый ключ или его отпечаток через другой канал связи (почта, месенджер и т.п.)?
Неплохо было бы добавить про kerberos/gssapi как альтернативу ключам.
Dear Автор,
Позвольте внести каплю критики для Вашей статьи.
Вы пишите так, что можно подумать, что SSH это OpenSSH дистрибутив и CLI утилиты к нему.
В то время, как на самом деле, SSH это стандартизированный IETF протокол, описанный в RFC 4251 (и дополнительных), а OpenSSH это просто одна из имплементаций протокола.
Т.е. у вас все смешалось в кучу: протокол, одна из рабочих реализаций протокола (OpenSSH), аргументы командной строки для CLI утилиты из дистрибутива OpenSSH (хотя вы же прекрасно понимаете, что в других версиях ПО от других «вендоров» в CLI утилитах могут быть (и будут) реализованы совсем другие ключи командной строки) и пр.
Пишите ясней и не смешивайте кегли, вафли и драже в одной тарелке.
Позвольте внести каплю критики для Вашей статьи.
Вы пишите так, что можно подумать, что SSH это OpenSSH дистрибутив и CLI утилиты к нему.
В то время, как на самом деле, SSH это стандартизированный IETF протокол, описанный в RFC 4251 (и дополнительных), а OpenSSH это просто одна из имплементаций протокола.
Т.е. у вас все смешалось в кучу: протокол, одна из рабочих реализаций протокола (OpenSSH), аргументы командной строки для CLI утилиты из дистрибутива OpenSSH (хотя вы же прекрасно понимаете, что в других версиях ПО от других «вендоров» в CLI утилитах могут быть (и будут) реализованы совсем другие ключи командной строки) и пр.
Пишите ясней и не смешивайте кегли, вафли и драже в одной тарелке.
Sign up to leave a comment.
Алгоритм установления соединения в протоколе SSH