Как передается пароль в SSH?

Может быть. Юзера можно добавить не назначая ему пароль и входить в него через su -l user. Аналогично можно назначить ему ssh-ключ и ходить по ssh.

Это какой-то БСК. Зачем делать ключ из пароля? Пароль может быть слабый, зачем на него завязываться? Тогда бы уж сгенерить случайный ключ и зашифровать его своим паролем — это куда бы ни шло.


Считается, что если отMITMили, то потерявши голову по волосам не плачут. Хз.


В passwd/shadow хранятся хэши от паролей, а не сами пароли, так что брутать хоть как прийдётся.

Шо? Вас не затруднит пользоваться общепринятыми сокращениями или не пользоваться ими вообще?

Это будет лучше передачи пароля в плейнтексте, несмотря на Ваше замечание. Особенно если учесть остутствие PKI в принципе.

В случае симметричной схемы вроде challenge-response – нет.

Ап.

Это не мной придумано, как и само сокращение, но в целом согласен.


Согласен.


Признаю свою неправоту. Правда, полной ясности в вопросе всё равно нет. Что-то такое пишут в этой pdf'ке:

man-in-the-middle (MITM) attack. This attack subverts the normally secure SSH login process and can lead to the compromise of your SSH session, username and password. Securiteam has a great rite-up on this vulnerability entitled "SSH Protocol Weakness Vulnerability (MITM)." This rite-up can be found at http://www.securiteam.com/securitynews/5BP0M157PG.html.

При этом ссылка идёт на что-то вообще левое, где атака делается чисто за счёт понижения 2го протокола до 1го. То ли нерелевантная ссылка, то ли в ssh v2 так просто не получится.

Сама по себе 2ая версия не похожа на решающую какие-то проблемы (Диффи-Хеллман и контроль целостности не вижу, как могут помочь в данном вопросе):

For protocol 2, forward security is provided through a Diffie-Hellman key agreement. This key agreement results in a shared session key. The rest of the session is encrypted using a symmetric cipher, currently 128-bit AES, Blowfish, 3DES, CAST128, Arcfour, 192-bit AES, or 256-bit AES. The client selects the encryption algorithm to use from those offered by the server. Additionally, session integrity is provided through a cryptographic message authentication code (hmac-md5, hmac-sha1, umac-64, hmac-ripemd160, hmac-sha2-256 or hmac-sha2-512).

Нечто подобное описывается ещё здесь:

Imagine that you try to connect to an SSH server, but Malicious Mary intercepts your connection. She behaves just like an SSH server, though, so you don't notice, and she ends up sharing a session key with you. Simultaneously, she also initiates her own connection to your intended server, obtaining a separate session key with the server. She can log in as you because you used password authentication and thus conveniently handed her your password.

SSH counters this attack in two ways. The first is server host authentication. ...

... The second protection SSH affords is to limit the authentication methods vulnerable to this attack. The password method is vulnerable, but public-key and hostbased/RhostsRSA are immune. ...

Т.е. keyboard-interactive/password_authentication не решают проблемы.

Ключевой момент в том, что во многих случаях идущий по ssh уже имеет учётную запись в /etc/passwd, т.е. между пользователем и сервером имеет некий предрасшаренный секрет. Действительно, его можно было бы использовать для аутентификации, не разглашая явно.

При этом совсем простой способ — типа посылка сервером клиенту случайной строки с требованием вернуть хэш от их суммы — не сработает, т.к. сервер статически хранит только хэш от пароль+некоторые_данные (зависит от типа сервера, ОС и т.д.). Грубо говоря, чтобы самому серверу узнать пароль на аккаунт, его нужно брутать, что всякие тулзы типа John The Ripper и делают. Когда пользователь логинится через текстовый терминал локально, сервер узнаёт пароль, вычисляет нужный хэш и сранивает с тем, который хранится в /etc/shadow. После успешной аутентификации пароль из памяти стирается. Короче, нужен какой-то более умный способ.

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

И, в конечном счёте, какова итоговая цель? Чтобы злоумышленник, полностью прослушивающий трафик пользователя, все его команды (включая passwd) тем не менее не мог получить пароль для того, чтоб зайти с консоли? Не очень реалистично смотрится, поскольку в большинстве случаев атакующией и так не имеет физического доступа к серверу. Боюсь, что даже если бы и удалось что-то такое сделать поверх, это всё равно свелось бы к той же асимметричной криптографии со сверкой отпечатков, которая уже и без того есть в ssh. Либо из-за каких-то таких соображений эту атаку никто не развивал, либо мне просто не посчастливилось найти респектабельное (на уровне стандарта, статьи, или хотя бы слайдов на конференциях) обсуждение этой проблемы. Реквестирую в тред unknown'а.


