☰

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

tag-icon • tag-icon security ssh authentication ssh-keys
Почему аутентификация по паролю SSH представляет угрозу безопасности?

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

решение1

Существуют свои плюсы и минусы аутентификации на основе пароля или ключа.

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

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

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

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

решение2

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

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

решение3

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

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

решение4

Ключи SSH предотвращают атаки типа «человек посередине» на ваш пароль.

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

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

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

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

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

Связанный контент