id: Гость   вход   регистрация
текущее время 18:38 28/03/2024
Автор темы: Гость, тема открыта 16/04/2013 06:23 Печать
Категории: право, политика
https://www.pgpru.com/Форум/Криптография/АутентификацияВSSHV2
создать
просмотр
ссылки

Аутентификация в SSH v.2


Ээ чё? В SSH v2 аутентификация с ключами разве не взаимная? Если сервер не знает открытого ключа клиента, то клиент разве не должен разорвать соединение?


 
На страницу: 1, 2, 3, 4 След.
Комментарии
— Гость (21/04/2013 07:51)   <#>

Кстати, не уверен, что из этого легко можно сделать протокол. Вся суть асимметричного крипто в том, что есть пары приватный-публичный, где информацию, зашифрованную публичным ключом, расшифровывает только владелец приватного. Как заставить это работать иначе? Если я просто вышлю публичный ключ в доказательство владения им по неаутентифицированному и шифрованному каналу, его прочитает митмер. Т.е. стороны не избавятся от митмера, т.к. он подменит информацию при выработке новых ключей обычным способом.

Впрочем, есть протоколы аутентификации основанные на том, что обе стороны владеют какими-то общим секретом (по-моему, они тоже сводятся к DH). В частности, в том же OTR есть аутентификация по общему симметричному ключу, известному обоим абонентам.
— Гость (21/04/2013 09:48)   <#>
https://www.pgpru.com/comment63420
в сессионный ключ.

Я даже не говорю о реальности ситуации, когда у атакующего будет закрытый ключ сервера, и саму ситуацию я взял с crypto.se. Просто факт, что SSH при ней может пасовать, хотя от этого можно было бы защититься, пока можно провести аутентификацию по ключу клиента. Неясно, где еще этот недостаток (раздельное установление канала и аутентификация ключами) может боком вылезти.

3. Да, во многих ситуациях это – относительно нормальное положение дел. Добро пожаловать в реальный мир, нео.
4А. Украсть открытый ключ клиента != подменить его на сервере
4Б. Если клиент не знает сервер, сервер все еще имеет открытый ключ клиента.
5. Не совсем, точнее, лишь как одна опция. Атака невозможна в случае использовании DH.

В общем, подведем итог – аутентификация по ключу вроде бы митмом не ломается, но неприятный осадок от сумбурной структуры аутентификации SSH остался.

Дык, это что вообще? Как его ставить, как оно будет работать с существующими программами?
— Гость (21/04/2013 11:46)   <#>
почитал...
ощущение, что где-то здесь: пост Гость (21/04/2013 07:30), должно закончится обсуждение. ибо все варианты с кражами и физ доступом к машинам, хранящим секретные ключи, – "бондиада" или интерпретации атак без относительно к самому SSH.
— Гость (21/04/2013 21:05)   <#>
Ставьте ссылку на посты, мне очень интересно листать 4 страницы и сравнивать даты.
— Гость (22/04/2013 00:51)   <#>

По-моему, так везде делается. Сначала устанавливается шифрованный канал со стороной, а потом выясняется, та ли эта сторона или нет. Могу привести в пример шифрование в IM (пусть тот же OTR в XMPP). По умолчанию шифрование там оппортунистическое по DH, причём ключи сторон никак не проверяются. Если у вас есть желание и возможность, после установления шифрованной сессии можно запросить отпечаток OTR, подписанный PGP-ключом собеседника (и выслать ему, соответственной, свой подписанный). Другие протоколы в IM требовали того же: сверки отпечатков по какому-то заранее аутентифицированному каналу (телефон, PGP-переписка и т.д.). Если сверить по каким-то причинам нельзя, то да, MITM будет успешно работать, но провести его надо при самом первом сеансе, т.к. после этого отпечатки ключей запоминаются и попытка MITM'ера сменить ключ тут же вызовет ругнань в IM, и попытка MITM'а будет раскрыта. С SSH аналогично: если MITM'ер не успел провести атаку в самый первый сеанс, то всё: ssh-клиент запомнил отпечаток и сразу же заметит, если он позже сменится.


Как клиент может «забыть» отпечаток сервера? Он сохраняется в настройках автоматически. Если он сохранился хотя бы в одном месте, позже можно его оттуда извлечь и перенести в любой другой профиль, даже автоматически (не логинясь на сервер заново из-под нового профиля).

Более реальная проблема — получить достоверный отпечаток сервера, чтобы зайти туда первый раз и загрузить свой (клиентский) ключ. Можно в крайнем случае поступить так: сначала зайти как есть, приняв любой предложенный отпечаток, а потом узнать валидный отпечаток по сторонним методам (аутентифицированному какому-то каналу). Если сравнение не покажет различий, можно будет постфактум установить, что MITM'а никогда не было.


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


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


Using GSSAPI key exchange allows you to leverage an existing key management infrastructure such as Kerberos or GSI, instead of having to distribute ssh host keys throughout your organisation. With GSSAPI key exchange servers do not need ssh host keys when being accessed by clients with valid credentials.

Это не то ли, что вам надо?


Да, согласен. Тем не менее, вопрос «что можно сделать, если похищен ключ, или клиенту всё равно, какой ключ у сервера» я лично для себя нахожу всё же интересным, поэтому и ввязался в обсуждение. Строго говоря — да, это не обсуждение SSH как такового.

Имхо, удалённый сервер, да ещё и такой, на котором ты не администратор — заведомо уязвимая сущность, поэтому годится лишь как перевалочный узел для шифрованных данных или как нода для р(о)утинга трафика. В обоих случаях противник ничего концептуального не получит, даже авторизовавшись на сервере под моими кредентиалсами. Максимум, чего он добётся — порушит сетевую инфраструктуру. Я имею в виду анонимное использование SSH-серверов через Tor, купленных у хостинг-провайдеров.
— Гость (05/05/2013 06:03)   <#>

Можно и из консоли: ssh-keygen -R hostname

Интересный improvement:
sshd(8): Added support for multiple required authentication in SSH protocol 2 via an AuthenticationMethods option. This option lists one or more comma-separated lists of authentication method names. Successful completion of all the methods in any list is required for authentication to complete. This allows, for example, requiring a user having to authenticate via public key or GSSAPI before they are offered password authentication.
На страницу: 1, 2, 3, 4 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3