В passwd/shadow хранятся хэши от пароль+другие_кредентиалсы, даже если ssh вообще не установлен. При чём тут challenge-response? Или имеете в виду, что ssh с помощью challenge-response может выдавать доступ к шеллу пользователям, которые не являются таковыми с точки зрения /etc/{shadow,passwd}? Т.е. тем, кто не может залогиниться непосредственно с консоли и не является пользователем ОС с точки зрения самой ОС?


Вопрос предельно не ясен. Ну сделает клиент секретный ключ из пароля, а дальше-то что, если сервер не знает самого пароля пользователя? (в UNIX это так). Как сервер удостоверится, что нечто валидно, если оно выведено из неизвестного ему секрета (напоминаю: нахождение пароля по данным в /etc/shadow — вычислительно трудная задача).

"захватив сервер ..., нападающий не получит пароль в плейнтексте" — от чего защищаемся-то? Если наш нападающий уже имеет доступ ко всему, то последний наш оплот — наш пароль что ли? Прийдётся опять хрустальные шары доставать. Наверное, предполагается, что пользователь столь глуп, что на недоверенный сервер (а доверенной может быть только личная машина, находящаяся локально под руками) ставит свой пароль, который он долго учил, выучил, и теперь использует на куче ресурсов? По уму каждый ресурс получает свой личный случайный пароль, сгенерённый с помощью pwgen. А пароли, хранящиеся в голове — только на локальный логин, локального рута и шифрование файловой системы. Всё остальное хранится где-то в файлах.

"украденный с сервера секрет нельзя использовать без дополнительного брута для аутентификации на нем" — что такое секрет с сервера? Хэш от пароля с солью? Так его и так брутать прийдётся, даже при уже существующей реализации, что вы нового своим методом добавите? Или имелся в виду приватный ключ для sshd?

В качестве заключения:


Даун. Вот в чём смысл апа? Если кто-то что-то знает и хочет сказать, ответит тут же. Вы же получаете ответ (или часть его, включающую полезную информацию) ценой того, что кто-то сел за вас, открыл гугл, и просидел пол вечера в попытках нарыть информацию по вопросу. Раз вы такими серьёзными вещами интересуетесь как улучшение безопасности SSH-протокола, неужто вы сами не можете нарыть информацию? Со стороны выглядит как паразитизм. По безопасности ssh, кстати, ещё ряд статей есть, я до них так и не добрался, их следовало бы почитать, на них даже в стандарте ссылка есть. Привыкайте к тому, что если ответа нет, то это не потому, что тут все дятлы кругом, а просто-напросто ваш вопрос не настолько всем интересен, чтобы все всё побросали и сидели даром разбирались с ним днями-ночами.

MitM SSH, по-моему, и v2, уже 100 лет как реализован в простой тулзе Cain & Abel. Если интересно, почитайте хелп / попробуйте. Даже если v2 там нет – я не вижу ничего, что могло бы при установлении защищенного канала без использования общего секрета противодействовать MitM.

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

Аутентификация по ключам автоматически отметает (отметает ли?) MitM, т.к. теперь у клиента и у сервера есть общий секрет. Правда, появляется опасность пассивного брута пароля после пассивного перехвата аутентификации.

Нападающего с сервера можно будет вычистить, а посмотрим, что вы будете делать, когда он получит все без исключение пароли, скажем, пары тысяч пользователей, и сможет тут же аутентифицироваться на нем любым из них? Бекапы защищают от изменения информации, но не от разглашения.
В случае, если ему придется сначала брутать какой-нибудь PBKDF2, его настроение сильно упадет, а Ваше улучшится.
Под "пароль в плейнтексте" я имел в виду больше "эквивалент пароля, позволяющий делать на сервере то же самое, что и пароль".

challenge-response – симметричная схема, т.е. секреты на обеих концах одинаковы и поимев сервер, мы можем утащить оттуда общий секрет клиента и сервера и потом аутентифицироваться перед этим сервером этим секретом без дополнительный операций. Для Windows NT, например, этим секретом будет хеш пароля.

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

