The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Уязвимость в SSH-клиентах OpenSSH и PuTTY

04.07.2020 23:05

В SSH-клиентах OpenSSH и PuTTY выявлена уязвимость (CVE-2020-14002 в PuTTY и CVE-2020-14145 в OpenSSH), приводящая к утечке сведений в алгоритме согласования соединения. Уязвимость позволяет атакующему, способному перехватить трафик клиента (например, при подключении пользователя через контролируемую атакующим точку беспроводного доступа), определить попытку первоначального подключения клиента к хосту, когда клиентом ещё не прокэширован ключ хоста.

Зная, что клиент пытается подключиться в первый раз и ещё не имеет на своей стороне ключ хоста, атакующий может транслировать соединение через себя (MITM) и выдать клиенту свой хостовый ключ, который SSH-клиент посчитает ключом целевого хоста, если не выполнит сверку отпечатка ключа. Таким образом, атакующий может организовать MITM не вызвав подозрения у пользователя и игнорировать сеансы, в которых на стороне клиента уже имеются прокэшированные ключи хостов, попытка подмены которых приведёт к выводу предупреждения об изменении ключа хоста. Атака строится на беспечности пользователей, не выполняющих ручную проверку fingerprint-отпечатка ключа хоста при первом подключении. Те кто проверяют отпечатки ключей от подобных атак защищены.

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

Проблема проявляется в выпусках с OpenSSH c 5.7 по 8.3 и в PuTTY с 0.68 по 0.73. Проблема устранена в выпуске PuTTY 0.74 через добавление опции для отключения динамического построения списка алгоритмов обработки хостовых ключей в пользу перечисления алгоритмов в постоянном порядке.

Проект OpenSSH не планирует изменять поведение SSH-клиента, так как если не указать алгоритм имеющегося ключа на первом месте, будет применена попытка применения не соответствующего прокэшированному ключу алгоритма с выводом предупреждения о неизвестном ключе. Т.е. возникает выбор - либо утечка информации (OpenSSH и PuTTY), либо вывод предупреждений о смене ключа (Dropbear SSH) в случае, если сохранённый ключ не соответствует первому алгоритму в списке по умолчанию.

