Аутентификация в SSH v.2
Ээ чё?[link1] В SSH v2 аутентификация с ключами разве не взаимная? Если сервер не знает открытого ключа клиента, то клиент разве не должен разорвать соединение?
Ссылки
[link1] http://habrahabr.ru/post/176693/#comment_6141093
[link2] http://www.gremwell.com/ssh-mitm-public-key-authentication
[link3] https://www.pgpru.com/forum/offtopik/japonskijjuniversitetzapustilprogrammuobhodavelikogorusskogofaervola
[link4] http://crypto.stackexchange.com/a/3716/5102
[link5] https://www.pgpru.com/comment46311
[link6] https://www.pgpru.com/comment63265
[link7] https://www.pgpru.com/comment25872
[link8] https://www.pgpru.com/proekt
[link9] https://www.pgpru.com/comment62136
[link10] https://www.pgpru.com/comment63280
[link11] https://www.pgpru.com/comment63253
[link12] https://www.ietf.org/rfc/rfc4432.txt
[link13] https://www.pgpru.com/comment63252
[link14] https://www.pgpru.com/comment63277
[link15] https://www.pgpru.com/comment63281
[link16] https://www.pgpru.com/comment63283
[link17] https://www.pgpru.com/comment63288
[link18] https://www.pgpru.com/comment63316
[link19] https://www.pgpru.com/comment63396
[link20] https://www.pgpru.com/comment63406
[link21] https://www.pgpru.com/novosti/2008/predskazuemyjjgschinebezopasnyekljuchivdebianubuntu
[link22] https://www.pgpru.com/comment50979
[link23] http://undeadly.org/cgi?action=article&sid=20061204161240
[link24] https://www.pgpru.com/forum/prakticheskajabezopasnostj/pkidljassh
[link25] https://www.pgpru.com/forum/kriptografija/kakperedaetsjaparoljvssh
[link26] http://www.sxw.org.uk/computing/patches/openssh.html
[link27] http://www.openbsd.org/53.html
Гениально.
Предлагаю дополнить их программу атакой на PGP.
Действительно, это ж сущая мелочь: подумаешь, сменился отпечаток ключа, что в этом такого.
Это просто чудесно. Ждём, когда они додумаются, что точно так же можно SSL/TLS атаковать и OpenPGP-ключи подделывать.
В самом митме ничего нового, подумаешь написали ещё одну программу. Но в описании треш и угар.
Но если вы уже в матрице, то как положить свой ключ на сервер?
На сервере ключ и так нормальный лежит. В данном случае у вас просто нет канала связи. Атакуемый канал – считай перерезанный.
Софт для пользователей которые кошмарят школьную локалку.
SSH Man-in-the-Middle Attack and Public-Key Authentication Method[link2]
Короче, граждане, не читайте за обедом
советских газетхабру.Всякие тулзы вида SSL/SSH stripper/hijacker, основанные на игнорировании пользователем (не)доверия к сертификату/ключу, существовали давно.
Представьте, что нашлись люди которые не использовали этот чудо метод аутентификации, а делали все по старинке через пароль, но без рута. Прочитали всё это люди и побежали настраивать ключи. И тут засада, госфаерволл с митмом подняли ещё раньше. Госфаервол с элементами AI, в виде роты майоров, на лету подменяет всё на нужное. Что делать?
Криптографические протоколы помогают поддерживать доверие, передавать его от кого-то кому-то (сети доверия, центры сертификации — со всеми своими недостатками), в некоторых случаях немного усиливать слабое доверие до более высокого посредством нескольких итераций и взаимопроверок. Но проблему первоначального установления доверия в недоверяемом канале без наличия уже полученных по безопасному каналу аутентифицирующих данных они не решают.
Бежать покупать VPN. Уже давно пора.
Как VPN поможет?
Чем VPN принципиально отличается от SSH, SSL, etc?
VPN у Гостя просто слинкован с libastral.so. Пока астрал не MITM'ят — работать будет.
mission impossible.
Пробрасываем канал из насмерть зацензуренного рунета во внешний интернет. Профит.
VPN может быть по разным протоколам и портам, есть надстройки с маскировкой трафика для использования в странах типа Китая, есть туннельные транспорты через разные другие протоколы. Есть малоизвестные приватные решения. Всё затрахаются блокировать.
P.S. естественно, администрируемый сервер должен стоять в нормальной стране. Хоститься в рашке сейчас безумие, кто так делает – ССЗБ.
Фи. С цензурой надо бороться так[link3]
В современных OpenSSH-клиентах при смене ключа сервера надо руками редактировать файл ~/.ssh/known_hosts. Сложно сделать это нечайно. Очень сложно. Т.к., чтобы знать, какую именно строку комментировать, надо выполнить дополнительную команду
Большая проблема — та, что при MITM'е, когда клиент ещё не знает правильный отпечаток сервера и использует парольную аутентификацию, атакующий может легко перехватить его пароль.
Парольная аутентификация на SSH в наши дни — атавизм, от которого уже давно нужно избавиться.
Господа в треде знакомы с очень узким диапазоном случаев (скорее всего, с одним – они заходят на свой собственный сервер). В их уйутный мирок просто не проникает то, что могут быть совершенно другие ситуации, например, сервер, на который ты заходил полгода назад, а теперь поменялся ключ – что будете делать? Админ для таких вопросов считайте что недоступер. Или целая сетка таких серверов с доступом по ssh и аутентификацией через ldap. Думайте ширше. И да, с вами так нелюбимой PKI тут будет гораздо лучше, чем без нее.
С аутентификацией по ключам можно полностью защититься от митма, даже если клиент игнорирует смену сертификата – самое простое, клиент подписывает свой ключ диффи-хеллмана, это не спасет от ложного сервера (разве что сервер аутентифицируется перед клиентом знанием открытого ключа), но не даст митмеру аутентифицироваться на сервере, не имея секретного ключа, а если использовать открытый ключ DH клиента, то митмер не узнает сеансового ключа DH и пролетит.
В ssh все гораздо интереснее[link4]. Сначала идет установление зашифрованого канала, а потом идет отдельно! идет аутентификация. Клиент подписывает определенный блок значений, включая сессионный ключ, сервер это проверяет. От митма это защищает по чистой случайности, и то не при всех конфигурациях – например, если вместо DH используется только RSA, то не защищает. Также не надо забывать про downgrade. ОЛОЛО ОТСОС.
Прекратите принимать вещества ©
А ведь так хорошо начали.
Просто так ключ не меняется, поэтому:
1 – первым делом пробуем войти с другого провайдера, через vpn, с другого сервера, и.т.д. Если удалось получить прежний отпечаток – митмит ваш провайдер. Шлем его нафиг либо используем vpn на постоянной основе.
2 – митмит ваш хостер, либо на сервере глюк. Пишем в поддержку вопрос "чозанах". Атаку сняли – забираем данные, затираем диски и валим от этого хостера нафиг.
3 – атака продолжается. пробуем войти по другим защищенным протоколам (ftps, https, и.т.д.) чтобы забрать данные и потереть их с сервера.
4 – если сервер на колокейшен – приезжаем к хостеру и забираем его. Данные с дедика можно забрать с помощью такой хитрости: заблаговременно пишем скрипт который сразу и навсегда блокирует вход в систему, перекачивает данные (например дамп dd) на ваш новый сервер в зашифрованном gpg виде, по окончании этого процесса вайпит всё нафиг. Соглашаемся со сменой ключа и мгновенно запускаем этот скрипт. Атакующий получает контроль над сессией и узнает ваш пароль, но ничего не успевает сделать. Есть риск что атакующий прервет сессию сразу после получения пароля и больше вас не пустит. Тогда ой.
5 – вы дошли до этого пункта и ничего не помогло? Надеюсь вы шифровали диски на сервере и на нем есть скрипт отключающий их при подозрении на атаку, длительном невходе админа, и.т.д. Вам следует дождаться когда криптодиски будут заведомо отключены и попробовать забрать данные несмотря на атаку. Если шифрование не использовалось, вы ССЗБ и хостер вас поимеет полюбому.
там идет обрыв соединения, каждые 3 минуты. неудачная защита.
Это единичный случай. Ну гляньте логи на сайте, народ по полчаса зависает и ничего. Хотите разбираться с этим вопросом дальше? Тогда идём в топик.
У, какие вы узколобые. Пытаешься вам обьяснить, что есть разные сценарии, как десятки серверов в локалке с аутентификацией по LDAP, смену ключей на которых невозможно отследить, что даже аутентификация по ключу не всегда от митма спасает – а могла бы! А вам – как об стенку горохом. Зря я свой пост писал.
коль у вас такой широкий лоб, предлагайте (!) а не констатируйте(!). в каком месте решение? накрыться простыней и ползти на кладбище. всемогущий MiTM не победим? так что ли?
Во-первых, новые версии SSH поддерживают PKI. Кому хочется, можно использовать, как и многие другие альтернативные способы аутентификации (по одноразовым паролям и т.д.).
Да, есть. Но на pgpru преимущественно обсуждается анонимность и безопасность малых неформальных сообществ или отдельных лиц[link5]. С апскейлингом таких решений будет туго, да.
А вот привыкайте, да. Я тоже постоянно сталкиваюсь с таким. Пишешь, пишешь, а в ответ приходит какой-то Гость (17/04/2013 01:00) и, пользуясь
свободой словавседозволенностью на форуме, поливает всё говном. Потом ещё администратор придёт и добавит "это интернет, детка, тут могут и нах послать", "не делайте из нас башню из слоновой кости".Если атакующий смог похитить серверные ключи из /etc/ssh, никто ему не мешает так же забрать и клиентские ключи из ~/.ssh/authorized_keys.
Если клиент не заинтересован в безопасности, он всегда сможет её саботировать. На мой взгляд, глупо обсуждать протокол, при котором клиента принуждают веси себя безопасно. Можно вывести предупреждение хоть на весь экран и красными буквами, но если клиент намеренно игнорирует, что тут поможет? Это один из ключевых моментов протокола.
Вы хотите, чтобы у протокола был дизайн, полностью устойчивый к краже ключа и полной компрометации? Хотите невозможного? В ssh сделали то, что могли. Представьте себе случай PGP-шифрованной переписки двух лиц, при которой атакующий похищает приватный ключ одной из сторон. Кардинальных отличий между этим случаем и ssh не вижу.
Там DH по умолчанию же вроде? Использование RSA — это что? Какие-то дополнительные опции в sshd_config, отключенные по умолчанию? Или случай, когда клиент сгенерил RSA-ключ вместо DSA для аутентификации себя перед сервером (ssh-keygen -t dsa или -t rsa)? Насчёт downgrade до RSA — это возможно всегда в дефолтной конфигурации ssh-сервера?
В дефолтной конфигурации спасает? Если нет, то что необходимо изменить в конфигурации клиента/сервера?
Когда-то не было согласования (выработки совместного ключа) по эфемерному DH, а были одноразовые RSA-ключи.
Гость (17/04/2013 17:41[link6]), это не ты ли весь тред про ЭК SSL сертификаты хрень какую-то нес? Если это ты – пожалуйста, просто сдрыстни.
Это где-то написано?
Ну я тоже послать могу, дальше что?
Я описал ситуацию, где этот подход неприменим. Не надо быть таким твердолобым и думать, что мир на Вас и Ваших проблемах замкнулся.
Компрометации закрытого ключа клиента нет. Читать научитесь, чтоли.
https://www.pgpru.com/comment63274
1. А с какого хрена я должен что-то предлагать?
2. Я уже предложил – хотя бы подписаный диффи-хеллман, или Вам эти каракули ни о чем не говорят? Алсо, смотреть в сторону SSL.
Есть такая вещь, как простановка ссылок в самом тексте. Вам не понять.
Сами-то смотрели[link7]? 24-часовой таймаут не смущает?
Интересно, как обстоят дела с регенерацией симметричных ключей в SSH-сессии...
https://www.pgpru.com/comment63281
Я не про Вашу ссылку, запрятанную в ебенях форума, я про что-то, что видно сразу по заходу на сайт.
И действительно, научитесь. Я вроде бы обьяснил, что у меня другой сценарий.
Вы хоть что-то по теме написать можете, или только балаболить в состоянии?
Вам шашечки или ехать? Ссылка дана на мнение модератора ресурса, благодаря вкладу которого этот ресурс вообще существует в том виде, к какому все уже давно привыкли и воспринимают, как само собой разумеющееся. Есть /proekt[link8], из него тоже негласно это следует, но уточнять не решили. Не то, чтоб здесь запрещено обсуждение чего-то иного, просто иное мало кому интересно. На тему принуждения к соблюдению ИБ в государственных и коммерческих компаниях есть другие интернет-ресурсы с другой публикой.
Лично я отвечал Гостю (17/04/2013 00:07), ссылка была дана им.
Если вам прошлого раза[link9] мало, и выводы не сделаны, ваши глубокие мысли по теме могут проредить ещё раз. И, наконец, потрудитесь вставлять ссылки не кишками, а как положено в wiki.
Ахаха, так это таки ты. Вали, дорогой, ты все равно нихера не знаешь, только время на тебя просирать. Все с тобой понятно, и уже давно.
Гость (17/04/2013 00:07) это я и есть, ака топикстартер, дубинушка. Лучше бы имя ТС освободили.
https://www.pgpru.com/comment63277
Интересно, можно подробности? Или это через DNSSEC, который появится лет через 15?
По делу писать пробовали?
Нет, я уже сдристнул[link10]. Если с вами кто-то ещё из читателей хочет покидаться говном, пусть для вас ищет ссылки и описывает подробности, с меня хватит.
Зачем так толсто? Если не видите связи аутентификации с имперсонацией (а равно и со следствиями при краже ключа) — это должно быть поводом подумать, а не потроллить.
Не надо мне давать поводы и на что-то намекать. Я дал ссылку на то, что, похоже, SSH сосет у митма даже при аутентификации по ключам, хотя возможности защититься есть. Кто хочет аргументированно обсудить (аргументированно – это с аргументами) – давайте.
Есть кто живой из тех, кто шарит?
Прежде, чем делать громкие заявления, вопрос:
По ссылке
Чёрным по белому написано
Вопрос 1: «Этот ключ» — это какой? Напоминаю, что сервер имеет
Вопрос 2: Откуда у сервера-митмера возьмётся этот ключ?
Не читайте то, читайте это[link4]. Там написано, что c RSA вместо DH митм возможен.
Для тех, кто считает, что RSA – это днище, везде есть DH, напомню о downgrade. Т.е. небезопасные протоколы должны быть отключены как минимум на одном конце.
Отвечаю на ссылку здесь[link11], вы мне орёте, что надо читать пост на хабре. Читаю пост на хабре — опять даёте ссылку stackexchange. Может, вы-таки определитесь со своим вопросом?
Про пост со stackexchange я уже написал. Могу повторить ещё раз:
DH:
RSA:
Итак, снова возвращаюсь к своему вопросу 2:
Соответственно, в случае RSA, откуда у него возьмётся «transient private key»? Для незнающих, что это, даю ссылку[link12].
Гость (20/04/2013 22:54), я уже не помню, где кто на что отвечал, плюс нету ников и мало кто ставит ссылки на посты, на которые отвечают (на имиджбордах и то так делают). Ставь ссылку на свой пост и скажи спасибо своим соседям по форуму, нафлудившими 3 страницы.
Похоже, я экстраполировал ответ на crypto.se на другую ситуацию
Т.е.
Если бы в него не входил открытый ключ сервера, то все бы прошло. Отсос пока отменяется.
Однако, все-таки проблемы в алгоритме ssh есть – при знании секретного ключа сервера и RSA аутентификации митм возможен, хотя этого можно было бы избежать. Раздельные установление шифрованого канала и аутентификация по ключам с точки зрения криптографии – бред.
Наверно, я отвечал. И мои «соседи» — тоже я. Полный список моих постов в этой ветке (17/04/2013 00:05)[link13], (17/04/2013 17:41)[link14], (17/04/2013 20:15)[link15], (17/04/2013 20:36)[link16], (17/04/2013 22:29)[link17], (18/04/2013 22:23)[link18], (20/04/2013 19:36)[link19], (20/04/2013 22:54)[link20]. Остальные гостевые посты — не мои.
Разве проблема митмеру узнать публичный ключ сервера? Если он инициирует соединение с сервером, сервер ему свой ключ предложит, поэтому митмер его узнает. Или я что-то не понимаю?
Ясно, что MITM в нормальном SSH в документированном его использовании невозможен. Протокол писали не дураки, и если бы сейчас вскрылась возможность MITM'а, это был бы ор на весь интернет ещё похлеще, чем с Debian OpenSSL[link21].
Что касается SSH в недокументированном его использовании, тут может быть всё, что угодно. Я усредно вас подвожу к вопросу, откуда ключи у митмера, но вы молчите. Придётся воспользоваться хрустальными шарами. Итак, первый вариант — кража, второй вариант — клиенту пофиг на отпечаток сервера, он всегда жмёт YES (с функциональной точки зрения этот случай идентичен первому). В частности, именно второй вариант был предложен на хабре. Первый выше предложил я (см. мои посты). Как бы там ни было, кража ключа выводится за рамки угрозы всегда, это ключевой момент. Спекулировать о том, что можно сделать, украв ключ (или если жертве всё равно, какой ключ), можно, но уязвимостью самого протокола это не считается.
Протокол SSH — клиент-серверный, в самом этом определении заложено неравенство, поэтому клиент доказывает свою идентичность и аутентифицируется перед сервером, прежде всего, а не наоборот.
Восстаналиваю логику этого треда:
5-ый пункт проще всего объяснить в терминах PGP. Чтобы было в точности параллельно ситуации с SSH, предположим, что для каждого собеседника каждый использует уникальную ключевую пару «публичный/приватный ключ». Дальше первый из собеседников теряет ключ второго. Второй при этом якобы может доказать свою идентичность владением публичным ключом первого. Что-то в этом разумное есть, конечно. Можно формализовать это, как требование раскрыть информацию, которая ранее была известна только между этими сторонами и никогда не передавалась третьей стороне. Случай кражи, впрочем, тут вообще не защищается: раз атакующий может похитить приватный ключ второго собеседника, он может у него же похитить и публичный ключ для первого.
В /comment50979[link22] была дана ссылка[link23] (заметьте, это ещё 2006-ой год). Для собственных целей не пользовался, подробностей сказать не могу. Была попытка обсуждать[link24] это на форуме.
Кстати, не уверен, что из этого легко можно сделать протокол. Вся суть асимметричного крипто в том, что есть пары приватный-публичный, где информацию, зашифрованную публичным ключом, расшифровывает только владелец приватного. Как заставить это работать иначе? Если я просто вышлю публичный ключ в доказательство владения им по неаутентифицированному и шифрованному каналу, его прочитает митмер. Т.е. стороны не избавятся от митмера, т.к. он подменит информацию при выработке новых ключей обычным способом.
Впрочем, есть протоколы аутентификации основанные на том, что обе стороны владеют какими-то общим секретом (по-моему, они тоже сводятся к DH). В частности, в том же OTR есть аутентификация по общему симметричному ключу, известному обоим абонентам.
https://www.pgpru.com/comment63420
в сессионный ключ.
Я даже не говорю о реальности ситуации, когда у атакующего будет закрытый ключ сервера, и саму ситуацию я взял с crypto.se. Просто факт, что SSH при ней может пасовать, хотя от этого можно было бы защититься, пока можно провести аутентификацию по ключу клиента. Неясно, где еще этот недостаток (раздельное установление канала и аутентификация ключами) может боком вылезти.
3. Да, во многих ситуациях это – относительно нормальное положение дел. Добро пожаловать в реальный мир, нео.
4А. Украсть открытый ключ клиента != подменить его на сервере
4Б. Если клиент не знает сервер, сервер все еще имеет открытый ключ клиента.
5. Не совсем, точнее, лишь как одна опция. Атака невозможна в случае использовании DH.
В общем, подведем итог – аутентификация по ключу вроде бы митмом не ломается, но неприятный осадок от сумбурной структуры аутентификации SSH остался.
Дык, это что вообще? Как его ставить, как оно будет работать с существующими программами?
почитал...
ощущение, что где-то здесь: пост Гость (21/04/2013 07:30), должно закончится обсуждение. ибо все варианты с кражами и физ доступом к машинам, хранящим секретные ключи, – "бондиада" или интерпретации атак без относительно к самому SSH.
Ставьте ссылку на посты, мне очень интересно листать 4 страницы и сравнивать даты.
По-моему, так везде делается. Сначала устанавливается шифрованный канал со стороной, а потом выясняется, та ли эта сторона или нет. Могу привести в пример шифрование в IM (пусть тот же OTR в XMPP). По умолчанию шифрование там оппортунистическое по DH, причём ключи сторон никак не проверяются. Если у вас есть желание и возможность, после установления шифрованной сессии можно запросить отпечаток OTR, подписанный PGP-ключом собеседника (и выслать ему, соответственной, свой подписанный). Другие протоколы в IM требовали того же: сверки отпечатков по какому-то заранее аутентифицированному каналу (телефон, PGP-переписка и т.д.). Если сверить по каким-то причинам нельзя, то да, MITM будет успешно работать, но провести его надо при самом первом сеансе, т.к. после этого отпечатки ключей запоминаются и попытка MITM'ера сменить ключ тут же вызовет ругнань в IM, и попытка MITM'а будет раскрыта. С SSH аналогично: если MITM'ер не успел провести атаку в самый первый сеанс, то всё: ssh-клиент запомнил отпечаток и сразу же заметит, если он позже сменится.
Как клиент может «забыть» отпечаток сервера? Он сохраняется в настройках автоматически. Если он сохранился хотя бы в одном месте, позже можно его оттуда извлечь и перенести в любой другой профиль, даже автоматически (не логинясь на сервер заново из-под нового профиля).
Более реальная проблема — получить достоверный отпечаток сервера, чтобы зайти туда первый раз и загрузить свой (клиентский) ключ. Можно в крайнем случае поступить так: сначала зайти как есть, приняв любой предложенный отпечаток, а потом узнать валидный отпечаток по сторонним методам (аутентифицированному какому-то каналу). Если сравнение не покажет различий, можно будет постфактум установить, что MITM'а никогда не было.
Я имел в виду случай, когда атакующий взломал (настоящий) сервер и может делать на нём всё, что захочет. Вы же, как я теперь понял, имели в виду подставной сервер, пытающийся скормить клиенту его фейковый публичный ключ.
На мой взгляд, критичнее вывод, к которому пришли в этом треде[link25]: если клиент не знает отпечатка ключа сервера и жмёт YES, то, в случае MITM-атаки, атакующий просто-напросто получает его пароль. Масштабы последствий, думаю, пояснять не нужно.
Это не то ли[link26], что вам надо?
Да, согласен. Тем не менее, вопрос «что можно сделать, если похищен ключ, или клиенту всё равно, какой ключ у сервера» я лично для себя нахожу всё же интересным, поэтому и ввязался в обсуждение. Строго говоря — да, это не обсуждение SSH как такового.
Имхо, удалённый сервер, да ещё и такой, на котором ты не администратор — заведомо уязвимая сущность, поэтому годится лишь как перевалочный узел для шифрованных данных или как нода для р(о)утинга трафика. В обоих случаях противник ничего концептуального не получит, даже авторизовавшись на сервере под моими кредентиалсами. Максимум, чего он добётся — порушит сетевую инфраструктуру. Я имею в виду анонимное использование SSH-серверов через Tor, купленных у хостинг-провайдеров.
Можно и из консоли: ssh-keygen -R hostname
Интересный improvement[link27]: