Вопрос: Почему аутентификация паролей SSH является угрозой безопасности?


В большинстве руководств по конфигурации OpenSSH рекомендуется отключить аутентификацию паролей в пользу проверки подлинности на основе ключей. Но, на мой взгляд, аутентификация паролем имеет существенное преимущество: возможность подключения из любой точки без ключа. Если он используется всегда с надежным паролем, это не должно быть угрозой безопасности. Или это должно быть?


63
2017-11-24 12:12


Источник


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


Ответы:


Существуют профили pro и con для проверки подлинности pw или key-based.

В некоторых случаях, например, проверка подлинности на основе ключа Меньше безопаснее, чем аутентификация паролем. В других случаях его pw-based менее безопасен. В некоторых случаях один из них более удобен, в других - меньше.

Все это сводится к следующему: когда вы выполняете аутентификацию на основе ключа, вы должен закрепите свой ключ парольной фразой. Если у вас нет работы ssh-agent, которая освобождает вас от ввода вашей кодовой фразы каждый раз, вы ничего не получили с точки зрения удобства. Безопасность спорна: вектор атаки сместился от сервера к вам или вашей учетной записи или вашей личной машине, (...) - те, может или не может быть проще сломать.

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

edit: О, только что увидел, что вы говорите о домашнем сервере. Я был в той же ситуации, «пароль» или «USB-накопитель с ключом на нем» всегда со мной? Я пошел за бывшим но изменил порт прослушивания SSH на что-то другое, чем 22. Это останавливает всех этих хромых сценаристов-роботов, заставляющих целые диапазоны сети.


23
2017-11-24 13:22



Изменение SSH-порта с 22 может быть не совсем хорошей идеей во многих случаях. adayinthelifeof.nl/2012/03/12/... - Tymek


Использование ключей 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...

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


73
2017-11-24 13:32



Очень полезный совет. - Sachin Divekar
Кроме того, использование Keys похоже на наличие длинного пароля с 2000 символами (а технически его еще больше) по сравнению с тем, что вы можете вводить вручную в терминале: D - Abhishek Dujari
Два очень полезных совета о SSH-аутентификации, но на самом деле не отвечают на вопрос для меня ... - MikeMurko
Если вы хотите заставить пользователя, прошедшего проверку пароля, пройти конкретную команду, измените его оболочку входа. Кроме того, «предоставление временного доступа без раскрытия пароля» - очень плохая идея. Существует сотни различных способов сохранить доступ позже. - b0fh
Только последний абзац отвечает на вопрос. ИМО-ключи позволяют гранулировать аннулирование, в то время как с паролями вы должны сообщать всем, что вы его меняете. - Riking


Вы можете получить лучшее из обоих миров, только разрешив аутентификацию с помощью пароля в вашей сети. Добавьте следующее в конец sshd_config:

PasswordAuthentication no
Match Address 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
    PasswordAuthentication yes

45
2017-11-24 13:31



это супер удобный наконечник. У меня есть несколько серверов, с которыми я мог бы справиться. - Sirex


Вы частично ответили на свой вопрос - чем больше может атаковать злоумышленник, тем больше возможностей он может взломать на ваш сервер с помощью грубой силы (рассмотрите DDoS).

Также сравните длину вашего пароля с размером ключа (обычно тысячи бит).


6
2017-11-24 12:15



96-бит энтропии означает 80-символьный пароль, если он написан на английском языке; 15 символов, если это случайная тарабарщина из набора символов для печати. вы уверены, что ваши ssh-пароли являются длинными / сильными? - MadHatter
Если у вас несколько паролей с 96-битной энтропией, которые не будут уязвимы для атак на словарях, вам, вероятно, придется использовать какое-то программное обеспечение для управления паролями в любом случае, так что вы фактически потеряете доступный везде элемент паролей , - Nick Downton
@SachinDivekar - это 96 бит энтропии только при использовании случайных паролей из набора [a-zA-Z], а не если это английские слова. - Jaap Eldering
@NickDownton - у вас может быть хороший длинный пароль, не прибегая к программному обеспечению keypass. Что-то вроде mywifesnameisangelaandshehasanicebutt неуязвим к атакам по словарю, очень силен и очень прост для запоминания, но невозможно догадаться. И он поставляется с бонусом, если коричневые точки, если вам когда-либо понадобится отдать свой пароль вашей жене. - Mark Henderson♦
Прости, Марк, но это неправильно. Ключевая фраза, которую вы даете, имеет 37 символов и, следовательно, примерно 44 бита энтропии, которая слабее, чем 7 случайных печатных символов, и в высшей степени атакуемая. Прочтите статью Википедии о работе Клода Шеннона для подробностей, но результат состоит в том, что письменный английский очень предсказуем - например, после «mywifesname» слово «есть» почти гарантировано. Для сильных паролей, содержащих слова, четыре случайный слова, натянутые из словаря, дадут вам 10 ** 23 возможностей, что составляет около 77 бит энтропии; все еще не большой, но неплохой. - MadHatter


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