Есть отличный протокол SRP, которому PKI не нужно вообще и который ни при каких обстоятельствах (ложный клиент, сервер, MitM) не позволяет пассивно брутать пароль. Также он не позволяет сделать MitM, не зная пароль в момент атаки. Вот только почему-то он нигде не используется, хотя он уже даже попал в стандарт TLS (SRP-TLS).

Насчет планктона. Вы не высоковато ли нос задирате? По моему личному опыту, к "планктону" относятся практически все преподаватели, которые не имеют напрямую дело с ИБ (собственно ИБ, сети). А если серверов чуть больше чем дохрена и аккаунт появляется на них через LDAP, Вы заходите на сервер с чужой машины и появляется запрос. Ваши действия? Будете запоминать отпечатки ключей всех серверов? Вы или человек дождя, или диванный теоретик :) Есть ситуации, когда SSH с парольной аутентификацией с наличием отсутствия PKI со своими функциями просто не справляется.

А может его завалили школьники задачками преподов.
Мне не нужно ничего нарывать. Я не собираюсь ничего улучшать – даже зная очевидные улучшения, я не могу никого заставить их применить. Я просто рассуждаю на интересную мне тему. Не хотите – не ищите, не хотите учавствовать в треде – Ctrl+W.

Фух, многабукав, а форма неудобная.

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

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

Т.е. из этого не стоит делать неверное заключение; "тулза, делающая MITM против X существует" -> "протокол X нестоек против MITM". Это всего лишь атака на реализацию, на невнимательных пользователей (социнженерия) или вспомогательная атака.

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

Это как минимум ресурсозатратно. Такие протоколы разрабатывались с конца девяностых, но так и не получили распространения. У нас в форуме где-то была тема про создание систем с разворачиванием асимметричного ключа из пароля через java-приложение в браузере. Кажется, автору удалось даже реализовать 1024-бит ключ (RSA?), но с полминутной-минутной задержкой.

Точно не знаю, как именно работает протокол аутентификации в SSH. Поэтому не уверен, что из

на клиенте генерировать секретный ключ из пароля и аутентифицироваться им

автоматически должно следовать

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

Обычно двустороняя аутентификация — это упрощённая/урезанная версия протоколов многосторонней аутентификации с серверами распределения сеансовых ключей (Key Distribution Centers — KDC). Только здесь вторая (отвечающая на запрос) сторона сама выступает в роли KDC. Обе стороны обрабатывают некоей функцией значения challenge-ID, nonce-random, timestamp (или что-то подобное) и выводят совместный ключ сеанса за несколько шагов протокола так, чтобы не срабатывал MITM, атаки переотправкой и т.д.

После того, как по такому согласованному каналу специально сформированные по протоколу запросы проходят нормально, стороны могут убедиться, что между ними действительно существует аутентифицированный и шифрованный канал. При этом пароль/ключ передавать не нужно. Остальную работу может довершить PAM.

Ирония ситуации в том, что после аутентификации пользователя, он может набрать su для рутового доступа или свой пароль для некоторых задач через sudo и пароль пойдёт по шифрованному каналу по буквам в реальном времени, так что можно подсчитать количество символов и стиль набора при анализе трафика. Кроме того, разворачивание асимм. ключа из пароля представляло ограниченный интерес при нестрогой односторонней аутентификации ("помню свой пароль, но отпечатки сервера не помню, но могу вспомнить по картинке-отпечатку"), возможно поэтому такой метод подзабыт. Как ограниченный и скорее имеющий нишу в областях с пониженными требованиями к безопасности в обмен на простоту и удобство (отсутствие необходимости хранить ключ и возможность аутентифицироваться в любом месте, скорее через браузер).

Про ssh v2 это был ответ на

Я написал уже, что SSH при определенных обстоятельствах (большое количество серверов) с отстутствием PKI со своими задачами не справляется.

Это ровно на 1 операцию хеширования затратнее аутентификации по ключам, согласны? Проблема, мне кажется, будет в брутаемости результата пассивного перехвата трафика.

Для аутентификации нужен закрытый ключ, на сервере открытый. Очевидно же.

Самое простое, что мне приходит в голову – DH с подписанием значения клиента его ключом.

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

Вообще
По-моему, роясь в этом направлении, я изобрету что-то вроде него :)

Дак это ж вопрос к интерфейсу. ssh-клиент при встрече с незнакомым новым сервером мог бы писать «получите отпечаток ключа сервера и внесите его в конфигурационный файл«, и до тех пор пока вы это не сделаете, процесс бы не двигался. Показа текущего, предъявляемого сервером, отпечатка можно убрать. Пользователь т.о. будет принуждён откуда-то его брать хотя бы.


Ну вы свели задачу к исходной, только теперь надо не чтобы клиент заранее знал отпечаток сервера, а сервер заранее знал отпечаток клиента. Но откуда у сервера возьмётся открытый ключ клиента? В существующей структуре аутентификации есть только ssh-ключи и пароли в форме /etc/shadow.

Если одной стороне про другую всё известно заранее, то я и так могу на клиенте в ~/.ssh/known_hosts руками прописать отпечаток сервера, после чего ssh-клиент даже не будет задавать никаких вопросов (в случае же MITM'а явно напишет что это MITM, что смена отпечатка, и затребует руками отредактировать файл ~/.ssh/known_hosts).

Естественно, что проблема MITM совершенно параллельна задаче аутентификации. MITM можно делать и при парольной аутентификации, и при public-key-аутентификации. Из того, что клиенты по разному реагируют на потенциальный MITM при разных типах аутентификации, ещё не следует делать далеко идущих выводов.


Простите, я так и не могу понять, что же мы защищаем? Конкретный вид пароля? Произвольные аутентификационные данные, позволяющие аутентифицироваться на сервере? Другие сервера, на которых пользователи по своей глупости выбрали те же пароли? Всё это разные задачи с точки зрения ИБ.


Тогда вообще при чём здесь метод аутентификации? Вы боитесь, что митмер сможет под именем пользователя зайти на сервер и делать что захочет? Так это максима, которая у него сразу имеется. Он же может от имени пользователя выполнять любые команды, вклиниваясь в уже существующее соединение, может свободно от его имени поменять параметры аутентификации — например, залить свой собственный ключ к нему в директорию ~/.ssh/authorized_keys и дальше благополучно ходить вне зависимости от того какой у пользователя ключ вообще. Если у него есть root-доступ, то список вообще шифрокий: поменять конфигурацию ssh-сервера на себе нужную, поменять (или просто добавить нужные) ключи, сменить права и uid'ы пользователей в /etc/passwd, /etc/group... список очень длинный, даже если не писать rootkit.


Верно мыслите.


То, о чём вы пишете, чисто организационные проблемы, потому и решаться они должны организационными методами. ИБ — экономика рисков. Если компании не так критична кража данных и MITM, они будут мириться с вероятностью, что это однажды произойдёт — всё равно прибыль покроет убытки. Если же компании критично, нанимают человека, который сам добавит все отпечатки в нужные конфигурационные файлы клиентов, всё согласует, а нужные действия повесит на ярлычки на десктопе. Так же, проведёт необходимый инструктаж с пользователями и определит карательные меры в случае несоблюдения техники безопасности. Это я вам не теоретизирую, а вспоминаю случаи из жизни. Помимо аутентификации по ключам в ssh имеются механизмы HostBasedAuthentication и, конечно же, PKI. Кому надо, сделают приемлемую схему под свои задачи.

Ситуацию частично спасает то, что легко сделать MITM можно только первый раз. Если атакующий сразу не вклинился в канал, нужные отпечатки уже намертво прописались в конфигах клиента. Дальнейшая их смена методом ответа "Yes/No" уже не решается, надо будет руками править. Пока пользователь правит, может и задуматься «к чему бы всё это?».


Полная уверенность в своих знаниях — признак полной некомпетентности в вопросе. В жизни есть много подводных камней, с которыми сталкиваешься псоле n лет работы над вопросом, так что не всё сводится к «весь мир плохой, не видит очевидного, я один понимаю правду». Напишите новый стандарт протокола, опубликуйте статью с детальным обоснованием его безопасности, пропихните её в рецензируемый журнал, потом напишите стандарт протокола, пропихните его в IETF, а дальше уже можете говорить «всё не переходят на новую версию, где решена куча проблем с безопасностью». Но вы, я вижу, не из робкого десятка, вам всё очевидно. Зачем при этом вопросы на форуме задавать — совсем не ясно.


Я вижу вы тут совсем новичок. Если я и unknown сделают Ctrl+W, то вы не получите вообще никакого конструктива — один информационный шлак. Пример альтернативных форумов символизирует.

Это вы про тред PGP на ходу от ДаняНадь? Кое-какие ссылки на его публикации можно найти здесь. Ну да, там, в частности, упоминается:

У меня нет возможности проверить работу с Java. Но идея понятна. Развертывание "походного" ассиметричного ключа происходит из пароля. Пользователь все равно должен доверять и рабочему терминалу и Вашему серверу

Kerberos — это оно?


Т.е. если имеется внешний сервер, то можно сделать защиту от MITM? За счёт чего так происходит, если допустить, что клиент изначально не знает ничего ни про одну из сторон? Или всё же клиенту известно нечто типа публичных ключей сервера ключей?


Хм-м, никогда не задумывался. Когда-то выяснял как передаётся пароль при парольной аутентификации в ssh (в ответ на приглашение Password:), и меня заверили что сначала он весь считывается, а только потом целиком шлётся, так что атакующий не может сказать сколько там символов. Это не правда? Конечно, это не случай su/sudo/passwd для уже установленного соединения, про который вы сейчас пишете.


Издревле для таких вещей есть одноразовые пароли (вопрос удобства остаётся). Называется, кажется, SKS, в ssh поддерживается.

ssh — это тулза, которая решает одну конкретную небольшую задачу, и делает это достаточно хорошо. Если задача — функционирующий монстр, то приходится разрабатывать/настраивать свою систему, с учётом пожеланий и требований заказчиков. ssh в такой системе будет лишь один из элементов-винтиков. Говорить «ssh не справляется» — не вполне точно, скорее «ssh в чистом виде недостаточен для решения поставленной ИБ-задачи».


Если бы на сервере хранился сам пароль, а пользователь мог бы высылать хэш/PBKDF2 от пароль+время+никуда_непередаваемый_секрет (имеющийся как у пользователя, так и на сервере), к примеру, то... может быть. Если непередаваемого секрета нет, то атакующий может побрутать пароль, а дальше сам его как надо похэшировать с временем и прочим, аутентифицируясь вместо пользователя. Если же непередаваемый секрет есть, то чем он лучше заранее имеющихся отпечатков ключей на клиентской стороне? Задача свелась к исходной.


А в чём цель тогда этой затеи, раз всё равно не отвязаться от асимметричной криптографии, а последняя уже и так имеется в ssh? Только в том, чтобы пользователям при регистрации раздавать не ключи и/или их отпечатки, а только пароли? Т.е. чисто техническое упрощение? Ведь достаточно всего-навсего добиться, чтобы пользователи сверяли отпечаток ключа сервера, заранее сообщённый им админом (ну хотя бы несколько символов из него). В случае же крупных систем на каждую клиентскую машину можно заранее ставить связку со всеми известными отпечатками, тогда ругань ssh-клиента будет исключительно при настоящем MITM'е. И, напоследок, ещё раз: в последних версиях ssh есть поддержка PKI для тех, кому совсем невмоготу.

По мере того, как разными участниками высказывались разные идеи, возникла путаница из-за отсутствия точной формулировки вопроса.
Из аутентификации по паролю теоретически можно сделать как минимум две вещи:

1. Замена асимметричного алгоритма на симметричный. Тот самый урезанный Керберос, Нидхэм-Шредер и аналоги — если только для двух сторон. А если для многих сторон — то вместо PKI это будет полноценный сервер KDC с этим протоколом (этого вроде бы нет в SSH, но как отдельный инструмент можно скрестить наверное). Он защитит от MITM, даст аутентификацию и избавит от необходимости помнить аутентифицирующие данные всех серверов (и станет самой уязвимой точкой системы, приводящей к полному провалу при компрометации — поэтому и уместнее использовать это на внутренних почтовых серверах к примеру, а не для SSH. Возможно. Есть варианты). Нужно будет каждому расшарить с ним один секретный симметричный ключ, а не хранить каждому весь список.
2. Обычный асимметричный алгоритм, но с разворачиванием асимметричного ключа каждый раз заново по паролю.

Может быть и что-то ещё (Identity Based Crypto — но это пока не получило широкого распространения, хотя это фактически тот же PKI на асимметричных EC-алгоритмах).

Ага, обсуждалось под маркой «личностной криптографии».

вот пример, в SSH2 это есть, так же как PKI с сертификатами и OpenPGP и вообще хорошая книжка, в открытом доступе от этого изд-ва как обычно старая версия, но может ответы на многие вопросы прояснить.

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

Именно это я и написал в ТС посте. Неясности возникли из-за того, что некоторые комментаторы пишут посты на экран, не понимая, как работает защищенный канал :)
Так это возможно? Или остается возможность пассивного брута?

Керберос, симметричный алгоритм? Нинужен. Хотет асимметричное. Неужто он в чем-то лучше PKI?