Почему аутентификация по паролю SSH представляет угрозу безопасности?
В большинстве руководств по настройке OpenSSH рекомендуется отключать аутентификацию по паролю в пользу аутентификации на основе ключей. Но, на мой взгляд, аутентификация по паролю имеет существенное преимущество: возможность подключения абсолютно из любого места без ключа. Если всегда использовать надежный пароль, это не должно быть угрозой безопасности. Или это должно?
11 ответов
There are pro's and con's for either pw or key-based authentication.
In some cases, for example, key-based authentication is less secure than password authentication. In other cases, its pw-based that's less secure. In some cases, one is more convenient, in others, less.
Все сводится к следующему: когда вы выполняете аутентификацию на основе ключей, вы должны защитить свой ключ парольной фразой. Если у вас не запущен ssh-агент, который освобождает вас от необходимости вводить парольную фразу каждый раз, вы ничего не получили в плане удобства. Безопасность спорна: вектор атаки теперь сместился с сервера на ВАС, или на Вашу учетную запись, или на Ваш персональный компьютер (...) - их может быть, а может и не быть легче сломать.
Думайте нестандартно, решая это. Вы получаете или теряете с точки зрения безопасности, зависит от остальной части вашей среды и других мер.
редактировать: О, только что увидел, что вы говорите о домашнем сервере. Я был в той же ситуации, "пароль" или "флешка с ключом на нем" всегда со мной? Я выбрал первый, но изменил порт прослушивания SSH на что-то отличное от 22. Это останавливает всех этих грубых злоумышленников, перебирающих зверства, форсирующих целые диапазоны сети.
Использование ключей SSH имеет одну уникальную особенность по сравнению с паролем: вы можете указать разрешенные команды. Это можно сделать, изменив ~/.ssh/authorized_keys файл на сервере.
Например,
command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...
разрешит только команду `/usr/local/bin/your_backup_script.sh" с этим конкретным ключом.
Вы также можете указать разрешенные хосты для ключа:
from="yourclient,yourotherclient", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...
Или объединить два:
from="yourbackupserver", command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...
С помощью ключей вы также можете предоставить временный доступ некоторым пользователям (скажем, консультантам) к серверу, не раскрывая пароль для этой конкретной учетной записи. После того, как консультант завершил свою работу, временный ключ может быть удален.
Вы можете получить лучшее из обоих миров, разрешив только аутентификацию по паролю из вашей сети. Добавьте следующее в конец вашего sshd_config:
PasswordAuthentication no
Match Address 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
PasswordAuthentication yes
Когда вы входите с паролем, вы передаете свой пароль на сервер. Это означает, что оператор сервера может изменить SSHD, чтобы получить доступ к вашему паролю. При аутентификации с открытым ключом они не могут получить ваш закрытый ключ, так как только ваш открытый ключ каждый отправляется на сервер.
Ключи ssh предотвращают атаки человека по середине на ваш пароль.
когда вы пытаетесь войти с помощью ключа, сервер создает запрос на основе вашего открытого ключа и отправляет его вашему клиенту. который расшифрует его и создаст соответствующий ответ для отправки.
Ваш закрытый ключ никогда не отправляется на сервер, и любой, кто прослушивает, не может ничего сделать, кроме как перехватить этот единственный сеанс.
с паролем они будут иметь ваши учетные данные.
Мое решение состоит в том, чтобы иметь переносимый ключ ssh в подходящих форматах на зашифрованном разделе на ключе USB. это позволяет мне:
легко убрать этот ключ в случае его утери.
ограничить, какие серверы это позволяет мне доступ к
и до сих пор носи
хотя установка программного обеспечения для монтирования является проблемой (truecrypt)
Вы частично ответили на свой вопрос - чем больше мест, откуда злоумышленник может подключиться, тем больше у него возможностей взломать ваш сервер с помощью брутфорсинга (рассмотрим DDoS).
Также сравните длину вашего пароля с размером ключа (обычно тысячи бит).
Это компромисс, как говорит @MartinVejmelka.
Причина, по которой вы используете основанную на ключе аутентификацию, заключается в том, что ключ намного выше текущего или ближайшего будущего перебора, что вам нужно либо прийти с вашего собственного ПК, либо иметь ключ на USB-накопителе или что-то подобное.
Пароль имеет следующие проблемы:
- Если оно короткое, оно может быть грубо вынуждено
- Если это долго, это легко забыто
- Это может быть серфингом
Ключ на несколько порядков длиннее и не отображается ни в одной точке, поэтому он позволяет избежать этих трех проблем.
Одно из потенциальных преимуществ использования SSH над паролями состоит в том, что если вы не укажете парольную фразу SSH, вам больше никогда не придется вводить пароль... ваш компьютер по сути является доверенным для сервера, поскольку у него есть ключ. Тем не менее, я обычно всегда использую парольную фразу SSH, поэтому я исключаю эту выгоду.
Я считаю, что лучший ответ на вопрос, почему руководства пользователя часто рекомендуют аутентификацию по SSH с использованием пароля, можно найти в руководстве по Ubuntu для SSHOpenSSHKeys. Я цитирую,
Если вы не думаете, что это важно, попробуйте зарегистрировать все попытки злонамеренного входа в систему, которые вы получите на следующей неделе. На моем компьютере - совершенно обычном настольном ПК - было более 4000 попыток угадать мой пароль и почти 2500 попыток взлома только за последнюю неделю. Как вы думаете, сколько тысяч случайных предположений потребуется, чтобы злоумышленник наткнулся на ваш пароль?
По сути, если у вас надежный пароль большой длины с пунктуацией, прописными и строчными буквами и цифрами... вы, вероятно, будете в порядке с аутентификацией по паролю. Также, если вы планируете отслеживать свои журналы, и в любом случае не делаете "супер-защищенных" вещей по сети... то есть используете их для домашнего сервера. Тогда, конечно, пароль работает хорошо.
Хорошие моменты, упомянутые здесь уже.
Что я считаю самым большим риском, учитывая, что вы позаботились об основах надежного пароля, так это о том, что на многих компьютерах установлены клавиатурные шпионы, а пользователь этого не осознает. Есть даже люди, создающие целые сайты полезных утилит, которые содержат трояны, так что это может случиться с лучшими из нас. Кейлоггер, например, отправит по электронной почте данные для входа хакеру, который затем легко сможет получить доступ к серверу.
Недавно я был предупрежден Нортоном о загрузке установщика Zombee Mod (не jar, установщик) для добавления полета к банке Minecraft. Я посмотрел на детали, и Нортон перечислил много утилит на этом сайте, которые были помечены как содержащие троян. Я не знаю, правильно это или нет, но это было довольно специфично с именами файлов. Известно также, что трояны помещаются в (некоторые) хранилища до их распространения.
Passwd auth метод действительно небезопасен (imho). С помощью этого механизма пароль будет передаваться на сервер sshd (как уже сказал @ramon). Это означает, что некоторые пользователи могут изменить сервер sshd для получения пароля. С атакой "человек посередине" это очень легко осуществить в локальной сети.
Вы можете просто установить исправление на сервере sshd, установив это исправление ( https://github.com/jtesta/ssh-mitm). использование arpspoof а также iptables поместить ваш пропатченный сервер между клиентом и аутентичным сервером sshd.
Пожалуйста, отключите аутентификацию пароля: откройте файл конфигурации /etc/ssh/ssh_config и добавьте строку PasswordAuthentication no,
Вы можете обойти с -o StrictHostKeyChecking=no вариант. Это очень полезно при использовании ssh в сценарии оболочки.
ssh -o StrictHostKeyChecking=no -o ConnectTimeout=10 -o PasswordAuthentication=no -o ConnectionAttempts=5 xxUser@xxxHost