6
2017-07-09 08:10



Это особенно актуально, когда вы подключаетесь к неправильному серверу из-за опечатки. Например, в некоторый момент времени .cg был подстановочным знаком, указывающим на одну машину с включенным ssh. В любое время, когда вы ошиблись .cg для .ch, вы в конечном итоге подключитесь к этому ящику и пропустите свой пароль ... - b0fh


Это компромисс, как говорит @MartinVejmelka.

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

Пароль имеет следующие проблемы:

  • Если это коротко, это может быть грубо принудительно
  • Если долго это легко забыть
  • Это может быть плечо серфинга

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


5
2017-11-24 12:43



но с использованием ключевого файла добавляется проблема с потерей ручного накопителя или любого используемого вами хранилища. - João Portela
после чего потерянный ключ можно удалить и добавить новый ключ. С паролями (особенно разделяемыми паролями) это может я БОЛЬШАЯ боль, и вовлекает много стонов. - SplinterReality
Один из моих (недавно удаленных) паролей: 08Forging2?seminal*^Rajas-(Posed/|, Это беспорядочно сгенерировано, но мне не трудно его запомнить. И удача плечом-серфингом или грубой силой. - finnw
@finnw Правильная батарея штанов для лошадей :-) security.stackexchange.com/q/6095/485 - Rory Alsop


Клавиши ssh предотвращают попадание человека в атаки на основе вашего пароля.

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

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

с паролем они будут иметь ваши учетные данные.

Мое решение состоит в том, чтобы иметь переносимый ключ ssh в подходящих форматах в зашифрованном разделе на USB-ключ. это позволяет мне:
легко удалите этот ключ в случае его потери.
ограничить, какие серверы он позволяет мне получить доступ к
и все еще носить его вокруг

хотя установка программного обеспечения для установки - это боль (truecrypt)


5
2017-11-25 11:04



Это не верно. Как только вы узнаете открытый ключ сервера (что вы делаете, если вы добавили его в свой кеш и не получили MITM'd в первом соединении), вы невосприимчивы к атакам MITM. Аутентификация на основе ключа / пароля не имеет к этому никакого отношения. Пароль - никогда отправленный в ящике по проводам, безопасное соединение при аутентификации на уровне машины (что является вашим / моим открытым ключом) всегда настроено до аутентификации на уровне пользователя (что является вашим паролем / доказывает, что этот открытый ключ принадлежит вам). - Thomas
Томас, в действительности многие люди игнорируют предупреждение об изменении отпечатка пальца. Pubkey auth гарантирует защиту MITM, даже если частный ключ сервера каким-то образом скомпрометирован или человеческие типы «да» рассеянно: злоумышленник должен выбирать между тем, чтобы не видеть трафик и отправлять открытый ключ, который не войдет в систему, выиграть. - Score_Under
И к ответчику: вам не нужно использовать truecrypt, private ключи opensh поставляются со своим собственным дополнительным шифрованием на основе пароля. - Score_Under


Хорошие пункты, упомянутые здесь уже.

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

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


2
2017-11-24 19:28





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

Я нахожу лучший ответ за то, почему руководство пользователя часто рекомендует SSH по аутентификации паролем, из руководства Ubuntu для SSHOpenSSHKeys. Я цитирую,

Если вы не думаете, что это важно, попробуйте выполнить регистрацию всех попыток злоумышленного входа, которые вы получите в течение следующей недели. У моего компьютера - совершенно обычного настольного ПК - было более 4000 попыток угадать мой пароль и почти 2500 попыток взлома за последнюю неделю. Сколько тысяч случайных догадок вы думаете, что это произойдет до того, как злоумышленник наткнется на ваш пароль?

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


2
2017-11-24 23:48