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

Как VPN поможет?

Пробрасываем канал из насмерть зацензуренного рунета во внешний интернет. Профит.

VPN у Гостя просто слинкован с libastral.so. Пока астрал не MITM'ят — работать будет.

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

P.S. естественно, администрируемый сервер должен стоять в нормальной стране. Хоститься в рашке сейчас безумие, кто так делает – ССЗБ.

Фи. С цензурой надо бороться так

В современных OpenSSH-клиентах при смене ключа сервера надо руками редактировать файл ~/.ssh/known_hosts. Сложно сделать это нечайно. Очень сложно. Т.к., чтобы знать, какую именно строку комментировать, надо выполнить дополнительную командуКогда-то раньше, в старых клиентах, — да, было достаточно написать yes в ответ на вопрос.

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

Парольная аутентификация на SSH в наши дни — атавизм, от которого уже давно нужно избавиться.

Господа в треде знакомы с очень узким диапазоном случаев (скорее всего, с одним – они заходят на свой собственный сервер). В их уйутный мирок просто не проникает то, что могут быть совершенно другие ситуации, например, сервер, на который ты заходил полгода назад, а теперь поменялся ключ – что будете делать? Админ для таких вопросов считайте что недоступер. Или целая сетка таких серверов с доступом по ssh и аутентификацией через ldap. Думайте ширше. И да, с вами так нелюбимой PKI тут будет гораздо лучше, чем без нее.

С аутентификацией по ключам можно полностью защититься от митма, даже если клиент игнорирует смену сертификата – самое простое, клиент подписывает свой ключ диффи-хеллмана, это не спасет от ложного сервера (разве что сервер аутентифицируется перед клиентом знанием открытого ключа), но не даст митмеру аутентифицироваться на сервере, не имея секретного ключа, а если использовать открытый ключ DH клиента, то митмер не узнает сеансового ключа DH и пролетит.

В ssh все гораздо интереснее. Сначала идет установление зашифрованого канала, а потом идет отдельно! идет аутентификация. Клиент подписывает определенный блок значений, включая сессионный ключ, сервер это проверяет. От митма это защищает по чистой случайности, и то не при всех конфигурациях – например, если вместо DH используется только RSA, то не защищает. Также не надо забывать про downgrade. ОЛОЛО ОТСОС.

Прекратите принимать вещества ©
А ведь так хорошо начали.

а теперь поменялся ключ – что будете делать?

Просто так ключ не меняется, поэтому:

1 – первым делом пробуем войти с другого провайдера, через vpn, с другого сервера, и.т.д. Если удалось получить прежний отпечаток – митмит ваш провайдер. Шлем его нафиг либо используем vpn на постоянной основе.
2 – митмит ваш хостер, либо на сервере глюк. Пишем в поддержку вопрос "чозанах". Атаку сняли – забираем данные, затираем диски и валим от этого хостера нафиг.
3 – атака продолжается. пробуем войти по другим защищенным протоколам (ftps, https, и.т.д.) чтобы забрать данные и потереть их с сервера.
4 – если сервер на колокейшен – приезжаем к хостеру и забираем его. Данные с дедика можно забрать с помощью такой хитрости: заблаговременно пишем скрипт который сразу и навсегда блокирует вход в систему, перекачивает данные (например дамп dd) на ваш новый сервер в зашифрованном gpg виде, по окончании этого процесса вайпит всё нафиг. Соглашаемся со сменой ключа и мгновенно запускаем этот скрипт. Атакующий получает контроль над сессией и узнает ваш пароль, но ничего не успевает сделать. Есть риск что атакующий прервет сессию сразу после получения пароля и больше вас не пустит. Тогда ой.
5 – вы дошли до этого пункта и ничего не помогло? Надеюсь вы шифровали диски на сервере и на нем есть скрипт отключающий их при подозрении на атаку, длительном невходе админа, и.т.д. Вам следует дождаться когда криптодиски будут заведомо отключены и попробовать забрать данные несмотря на атаку. Если шифрование не использовалось, вы ССЗБ и хостер вас поимеет полюбому.