Для обеспечения защиты в OpenSSH предлагается использовать альтернативные способы проверки ключа хоста при помощи записей SSHFP в DNSSEC и сертификатов хоста (PKI). Также можно отключить адаптивный выбор алгоритмов хостовых ключей через опцию HostKeyAlgorithms и использовать опцию UpdateHostKeys для получения клиентом дополнительных ключей хоста после аутентификации.

  1. Главная ссылка к новости (https://nvd.nist.gov/vuln/deta...)
  2. OpenNews: Выпуски libssh2 1.8.1 и Putty 0.71 с устранением уязвимостей
  3. OpenNews: Уязвимости в реализациях SCP из OpenSSH, PuTTY и WinSCP
  4. OpenNews: В OpenSSH устранена критическая уязвимость
  5. OpenNews: Обновление SSH-клиента PuTTY 0.67 с устранением уязвимости
  6. OpenNews: Критическая уязвимость в библиотеке Libssh
Лицензия: CC-BY
Наводку на новость прислал Аноним
Тип: Проблемы безопасности
Короткая ссылка: https://opennet.ru/53286-putty
Ключевые слова: putty, ssh
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (75) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 23:15, 04/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я так понимаю, пользователям FreeBSD следует срочно обновиться.
     
     
  • 2.6, arfh (?), 23:23, 04/07/2020 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Эта уязвимость касается всех. При чём здесь FreeBSD? Тем более, некуда обновляться. Исправленной версии нет.
     
  • 2.9, Аноним (9), 23:35, 04/07/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Клиент для винды должен был называться LaPuta...
     
     
  • 3.20, бублички (?), 02:31, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    или el coño, или la chimba, т.к. в PuTTY легко проследить отзыв к pussy
     
     
  • 4.38, Аноним (38), 10:58, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Их и так называют pussy.exe. Возможно я один из первых кто предложил этот термин более 10 лет назад, а возможно и нет.
     
  • 2.18, Аноним (18), 00:37, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Я так понимаю, пользователям FreeBSD следует срочно обновиться.

    ютуб "ubuntu server remote administration"

    первая ссылка:
    https://youtu.be/Pt1vwQiUDn8?t=376

    вторая:
    https://youtu.be/o-W_mDGX1bY?t=446
    > Use a Terminal Emulator to Connect to the Server (PuTTy)

    третья
    https://youtu.be/d1u6TnN3YEw?t=25
    > Tutorial: Install SSH (OpenSSH-Server) in Ubuntu Server and Connect Remotely via Putty to Server

    Какие однако интересные ДЕ у линуксоидов, особенно в первом видео (Гном, не иначе), гы-гы!

     
     
  • 3.35, Аноним (35), 10:15, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А какое ДЕ на твоей free bsd?
     
     
  • 4.39, YetAnotherOnanym (ok), 11:14, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Люмина же!
     
  • 4.48, Аноним (48), 13:07, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > А какое ДЕ на твоей free bsd?

    У меня просто иксы, WM, панелька и набор самых удобных для меня, абсолютно независимых от тулкита или ЯП программ - вместо так любимого линуксоидами (особенно из ютубных видео выше) почти религиозного самоограничения "зато однообразно, красиво и прям как в венде или макоси!".

    Кстати, неплохой уход с темы тулзов для администрирования убунты ))

     
     
  • 5.49, Аноним (38), 13:12, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну я свои убунты и чентоси администрирую с кубунты и манджары(с кедами тоже). Эти же машины админят суровые бздшники с вантузов, ибо вынуждены. Этот комментарий пишется с кубунты.

    > почти религиозного самоограничения "зато однообразно, красиво и прям как в венде или макоси!".

    мне на это плевать. Не тулкит красит программу, а программа - тулкит.

     
     
  • 6.55, Аноним (-), 15:18, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Оно и видно по предыдущим комментаторам, как пингвиноидам на это плевать Инфа... большой текст свёрнут, показать
     
     
  • 7.56, Аноним (38), 15:57, 05/07/2020 Скрыто модератором
  • –1 +/
     
     
  • 8.57, Аноним (-), 16:17, 05/07/2020 Скрыто модератором
  • +/
     
     
  • 9.61, Аноним (38), 18:18, 05/07/2020 Скрыто модератором
  • –2 +/
     
     
  • 10.64, Аноним (-), 19:28, 05/07/2020 Скрыто модератором
  • +3 +/
     
     
  • 11.65, Аноним (38), 20:54, 05/07/2020 Скрыто модератором
  • +/
     
  • 7.86, Аноним (-), 15:13, 07/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А ты, Гена, гений Я правильно понимаю этот вопль души Эта ниправильные линукса... большой текст свёрнут, показать
     
  • 2.69, bOOster (ok), 05:48, 06/07/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Типичный линухсоид, не понимающий какие сервисы работают в его системе.. Позор.
     
     
  • 3.78, Аноним (-), 12:31, 07/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Типичный линухсоид, не понимающий какие сервисы работают в его системе.. Позор.

    Зачем местным линухоидам Putty или OpenSSH, если у них для локалхоста есть Prallels и WSL, а для ремота - вебпанелька?

     

  • 1.2, Аноним (2), 23:17, 04/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > Те кто проверяют отпечатки ключей проблеме не подвержены.

    А вот поди проверь его! Если сервер за том конце шара)
    И никакой псевдографики не показывается.

     
     
  • 2.5, Hult (?), 23:20, 04/07/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А не фиг вообще на него лезть!
     
  • 2.13, Аноним (13), 00:12, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    И причём тут псевдографика? Если вы про рисунок, сопровождающий отпечаток, так он именно дополняет, а не заменяет строковое значение.
     
  • 2.15, An0n (?), 00:26, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Речь же о MITM, то есть на сервер то вы попадёте, только через злоумышленника. Ну а там уже можно и проверить.
     
     
  • 3.16, An0n (?), 00:27, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    https://superuser.com/questions/421997/what-is-a-ssh-key-fingerprint-and-how-i
     
  • 2.36, Аноним (36), 10:29, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А зачем Вам подключаться в первый раз к серверу через хакерский Wi-Fi? Да ещё и не проверив fingerprint через сторонние ресурсы. Уязвимость в стиле: а вот была бы у него подпись VerySign...
     
  • 2.44, YetAnotherOnanym (ok), 12:42, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А пароль для входа на этот сервер вы знаете? Или ключик ваш как-то прописан на сервере? Если так, то возможность узнать отпечаток ключа сервера у вас точно была.
     
  • 2.58, Аноним (58), 17:27, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    man ssh-keysign
     

  • 1.3, Онаним (?), 23:18, 04/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Те кто проверяют отпечатки ключей проблеме не подвержены.

    Ну и басиньки.

     
     
  • 2.4, Онаним (?), 23:20, 04/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это вот к тому, что меня тут где-то кто-то упорно вопрошал - а зачем вам закрытая сеть и несколько уровней доступа, включая VPN. Ведь КЛАУД! ДОКЕР! СМУЗИ!

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

     
     
  • 3.7, Аноним (7), 23:27, 04/07/2020 [^] [^^] [^^^] [ответить]  
  • +20 +/
    Тупо пишу yes при подкдючении
    Какой такой ключ
     
     
  • 4.45, YetAnotherOnanym (ok), 12:43, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Дай я тебя поцелую!
     
     
  • 5.77, InuYasha (??), 11:30, 07/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Соблюдай социальную дистанцию!
     
  • 4.74, Аноним (74), 15:54, 06/07/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Нуб!

    Host *
        StrictHostKeyChecking accept-new
        UserKnownHostsFile /dev/null

     
  • 3.31, Аноним (35), 09:41, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Всё бы ничего, но вот только докер позволяет сделать клауд в закрытых сетях реальностью. И всякие кроваво-ынтырпрайзные финтехи этим давно уже пользуются. Посмотри на HSBC, Mr. Cooper, Deutsche Bank... Ну это те, в которые я деплоил всякую кубернетщину. Насчёт смузи - покупаю иногда.
    Так что, я бы вам порекомендовал немножко разобраться в теме, прежде чем писать такие комментарии.
     
     
  • 4.33, Онаним (?), 10:09, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Приведённый списочек в каком-то плане показателен :)
    С Deutsche Bank наверное больше всего работали, нет?
     
     
  • 5.34, Аноним (35), 10:15, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    В этих местах крутится одно из наших решений, да. Самый показательный - это HSBC.
     

  • 1.8, anonymous (??), 23:29, 04/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Ничего не понял. Уязвимость в том, что без использования CA возможен MITM?
     
     
  • 2.11, DerRoteBaron (ok), 23:54, 04/07/2020 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Уязвимость в том, что можно определить, кого MITM'ить есть смысл, а у кого хост уже известен и MITM наверняка вскроется
     
  • 2.53, Аноним (53), 14:19, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Уязвимость в том, что народ наконец изучил матчасть, и понял, что само по себе SSH как "крест животворящий"(с) от MITM не защищает. А чтобы всё работало нужно на первом этапе сверить отпечаток ключа.

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

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

     

  • 1.10, Аноним (10), 23:39, 04/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Сколько программ, столько и уязвимостей! Возможно ли написать программу без ошибок, если ты не робот? Сомневаюсь...
     
     
  • 2.12, Аноним (1), 23:59, 04/07/2020 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Ух, сос мыслом брат ☝
     
  • 2.14, BlackRot (ok), 00:16, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Очевидное невероятное
     
  • 2.17, Аноним (17), 00:27, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • –6 +/
    Можно и даже было бы нужно, но это в идеальных условиях, неограниченное время и команда собранная из профи с образованиями не меньше докторского из нормальных западных универов с опытом лет 10 прод разработки. А не веб мака с опытом работы 1 неделя жабаскрипта и оптимальным манагером который урезает и так уже короткое время и требует всяких разных фичей которые кроме как для промо мало кому нужны. Ну или делаются каким-то дорком дома на колене под пивом
     
  • 2.19, doctorishe (?), 01:03, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если ваша программа написана без ошибок - позовите системного программиста - он исправит ошибки в компиляторе :)
     
  • 2.40, КО (?), 11:31, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это не ошибка в программе. Это организационная ошибка.
    Выдавать пользователю кучу цифробукв и спрашивать - оно? Путь к успеху.
    В данном случае для строгой проверки клиент не должен был спрашивать оно или не оно, а спрашивать просто отпечаток у пользователя и если не оно говорить - аяяй! Но это же влом и муторно будет пользователям. Посему упрощенный вариант.
     
     
  • 3.68, с (?), 03:20, 06/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А винда не спрашивает при первом подключении по рдп? (спрашивает вообщето)
    Нет тут ошибки, это узкое место, да, но или так, или еще большие и не однозначные костыли.

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

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

    У меня так 200 человек ушло на удаленку, 2 дня писал скрипты, которые создают пользователя, генерируют ключи, генерируют батники, собирают "профиль" и пакуют в exeшник по нажатии кнопочки на специальной страчке, у эникеев просто нет шанса накосячить, как и у юзера.

     
  • 2.46, Аноним (46), 12:47, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ага лучше писать хорошо, чем писать плохо.
     

  • 1.21, Anonymouz (?), 03:50, 05/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Баг очевидный, наверняка многие знали или догадывались, странно что написали только сейчас. Использовать можно только когда в запасе месяц-другой времени, т.е. вряд ли юзабельно в целях наживы например.
    И да, даже админы очень серьезных контор не проверяли и не будут проверять отпечаток.
     
     
  • 2.22, Аноним (22), 04:05, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    У меня кстати всегда холодок пробегает, когда патти спрашивает при первом коннекте... я думаю, но потом не перепроверяю ;(
     
  • 2.25, Anonym123 (?), 04:20, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    я не " админы очень серьезных контор", но да, при внезапном изменении отпечатка - обязательно проверяю. страшно патамучта.
    И если по какой-либо причине меняю ключ на сервере - предупреждаю коллегу.
    Не, не параноик.
     
  • 2.27, Аноним (27), 08:11, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Баг очевидный

    Бага в OpenSSH - НЕТ!

    > Атака строится на беспечности пользователей,

    Проблема из-за "человеческого фактора".

     
     
  • 3.37, Anonymouz (?), 10:40, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Баг приводит к утечке информации. CVE выдали, пример атаки с его использованием есть, о чем тут спорить?
     
     
  • 4.42, Аноним (42), 12:10, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Сейчас событие "CVE выдали" не означает вообще ничего.
     
  • 4.51, Аноним (51), 14:03, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Дайте CVE. Мне очень интересно почитать на неисправленный баг в человеческом мозге (днк) из-за которого у людей все еще сохраняется неисправленная "feature" развивающая беспечность
     
  • 2.59, Аноним (58), 17:32, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > даже админы очень серьезных контор не проверяли и не будут проверять отпечаток.

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

     
     
  • 3.66, Anonymouz (?), 22:55, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Где-то хуже где-то лучше, некоторые стараются добавить все в known_hosts и раскидать по серверам, но все равно один админ с гарантией когда-нибудь полезет не проверив, возможно даже не на сервер а на домашнюю систему, где у него настроен туннель до работы, через который контору и хакнут. Например для Яндекса это сработает.
    Это если не говорить об инсайде, там возможностей для гадости больше.
     
     
  • 4.72, Аноним (58), 14:51, 06/07/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >> подписывают хостовые ключи
    > некоторые стараются добавить все в known_hosts и раскидать по серверам

    Читать и понимать написанное научись.

     
     
  • 5.75, Anonymouz (?), 21:27, 06/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >>> подписывают хостовые ключи
    >> некоторые стараются добавить все в known_hosts и раскидать по серверам
    > Читать и понимать написанное научись

    С этом скорее к Вам. :-P Вы там у себя подписывате, а рядом админы компаний подходят к вопросу по-разному, иногда никак, иногда используют схему с puppet+known_hosts или что-то еще более странное... пентерстеры об этом много могут рассказать (но не станут).

     

  • 1.24, Lex (??), 04:17, 05/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –10 +/
    Итак, в библиотеке, связанной с сертификатами и шифрованием спустя много лет нашли очередную эпическую дырищу:

    -Если проект написан на JS - “ууу, вебмакаки!!111 школу вначале закончи!! А что ещё от JS ожидать ?))»

    -Если проект написан на Си / Плюсах и является чуть ли неотъемлемой частью юниксовых систем, открывая хорошую такую дырень для «желающих» - «ненуачо, бывает. Просто шифроваться получше надо было и защит там всяких побольше приделать. И вообще, не бывает кода без ошибок».

     
  • 1.26, Аноним (26), 04:25, 05/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не пойму, зачем вообще менять порядок алгоритмов при аутентификации, когда ключ закеширован. Если настройки сервера и клиента не менялись, то при повторном соединении, как и при первом, выберется одинаковый алгоритм, и никакого предупреждения о смене ключа не будет. А если менялись, то предупреждение закономерно, и для хоста надо закешировать второй ключ или обновить первый.
     
     
  • 2.41, КО (?), 11:40, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Если настройки сервера и клиента не менялись, то при повторном соединении, как и при первом, выберется одинаковый алгоритм

    Это еще если версии пакетов не менять и пр. А то может оказаться что в версии N+1 добавят еще один алгоритм (причем более предпочтительный) и фигакс - у тебя предупреждение, что ты лезешь на другой сервак вместо своего. При частых ложных предупреждениях, ты их начнешь игнорировать. :(

     
  • 2.60, Аноним (58), 17:34, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    На сервере могли сгенерировать новый ключ для нового алгоритма, например.
     

  • 1.43, Аноним (46), 12:41, 05/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я думал путти уже законодательно запретили.
     
     
  • 2.52, Аноним (51), 14:05, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Запрещали, запрещали да, потом поняли что бессильны и разрешили при первой же возможности. Кажется это про телеграм, но не суть, применимо к любому и везде. Извините если что.
     

  • 1.47, YetAnotherOnanym (ok), 12:48, 05/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > будет применена попытка применения не соответствующего прокэшированному ключу алгоритма с выводом предупреждения о неизвестном ключе

    Я чота не догоняю - почему нельзя воздержаться от вывода предупреждения до тех пор, пока не перебраны безуспешно все алгоритмы?

     
     
  • 2.54, olan (?), 14:41, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Протокол аутентификации не позволяет перебирать алгоритмы. Там схема простая: клиент и сервер предлагают списки поддерживаемых алгоритмов, и после получения этих списков выбирается первый алгоритм из списка клиента, который поддержан сервером. Если аутентификация не прошла, соединение рвётся. Чтобы выбрать другой алгоритм, надо повторно соединиться и прислать алгоритмы в другом порядке.

    И потом, отсутствие ключа в кэше клиента - это не безуспешная попытка с точки зрения протокола. Это как раз говорит о том, что у сервера поменялся ключ.

     
     
  • 3.63, YetAnotherOnanym (ok), 18:54, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > соединение рвётся

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

     
  • 2.70, КО (?), 08:58, 06/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Т.е. пользователя надо спрашивать подряд
    это ли правильная подпись - да/нет?
    это ли правильная подпись - да/нет?
    это ли правильная подпись - да/нет?
    это ли правильная подпись - да/нет?
    ...
    это еще более странное поведение будет.
     
     
  • 3.71, YetAnotherOnanym (ok), 14:09, 06/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > спрашивать подряд

    Чёрным по светло-оливковому написано: "воздержаться от вывода предупреждения до тех пор, пока не перебраны безуспешно все алгоритмы". То есть, после перебора выдать запрос: "алгоритм X - хэш такой-то, алгоритм Y - хэш такой-то, алгоритм Z - хэш такой-то. Закэшированный хэш такой-то. Решай сам."

     
     
  • 4.88, КО (?), 10:45, 08/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Нету никакого перебора есть первое подключение.Речь про выбор сертификата для формирования ключа шифрования по подписи. вы предлагаете установить N шифрованных каналов, чтобы задать вопрос и потом N-1 закрыть?
     

  • 1.50, Аноним (50), 13:28, 05/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ну по факту уязвимость условная. Да, она даёт понять, есть ли у человека захешированный ключ или нет. Те кто не проверяют ключ, они и в первый раз не проверят, и в случае изменения его не проверят нажмут yes/
     
     
  • 2.62, КО (?), 18:31, 05/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Как раз в случае изменения и заметят. Ибо изменение это неожиданно.
    Как-то мне это помогло обнаружить конфликт ip адресов в локалке. Включаю сервак все ок. Потом что-то у него с сетью, а по ssh уже другой ключ.
    А то, что в первый раз должен быть какой-то ключ - это нормальное поведение.
     

  • 1.67, Аноним (67), 23:09, 05/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Кстати, разрабам, юзающим ssh исключительно для пуша открытых репозиториев на GitHub должно быть пофиг: выдача себя за сервер для клиента не позволит атакующему выдать себя за вас для сервера и закинуть бэкдор, но позволит принять пуш, который содержит и так публичные данные. Но вот с пуллом засада - пулл как раз атакующий может подменить, поэтому пуллить желательно по https.
     
     
  • 2.73, Аноним (58), 14:58, 06/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    MITM работает в обе стороны.
     
  • 2.87, anonymous yet another (?), 08:02, 08/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > ... , поэтому пуллить желательно по https.

    Убийственная логика.

    "Градуируя его вдоль спины получаем синекдоху отвечания".

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру