Ваш пароль SSH раскрывается, когда вы пытаетесь подключиться к неправильному серверу?
192
Когда вы случайно пытаетесь подключиться к неправильному серверу с учетными данными пароля, может ли администратор прочитать и записать пароль, который вы использовали?
В ssh-клиенте вы сначала аутентифицируете сервер и делаете так: «Я верю, что могу сообщить свой пароль этому серверу». В следующий раз обратите более пристальное внимание на сообщение, которое вы увидели первым: «Подлинность X не может быть установлена. Отпечаток ключа RSA - Y Вы уверены, что Z? (Да / нет)» Этот раздражающий вопрос не задавался бы, если бы вы предполагали автоматически отвечать да каждый раз.
Кубанчик
6
Можно установить PasswordAuthentication noпо умолчанию в OpenSSH и включить его (только если это необходимо) для доверенных серверов. В сочетании со строгой проверкой ключа хоста это должно в основном защищать вас от раскрытия пароля, что, конечно же, обходится недешево.
Хоббс
6
@kubanczyk, если вы хотите использовать SSH для «internal-www.my-company.com», но случайно набрали «ssh www.my-company.com», это приглашение не защитит вас - вероятно, оба сервера в вашем списке доверенных, просто один из них принадлежит вам, а другой - третьей стороне.
Марк
ChallengeResponseAuthentication noЯ думаю, что @hobbs тоже
ilkkachu
Ответы:
215
Проще говоря: да
Подробнее...
Если вы подключитесь к моей машине, то вы не будете знать, работает ли у меня обычный sshсервер или тот, который был изменен для записи переданного пароля.
Кроме того, мне не обязательно вносить изменения sshd, но я мог бы написать модуль PAM (например, используя pam_script), которому будет передан ваш пароль.
Так да. НИКОГДА не отправляйте свой пароль на ненадежный сервер. Владелец машины мог легко настроить ее для регистрации всех попыток ввода пароля.
(На самом деле это не редкость в мире информационных технологий; настройте сервер honeypot для регистрации попыток ввода пароля)
Верный. По умолчанию стандарт sshdэто не пароли входа. (Если вы введете пароль в качестве имени для входа, он будет зарегистрирован, но это еще одна проблема). Стандарт sshdпредставляет собой инструмент безопасности, и поэтому учетные данные не будут регистрироваться так :-)
Стивен Харрис
116
Еще одна причина использовать пары открытый / закрытый ключ ...
gerrit
3
Некоторое время я размышлял об использовании паролей, и недавно меня осенило, что попытка войти на неправильные серверы была бы хорошим способом раскрытия моего пароля администратору вредоносного сервера.
vfclists
10
Вход на неверный сервер @vfclists также является той причиной, по которой ваш sshd-клиент хранит отпечатки пальцев для каждого сервера. При первом подключении вы принимаете этот отпечаток пальца, а затем, если он не совпадает, вы получаете гигантское предупреждение, на которое вам следует обратить внимание.
Hometoast 15.09.16
44
Лучший совет: никогда не используйте аутентификацию пароля для ssh. Протокол имеет аутентификацию pubkey по очень веским причинам; используй это!
R ..
52
Да.
Пароль отправляется после того, как зашифрованное соединение установлено, но удаленный сервер получает пароль в виде открытого текста.
Если вы заботитесь об этом, лучшее и простое решение - использовать ключи SSH.
Если у вас есть машины, которые не могут принимать ключи, то одним из решений будет создание инструмента, который надежно хранит ваши пароли, а затем использует их sshpassдля отправки правильного пароля всегда, в зависимости от сервера, к которому вы подключаетесь.
Теперь причина, по которой пароль отправляется в виде открытого текста, состоит в том, что он оставляет все решения по обработке и хранению его на удаленном конце, и клиент может быть совершенно тупым. В течение последних десяти лет в системах Linux и BSD используется несколько различных форматов хеширования (хранения) паролей ( crypt (3) ), ни один из которых не требует поддержки со стороны клиента.
Хотя это отчасти и из-за истории (то есть так было всегда). Существуют лучшие протоколы аутентификации по запросу-ответу, которые можно использовать даже с паролями. Например, SRP , который предоставляет сторонам общий секрет во время аутентификации. Он был реализован для некоторых SSH-серверов, но патч для OpenSSH предназначен для (очень) старой версии.
Проблема с протоколами «запрос-ответ» для аутентификации по паролю состоит в том, что некоторые из них требуют, чтобы сервер сохранял пароль в виде простого текста. Если протокол «запрос-ответ» позволяет серверу хранить хешированный пароль, то он, скорее всего, требует очень специфического алгоритма хеширования.
Касперд
8
Пароли обычно отправляются в виде «открытого текста» (т. Е. Не в открытом виде, а только с той защитой, которую обеспечивает основной SSH | TLS | независимо от того, какое соединение обеспечивает). Если бы система требовала хеширования паролей на стороне клиента и хэша для отправки, серверы не могли бы получить фактический пароль и вместо этого предоставили бы доступ любому, кто мог бы предоставить хеш пароля , что делает указанный хеш- пароль эквивалентным паролю ,
Blacklight Shining
1
@BlacklightShining Нулевые доказательства паролей существуют, но они не используются в SSH, потому что нет возможности использовать для них стандартную базу паролей и нет реального смысла их использовать, а не аутентификацию на основе ключей.
Random832
где я могу увидеть эти пароли, используемые для аутентификации? Их нет в /var/log/auth.log, где тогда?
ス レ ッ ク ス
OpenSSH не будет регистрировать пароли, не удалось или иным образом. (Я не очень знаком с другими серверами SSH.) Почти во всех законных установках любое значение, которое это может предоставить, будет перевешено риском, присущим преднамеренной записи паролей - некоторые из которых могли быть предоставлены законными пользователями, которые сделали опечатку или попробовал неверный, но правильный для чего-то еще пароль - открытым текстом. Однако, если у вас есть веская причина для этого, патчить OpenSSH будет легко.
musicinmybrain
10
В дополнение к ответу Стивена Харриса, я построил представление в реальном времени, которое показывает, что модифицированный сценарий аутентификации PAM сможет захватывать при подключении к блоку через ssh (своего рода приманка). Я использую модифицированную версию библиотеки PAM lib-storepw.
Ответы, которые в первую очередь являются ссылками, не одобряются в случае, если ссылка становится недоступной (похоже, что вы поддерживаете этот сайт лично, но все же). Вы должны немного описать, как вы справились с этим с помощью своего скрипта аутентификации для читателей.
Сентиман
он больше не работает, я отправил огромную строку в качестве пароля, я думаю, что это могло сломать ее, извините: - /
scottydelta
@scottydelta Хотя я не рассматривал это, возможно, существует ограничение на размер буфера, который может принять модуль PAM или сам демон SSH при попытке аутентификации. Сайт все еще работает, как я и предполагал, хотя и будет обрабатывать до предела буфера, принятого модулем sshd или PAM, если это действительно так.
Вилли С.
Неужели источник для вашего модифицированного lib-storepw доступен для использования другими?
Тим Флетчер
2
SSH - это протокол, который требует взаимного доверия. Вот почему клиент OpenSSH поддерживает файл known_hosts для реализации своего доверия при первом использовании.
Когда вы пытаетесь войти на сервер SSH, независимо от того, кто поставил программное обеспечение или какие данные оно настроено для регистрации, вы участвуете в некоторой процедуре аутентификации. При использовании аутентификации по паролю вы передаете свой пароль на этот сервер. Это одна из причин, по которой рекомендуется асимметричная криптография (открытый ключ, сертификаты) - криптография с открытым ключом значительно снижает риск раскрытия ваших учетных данных. (Хотя это может не защитить вас от атаки MitM, если используется переадресация ssh-agent или какая-либо подобная схема.)
SSH не требует взаимного доверия или, по крайней мере, не симметричного доверия. Важно быть точным: known_hosts - это подлинность, а не доверие. Как вы указали, размещение открытого ключа на менее доверенном хосте безопасно. Действительно, использование пароля для входа в систему также является «безопасным», если вы не используете этот пароль повторно. (Конечно, это так же безопасно, как степень, в которой вы доверяете серверу.) Даже основанные на хосте входы ssh зависят от асимметричного доверия.
PasswordAuthentication noпо умолчанию в OpenSSH и включить его (только если это необходимо) для доверенных серверов. В сочетании со строгой проверкой ключа хоста это должно в основном защищать вас от раскрытия пароля, что, конечно же, обходится недешево.ChallengeResponseAuthentication noЯ думаю, что @hobbs тожеОтветы:
Проще говоря: да
Подробнее...
Если вы подключитесь к моей машине, то вы не будете знать, работает ли у меня обычный
sshсервер или тот, который был изменен для записи переданного пароля.Кроме того, мне не обязательно вносить изменения
sshd, но я мог бы написать модуль PAM (например, используяpam_script), которому будет передан ваш пароль.Так да. НИКОГДА не отправляйте свой пароль на ненадежный сервер. Владелец машины мог легко настроить ее для регистрации всех попыток ввода пароля.
(На самом деле это не редкость в мире информационных технологий; настройте сервер honeypot для регистрации попыток ввода пароля)
источник
sshdэто не пароли входа. (Если вы введете пароль в качестве имени для входа, он будет зарегистрирован, но это еще одна проблема). Стандартsshdпредставляет собой инструмент безопасности, и поэтому учетные данные не будут регистрироваться так :-)Да.
Пароль отправляется после того, как зашифрованное соединение установлено, но удаленный сервер получает пароль в виде открытого текста.
Если вы заботитесь об этом, лучшее и простое решение - использовать ключи SSH.
Если у вас есть машины, которые не могут принимать ключи, то одним из решений будет создание инструмента, который надежно хранит ваши пароли, а затем использует их
sshpassдля отправки правильного пароля всегда, в зависимости от сервера, к которому вы подключаетесь.Теперь причина, по которой пароль отправляется в виде открытого текста, состоит в том, что он оставляет все решения по обработке и хранению его на удаленном конце, и клиент может быть совершенно тупым. В течение последних десяти лет в системах Linux и BSD используется несколько различных форматов хеширования (хранения) паролей ( crypt (3) ), ни один из которых не требует поддержки со стороны клиента.
Хотя это отчасти и из-за истории (то есть так было всегда). Существуют лучшие протоколы аутентификации по запросу-ответу, которые можно использовать даже с паролями. Например, SRP , который предоставляет сторонам общий секрет во время аутентификации. Он был реализован для некоторых SSH-серверов, но патч для OpenSSH предназначен для (очень) старой версии.
источник
В дополнение к ответу Стивена Харриса, я построил представление в реальном времени, которое показывает, что модифицированный сценарий аутентификации PAM сможет захватывать при подключении к блоку через ssh (своего рода приманка). Я использую модифицированную версию библиотеки PAM lib-storepw.
https://livesshattack.net
https://livesshattack.net/about
источник
SSH - это протокол, который требует взаимного доверия. Вот почему клиент OpenSSH поддерживает файл known_hosts для реализации своего доверия при первом использовании.
Когда вы пытаетесь войти на сервер SSH, независимо от того, кто поставил программное обеспечение или какие данные оно настроено для регистрации, вы участвуете в некоторой процедуре аутентификации. При использовании аутентификации по паролю вы передаете свой пароль на этот сервер. Это одна из причин, по которой рекомендуется асимметричная криптография (открытый ключ, сертификаты) - криптография с открытым ключом значительно снижает риск раскрытия ваших учетных данных. (Хотя это может не защитить вас от атаки MitM, если используется переадресация ssh-agent или какая-либо подобная схема.)
источник