Фи. С цензурой надо бороться так

там идет обрыв соединения, каждые 3 минуты. неудачная защита.

там идет обрыв соединения, каждые 3 минуты. неудачная защита.

Это единичный случай. Ну гляньте логи на сайте, народ по полчаса зависает и ничего. Хотите разбираться с этим вопросом дальше? Тогда идём в топик.

У, какие вы узколобые. Пытаешься вам обьяснить, что есть разные сценарии, как десятки серверов в локалке с аутентификацией по LDAP, смену ключей на которых невозможно отследить, что даже аутентификация по ключу не всегда от митма спасает – а могла бы! А вам – как об стенку горохом. Зря я свой пост писал.

У, какие вы узколобые.

коль у вас такой широкий лоб, предлагайте (!) а не констатируйте(!). в каком месте решение? накрыться простыней и ползти на кладбище. всемогущий MiTM не победим? так что ли?

с вами так нелюбимой PKI тут будет гораздо лучше, чем без нее.

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

есть разные сценарии

Да, есть. Но на pgpru преимущественно обсуждается анонимность и безопасность малых неформальных сообществ или отдельных лиц. С апскейлингом таких решений будет туго, да.

У, какие вы узколобые

А вот привыкайте, да. Я тоже постоянно сталкиваюсь с таким. Пишешь, пишешь, а в ответ приходит какой-то Гость (17/04/2013 01:00) и, пользуясь свободой слова вседозволенностью на форуме, поливает всё говном. Потом ещё администратор придёт и добавит "это интернет, детка, тут могут и нах послать", "не делайте из нас башню из слоновой кости".

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

Если атакующий смог похитить серверные ключи из /etc/ssh, никто ему не мешает так же забрать и клиентские ключи из ~/.ssh/authorized_keys.

клиент игнорирует смену сертификата

Если клиент не заинтересован в безопасности, он всегда сможет её саботировать. На мой взгляд, глупо обсуждать протокол, при котором клиента принуждают веси себя безопасно. Можно вывести предупреждение хоть на весь экран и красными буквами, но если клиент намеренно игнорирует, что тут поможет? Это один из ключевых моментов протокола.

От митма это защищает по чистой случайности

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

и то не при всех конфигурациях – например, если вместо DH используется только RSA, то не защищает.

Там DH по умолчанию же вроде? Использование RSA — это что? Какие-то дополнительные опции в sshd_config, отключенные по умолчанию? Или случай, когда клиент сгенерил RSA-ключ вместо DSA для аутентификации себя перед сервером (ssh-keygen -t dsa или -t rsa)? Насчёт downgrade до RSA — это возможно всегда в дефолтной конфигурации ssh-сервера?

даже аутентификация по ключу не всегда от митма спасает – а могла бы

В дефолтной конфигурации спасает? Если нет, то что необходимо изменить в конфигурации клиента/сервера?

Когда-то не было согласования (выработки совместного ключа) по эфемерному DH, а были одноразовые RSA-ключи.

Гость (17/04/2013 17:41), это не ты ли весь тред про ЭК SSL сертификаты хрень какую-то нес? Если это ты – пожалуйста, просто сдрыстни.

Это где-то написано?

Ну я тоже послать могу, дальше что?

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

Компрометации закрытого ключа клиента нет. Читать научитесь, чтоли.

https://www.pgpru.com/comment63274
1. А с какого хрена я должен что-то предлагать?
2. Я уже предложил – хотя бы подписаный диффи-хеллман, или Вам эти каракули ни о чем не говорят? Алсо, смотреть в сторону SSL.

Есть такая вещь, как простановка ссылок в самом тексте. Вам не понять.

В ssh все гораздо интереснее

What could a hacker do while provided with the SSH server private key and a MitM position specifically when the client is authenticated with a public key

Компрометации закрытого ключа клиента нет. Читать научитесь, чтоли.