company_banner

Более безопасное подключение к SSH с помощью DNSSEC


    Все, кто использует SSH знают, что при первом подключении к серверу, появляется сообщение с подтверждением отпечатка ключа. Дальше ключ сохраняется на стороне клиента, и больше это сообщение не показывается до момента пока сохраненный ключ не изменится. Но в чем практический смысл этой процедуры?

    В реальной жизни почти никто не проверяет отпечаток SSH-ключа сервера не особенно задумываясь о возможности MiTM-атаках. С появлением DNS-записи SSHFP отпечаток ключа сервера можно хранить в DNS и проверять его подлинность с помощью DNSSEC. При этом не нужно даже подтверждать ключ при первом подключении. В статье разберем, как настроить запись SSHFP для своего SSH-сервера.

    Сервер для тестов


    Для начала нам потребуется сервер.В панели RuVDS реквизиты для SSH-доступа находятся сразу на карточке сервера. Сохраняем IP-адрес и пароль для подключения.



    Вы также можете настроить файрвол прямо из контрольной панели, чтобы разрешить доступ по SSH только для своего IP.

    Для настройки SSHFP на IP-адрес сервера должен быть направлен домен, именно для этого домена мы будем настраивать DNS-записи.

    Как работают ключи в SSH


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

    При установке нового сервера генерируются случайные SSH-ключи, обычно это происходит сразу при установке пакета OpenSSH или при первой загрузке, если используются готовые образы систем.

    Файлы с ключами находятся здесь:

    $ ls -la /etc/ssh/ssh_host_*_key*
    
    /etc/ssh/ssh_host_dsa_key
    /etc/ssh/ssh_host_dsa_key.pub
    /etc/ssh/ssh_host_ecdsa_key
    /etc/ssh/ssh_host_ecdsa_key.pub
    /etc/ssh/ssh_host_ed25519_key
    /etc/ssh/ssh_host_ed25519_key.pub
    /etc/ssh/ssh_host_rsa_key
    /etc/ssh/ssh_host_rsa_key.pub
    

    В этом списке есть сразу несколько ключей разного типа: dsa, rsa, ecdsa, ed25519. Это сделано для совместимости с разными SSH-клиентами. На этапе подключения клиент и сервер согласовывают, какой алгоритм ключа будет использоваться. Клиент может попросить сервер использовать другой алгоритм, если предложенный не поддерживается. Сервер посылает публичную часть своего ключа клиенту и пользователю предлагается проверить его отпечаток вручную.


    Сервер посылает клиенту отпечаток публичного ключа в момент подключения

    Если это первое подключение, клиенту будет показано сообщение с требованием проверить отпечаток ключа вручную:

    The authenticity of host 'example.com (123.45.67.89)' can't be established.
    ECDSA key fingerprint is SHA256:7Q4nIqjuo/lSXWFkt9RaJYVHrT6LUAc6KWrdQ4/DDeA.
    Are you sure you want to continue connecting (yes/no/[fingerprint])?
    

    На этом этапе мы все обычно нажимаем Yes не задумываясь и отпечаток ключа сохраняется в файл ~/.ssh/known_hosts. Теперь если ключ на сервере изменится, клиенту будет показано сообщение о возможной MiTM-атаке. Предполагается, что в самый первый раз клиент выполнил проверку ключа самостоятельно и убедился, в его подлинности.

    Такой подход довольно рискованный, ведь если атакующий успел перехватить момент первого подключения, то сможет подсунуть свой ключ и перехватить подключение. В случае c HTTPS у нас есть третья сторона, которая подтверждает ключ сервера с помощью сертификата. Если такой же подход как в SSH использовался в вебе, нас бы постоянно мучали сообщения о проверке ключа и MiTM-атаки были повсеместно, ведь никто не станет проверять ключи, а будет просто всегда соглашаться.

    Храним отпечаток ключа в DNS. Что такое записи SSHFP


    Как узнать, что предложенный сервером SSH-ключ действительно настоящий и это не MiTM-атака? Ведь для того чтобы зайти на сервер и проверить ключ нужно сперва ввести пароль. Но тогда атакующий сможет моментально взломать сервер и подменить все данные на нем, да так, что мы и не заметим подвоха. Поэтому нужен способ проверить подлинность ключа еще ДО реального подключения.

    Долгое время, единственным способом проверить SSH-ключ сервера до подключения, было использовать другой канал, например, попросить, администратора сервера сообщить отпечаток ключа сервера. Это неудобно, поэтому проще игнорировать проблему и всегда соглашаться не задумываясь.


    SSHFP позволяет проверить подлинность ключа сервера до подключения через DNS

    SSHFP — тип записей DNS для хранения SSH-ключей. Отпечаток SSH-ключа помещается в DNS-сервер подобно TXT записи и подписывается ключом DNSSEC. То есть при первом подключении к серверу с использованием имени хоста, клиент сможет заранее узнать отпечаток ключа сервера через DNS, и если он совпадает с предложенным сервером, то подключаться без предупреждения.

    Настройка DNSSEC


    Для использования SSHFP потребуется доменное имя с настроенным DNSSEC. Есть множество публичных DNS-сервисов, которые предлагают панель управления DNS сразу с функцией DNSSEC. Самый популярный такой сервис — CloudFlare. Рассмотрим настройку на его примере. Для следующий действий домен должен быть делегирован NS-сервера Cloudflare.

    ▍Шаг 1 — сгенерировать ключ


    Заходим в панель DNS --> Enable DNSSEC

    В этот момент будут сгенерированы ключи для подписания вашей доменной зоны. Вам будут показаны публичные ключи. Их нужно будет добавить на стороне регистратора домена.

    ▍Шаг 2 — добавление публичных ключей у регистратора


    Далее, нужно создать DS-записи, содержащие публичный ключ, у регистратора домена.
    В зависимости от вашего регистратора, интерфейс добавления ключей DNSSEC может выглядеть по-разному. Важно только не перепутать значения, так как они могут называться по-разному и отличаться от названий показанных в CloudFlare.

    На примере ниже показано как соотносятся значения, показанные в панели CloudFlare со значениями в панели управления доменом у регистратора Uniregistry.



    ▍Шаг 3 — проверка добавленных DS-записей


    После добавления DS-записей на стороне регистратора можно проверить корректность настроек. На стороне CloudFlare подписание DNS-записей будет активировано, только когда будет пройдена проверка корректности добавления DS-записей на стороне регистратора.


    Ожидание добавления DS-записей

    Через пару минут или часов, если записи были добавлены корректно, вы увидите такое сообщение. Это значит, что DNS-ответы теперь подписываются с помощью DNSSEC.



    ▍Шаг 4 — проверка работы DNSSEC


    Теперь можно проверить работу DNSSEC на нашем домене с помощью онлайн-сервисов вроде dnssec-analyzer.verisignlabs.com. Все галочки должны быть зелеными.


    Результат проверки DNSSEC

    Добавление записей SSHFP


    Сгенерируем SSHFP-записи на сервере. В нашем примере мы администрируем сервер с адресом myserver.com. Для этого доменного имени мы ранее настроили DNSSEC.

    На сервере выполняем команду:

    # Сгенерировать записи SSHFP из существующих SSH-ключей
    sudo ssh-keygen -r myserver.com
    
    myserver.com IN SSHFP 1 1 057ecce168ace29d5a0099e3b63df2850e4c8e20
    myserver.com IN SSHFP 1 2 52cd6099a304b9b8f57f2cd914e96a1b7477eb2f88c98c602
    myserver.com IN SSHFP 2 1 42d677482e4450ee515d3aac94d96302a99bd4ec
    myserver.com IN SSHFP 2 2 edda5fa445dc0da570c772a6df0d4012037e1a102840d29c4
    ...
    

    Будут сгенерированы отпечатки для всех ключей из папки /etc/ssh/. Вы можете выборочно сгенерировать отпечатки для конкретных ключей, указав путь к файлу.

    Теперь все эти записи нужно добавить в панели DNS, в нашем случае Cloudflare.


    Добавление записи SSHFP в панели Cloudflare

    Так, нужно добавить все ключи, полученные на предыдущем шаге. Теперь можно проверить, что ключи добавлены:

    dig SSHFP myserver.com
    

    В ответе вы должны увидеть все добавленные ключи. На подписание новых записей может потребоваться время, поэтому ключи в ответе могут появиться не сразу. Обычно это не занимает дольше 10-15 минут.

    Подключаемся к серверу


    Чтобы SSH-клиент проверял валидность ключей через DNS, нужно добавить включить это в настройках. Конфиг клиента находится в домашней папке пользователя. Добавляем туда одну строку.

    # Редактируем конфиг
    vi ~/.ssh/config
    
    VerifyHostKeyDNS yes
    

    Теперь можно подключаться к серверу. Для чистоты эксперимента можно удалить строку с отпечатком ключа из ~/.ssh/known_hosts. Для наглядности можно добавить опцию -v

    # Подключаемся к серверу
    ssh -v root@myserver.com
    
    
    # DNS настроен неправильно, записей SSHFP нет
    debug1: kex: host key algorithm: ecdsa-sha2-nistp256
    debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
    .....
    DNS lookup error: data does not exist
    
    # DNS настроен правильно, но системный резолвер
    # не поддерживает валидацию DNSSEC
    debug1: kex: host key algorithm: ecdsa-sha2-nistp256
    debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
    ....
    debug1: found 8 insecure fingerprints in DNS
    debug1: matching host key fingerprint found in DNS
    
    
    # DNS настроен правильно, системный резолвер поддерживает DNSSEC
    debug1: kex: host key algorithm: ecdsa-sha2-nistp256
    debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
    ....
    debug1: found 8 secure fingerprints in DNS
    debug1: matching host key fingerprint found in DNS
    debug1: ssh_rsa_verify: signature correct
    

    Если все настроено правильно, то при первом подключении к серверу не будет запрошена ручная проверка отпечатка ключа. Для этого также нужно, чтобы системный DNS-резолвер поддерживал валидацию DNSSEC.

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

    RUVDS.com
    VDS/VPS-хостинг. Скидка 10% по коду HABR

    Похожие публикации

    Комментарии 43

      –1
      Чтобы обезопасить первое подключение можно использовать fwknop, хотя там есть и своя слабина.
        +1
        Каким образом? fwknop это портнокер по сути, он наоборот ограничивает клиентов пока они не пришлют аутентифицированный пакет.

        Из альтернатив тут только использование сертификатов SSH (подчеркну: не ключей — сертификатов), распространяемых отдельно. Такое решение лучше масштабируется и не требует внедрения DNSSEC. Вот руководство, правда не очень свежее: www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu
          –1
          Да, и как раз именно этим можно обезопасить первое подключение: ссш открывается только тому клиенту, который присылает нужный пакет. Для остальных, в основном, даже не видно, что порт назначен для ссш. После того как я настроил fwknop боты фактически сканируют впустую.
            0
            Смысл статьи в противоположном: защитить не сервер от левых клиентов, а клиентов от подложного сервера. Ситуация такая: клиент делает первое подключение, он ещё не знает, какой у сервера должен быть host key. Первый раз обычно мы просто его принимаем на веру, не зная, к кому подключаемся на самом деле. А вот с DNSSEC можно опубликовать подписанную запись, какой должен быть ключ.
              –2
              Рассмотрим схематичную связку — fwknop && ssh — если не прошел fwknop, то это ложный сервер и ssh не начинается.
                0
                Во-первых, как Вы узнаете, прошёл он или нет? Там отправляется с клиента один UDP-пакет больше ничего. Можно узнать только если порт UDP закрыт.

                Во-вторых, это никак не поможет защитить само TCP-соединение от перехвата. Атакующий может даже и не знать про какой-то там fwknop — он просто зарулит соединение SSH себе и всё. А SPA-пакет fwknop спокойно дойдёт до сервера, и сервер может его даже получит и что-то там откроет.
                  –2
                  У fwknop на сервере есть возможность отсылать на мейл сообщения на открытии и закрытии доступа.
                  +2

                  YourChief прав, порт кнокинг не защтит вас от MiTM-атаки. Представьте, что атакующий сидит на стороне провайдера и использует DPI для обнаружения SSH хендшейка и автоматически подменяет ключ на свой. Ему не важно что вы делали до этого, ведь TCP-подключение с SSH все равно будет обнаружено и перехвачено.

                    –2
                    речь о fwknop, а не о простом кнокинге.
          0
          На сколько понял, SSHFP запись просто предоставляет в открытую fingerprint и не работает если домен не поддерживает DNSSEC?
          А почему не использовать обычную TXT запись?
            +3
            Если не использовать DNSSEC, то запись не подписана и может быть так же подменена по пути.

            Вопрос почему это сделали отдельным типом записи — хороший вопрос, могли по идее так же пихнуть ключ в TXT-запись, защищённую DNSSEC.

            Из альтернатив тут только использование сертификатов SSH (подчеркну: не ключей — сертификатов), распространяемых отдельно. Такое решение лучше масштабируется и не требует внедрения DNSSEC. Вот руководство, правда не очень свежее: www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu
            0
            VerifyHostKeyDNS yes

            Этого недостаточно. У SSH-клиента должен быть резолвер, валидирующий DNSSEC. В общем случае это не так.
              +1

              Да, об этом сказано в конце.

                0
                Это довольно нетривиальная часть — речь не просто о системном резолвере, а буквально о резолвере в локалке, который тоже должен поддерживать и валидировать DNSSEC. Если компьютер переносной, то придётся использовать что-то вроде dnssec-trigger. Либо иметь ssh, собранный с поддержкой ldns и unbound-anchor.

                Довольно громоздко получается в результате, я бы сказал.
              +2
              TIL: для аутентификации публичным ключом валидация ключа хоста по сути не нужна: www.gremwell.com/ssh-mitm-public-key-authentication
                0
                А в чём заключается проблема, которую решают? Лень проверять fingerprint сервера? Потому как для получения пароля или для передачи своего публичного ключа нужно уже иметь доверенный канал связи. Почему по этому каналу стандартно не запрашивать fingerprint? Если нам это лень сделать, то почему нам не лень найти ОС и SSH-клиент, которые поддерживают SSHFP, настроить DNSSEC, изменить конфигурацию по умолчанию SSH-клиента?
                  +1

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

                    +1
                    Это самая распространенная ошибка при развёртывании каналов на основе асимметричного ключа. Если вы пошлёте ваш публичный ключ по недоверенному каналу, например по e-mail с opportunistic шифрованием и где-то между вами и получателем будет полноценный MiTM, то все ваши коммуникации будут проходить через MiTM с возможностью расшифровки. Атакующий перехватывает ваш первый e-mail и подменяет ваш публичный ключ на свой. После этого он перехватывает все адресованные вам сообщения, расшифровывает своим private ключём, шифрует для вашего публичного и отправляет вам. Аналогично в обратную сторону.

                    Публичный ключ называется публичным потому, что его можно распространять на публичных площадках: опубликовать у себя на HTTPS-сайте, разместить на корпоративном (доверенном) сервере, тогда можно проверить, что это ваш ключ, а не MiTM-атакующего. Если ваш публичный ключ станет известен всем, ничего плохого в этом нет, даже наоборот.

                    Применительно к SSH, если вы пошлёте ваш публичный SSH-ключ владельцу SSH-сервера по e-mail, а между вами MiTM, ваш e-mail может быть перехвачен, публичный ключ подменен. После этого атакующий либо заходит на SSH-сервер со своим ключём и делает там то, что хочет, либо перехватывает вашу SSH-сессию, проксирует её и наблюдает за всеми вашими действиями.
                      0
                      и где-то между вами и получателем будет полноценный MiTM, то все ваши коммуникации будут проходить через MiTM с возможностью расшифровки

                      Не очень понимаю как. Ключ передаётся по одному каналу, а сообщения потом идут по другому же.

                        0
                        Не очень понимаю, где вы видите другой канал, разве что в середине, на просторах «большого» Интернета, и то магистральные провайдеры могут быть одни и те же, не говоря уже про СОРМ и прочие системы, которые могут и на многих провайдеров распространяться.

                        Запустите traceroute с вашего рабочего места до SSH-сервера, а затем запустите traceroute с рабочего места (или, скорее, почтового сервера вашего предприятия) до следующего(-их) hop на пути e-mail и от администратора SSH-сервера до последнего или пред-последнего почтового сервера, через который прошла почта. Каждый совпавший hop в traceroute даст вам некое представление о количестве мест где и ваш e-mail трафик и SSH-сессии могут перехватить. На самом деле, таких мест значительно больше, если учитывать L2-оборудование и даже физические L1-каналы. Как минимум, это оборудование провайдеров вашей компании и компании, где размещён SSH-сервер, но, в большинстве случаев, там ещё масса неявных мест, вроде магистральных провайдеров между городами, IX-точек и т.д. Также, достаточно вероятным вектором (развития) атаки будет взломанное оборудование вашей компании или контрагента.

                        Более того, как я написал выше, одним из типов атаки будет подмена вашего публичного ключа в e-mail и заход со своим ключом на SSH-сервер, для этого вообще больше ничего перехватывать не надо, только e-mail.
                    +2
                    Первое, что хочу сказать — автор молодец, что поднимает такие темы. Этот кейс действительно игнорируют множество разработчиков. Что касается самого способа, то он предназначен больше для случаев, когда надо ходить на большое количество хостов через публичную сеть. Для стандартной схемы с бастион-хостом конечно проще проверить отпечаток самостоятельно один раз и разместить known_hosts файл в репозитории с инструментами управления.
                    0
                    sudo ssh-keygen …

                    Зачем sudo, публичные части ключей и так кто угодно читать может ;)

                      –1

                      Эм, всё не так.
                      По поводу веба: естественно никто не станет сверять ключи для посещения очередного развлекательного сайта, так что там придумали систему, которая хоть как-то работает в расчёте на незаинтересованного в безопасности и в среднем малограмотного пользователя.
                      Если у вас SSH относится к той же категории, то ок, хорошая идея, но не надо её выставлять как топовую безопасность. Особенно вот это:


                      узнать отпечаток ключа сервера через DNS, и если он совпадает с предложенным сервером, то подключаться без предупреждения.

                      Для пользователей, которым плевать на безопасность, и которые не хотят на неё вообще что-то тратить ("нажимаем Yes не задумываясь", "ведь никто не станет проверять ключи, а будет просто всегда соглашаться"), это всё действительно несколько её увеличит. А те, кому не плевать, будут сверять ключи с полученными по действительно надёжному каналу, который не подвержден перехвату третьими сторонами (DNSSEC, как и общепринятый SSL для сайтов, таковым очевидно не является).

                        +1
                        надёжному каналу, который не подвержден перехвату третьими сторонами (DNSSEC, как и общепринятый SSL для сайтов, таковым очевидно не является).

                        Не понял:


                        1. Я использую DoH или DoT
                        2. Я выполняю в теминале:
                          a)

                        dig . DNSKEY | grep -Ev '^($|;)' > root.keys

                        b)


                        dig +sigchase +trusted-key=./root.keys babai.ru SSHFP | cat -n

                        и получаю в ответ: "Ok this DNSKEY is a Trusted Key, DNSSEC validation is ok: SUCCESS"


                        c)


                        ssh -v root@babai.ru

                        и получаю в ответ: "found 6 secure fingerprints in DNS"


                        ГДЕ, ЧТО и КАК здесь подвержено перехвату ?

                          0
                          Такой пример. У меня есть мгтс и мтс в планшете. Я могу DoT делать по одному каналу, а ssh по другому. Как пример.
                            0

                            Ну нет, у настоящего параноика стоит в системе stubby и по-любому каналу DNS будет секурно :)

                              0
                              По любому. Без тире.

                              У меня DNS over TLS от Android 9.
                            0

                            Всё и везде.


                            dig. DNSKEY

                            DoH-сервер может подменить этот ключ (да, DoH-сервер это третья сторона, а не абстрактная идеальная сущность). Но допустим этого не произошло, и ключ вы получили настоящий.


                            dig +sigchase +trusted-key=./root.keys babai.ru SSHFP | cat -n

                            Если я правильно понял, эта команда проверяет, что SSHFP-запись домена babai.ru подтверждена ключом, полученным на прошлом этапе. Очевидно, тут имеется третья сторона (владелец того самого ключа рут-зоны — ICANN наверно? а может ещё цепочка CA, не особо в курсе их организационной структуры), которая может своим настоящим ключом злонамеренно или по ошибке подписать подложную SSHFP-запись для mitm-атаки.


                            ssh -v root@babai.ru
                            found 6 secure fingerprints in DNS

                            Даже если прошлая команда не подверглась уже описанным атакам и подтвердила настоящую легитимную SSHFP-запись, полученную с помощью сделанного ей DNS-запроса про домен babai.ru, это не гарантия того, что аналогичный DNS-запрос, сделанный ssh-клиентом (хотя стоит отметить, что в зависимости от настроек dns-кеша и прочих обстоятельств этого второго запроса может и не случиться, но это частный случай), вернёт ту же SSHFP-запись. То есть может выйти так, что dig получит и проверит легитимную запись, а второму запросу (от ssh) отдадут уже подложную.


                            Итог: вы, если хотите, можете доверять используемому вами DoH-серверу и вообще официальной DNS-инфраструктуре, но надо понимать, это это именно осознанное доверие третьей стороне, снижающее безопасность p2p-соединения. Даже если этой третьей стороной является какая-то крупная известная организация, которой вроде бы незачем вас атаковать, данный риск всё равно должен держаться в голове.


                            Все эти шифрования и pki защищают только транспорт, а от злонамеренного агента на той стороне они никак не защитят. Как минимум одна "та сторона" неизбежна — это сам сервер, к которому подключается ssh, а вот от всего остального можно избавиться.

                              0
                              1. Вы всё написали правильно, но если я просто параноик то вы гуру-параноик (в хорошем смысле этого слова) :)
                              2. В "обычной" жизни когда я с одного своего сервера поключаюсь к другому своему же серверу по ssh (разумеется вход по ключу а не паролю) я считаю надписи "found 6 secure fingerprints in DNS" достаточно для моего спокойствия что я попал куда надо. Я всё таки Google/Cloudflare (DoT, DoH) и рутовым держателям ключа Dnssec (ICAAN) таки доверяю.
                              3. Всё равно спасибо учитель за такой сверхпараноидальный взгляд — мне есть ещё куда расти :)
                                0
                                Теперь IANA, а не ICANN. www.iana.org/dnssec
                                ещё цепочка CA

                                Именно, только не CA, а иерархическая зональность, т.е. "." (Root), com., example.com.
                                Далее вот как выглядит корневая зона, зона точка. www.internic.net/domain/root.zone

                                Там есть два ключа, zone signing key и key signing key (ZSK и KSK). В зоне есть DS записи с ID ключами, которому зона доверяет (com., например). Вот так.
                              0
                              По опыту эксплуатации пробовал sshfp и CA для ssh. Увы проблема подтверждения отпечатка сервера для виндовых клиентов с putty не решается этими технологиями. Если кто-то знает как это решить буду очень признателен.
                                0
                                Запретите на сервере аутентификацию по паролю и тогда, когда все будут использовать только аутентификацию по публичному ключу, никаких рисков в виде MITM не будет. Вот подтверждение. Все будут только в выигрыше.
                                  –1

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

                                    –1
                                    В чем я неправ?
                                      –2
                                      Вопрос в MitM во время первого подключения к серверу, а не использование на стороне клиента метода аутентификации через пароль или ключ (или сертификат).

                                      Вы написали про то что мы можем перейти на ключи (что нормальные люди уже сделали, в отличии от вас наверное), но это не отменяет MitM на пути к серверу при первоначальной установке соединения (в современных системах часто используются облачное создание виртуалок буквально двумя кликами).

                                      При первом подключении по ssh к серверу, сервер передаёт отпечаток своего ключа, и потом последующие подключения выполняют сравнение этого отпечатка подтверждает факт легитимности соединения. В том случае если между вами и свежеустановленным сервером будет злоумышленник, то он может вам передать свой отпечаток и вы не будете знать об этой подмене. Независимо от того используете вы пароль или ключ, соединение будет скомпрометировано. Вам стоит освежить знание о механизмах работы этого популярного типа соединения, для архитектора важно знать больше о безопасности.
                                        0
                                        (что нормальные люди уже сделали, в отличии от вас наверное)
                                        Вот этот выпад я откомментирую чуть ниже.

                                        Независимо от того используете вы пароль или ключ, соединение будет скомпрометировано.
                                        А вот это неверно, о чём и была заметка, ссылку на которую я дал. Злоумышленнику не удастся стать посредником и вклиниться в сессию. Ему никак не получить таким образом доступ к серверу, потому что подпись для авторизации охватывает идентификатор сессии, а он в свою очередь выведен из общего секрета, согласованного через DH.

                                        По поводу хамства выше я хочу сказать, что вы не поняли о чём речь, но априори считаете собеседника идиотом. В данной ситуации всё вышло ровно наоборот.
                                          0
                                          Из заметки же ясно, что DH согласование соединения влияет на идентификатор сессии и именно это мешало злоумышленнику иметь неограниченное влияние на соединение. Однако злоумышленник всё ещё может получать данные от клиента и их утечка бОльшая проблема, чем доступ на новый сервер, на котором возможно ничего и нет полезного.
                                        0
                                        В том, что речь не про MITM, а про подмену целевого хоста.
                                          0
                                          Это верно, моя ошибка.
                                    0
                                    В windows 10 есть OpenSSH. Из коробки.
                                      0

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

                                        0
                                        Это компонент windows. По факту как из коробки. Или вам сложно зайти в установка/удаление компонентов windows?
                                          0
                                          Не у всех есть админские права)

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое