Большинство руководств по настройке OpenSSH советуют отключить аутентификацию по паролю в пользу аутентификации на основе ключей. Но, на мой взгляд, у аутентификации по паролю есть существенное преимущество: возможность подключиться из любого места без ключа. Если используется всегда с надежным паролем, это не должно представлять угрозы для безопасности. Или надо?
Использование ключей 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
Есть плюсы и минусы для аутентификации на основе pw или ключа.
В некоторых случаях, например, аутентификация на основе ключей Меньше безопаснее, чем аутентификация по паролю. В других случаях это менее безопасно на основе pw. В одних случаях один удобнее, в других - меньше.
Все сводится к следующему: когда вы выполняете аутентификацию на основе ключей, вы должен защитите свой ключ парольной фразой. Если у вас не запущен ssh-agent (ssh-agent освобождает вас от необходимости каждый раз вводить кодовую фразу), вы ничего не добьетесь с точки зрения удобства. Безопасность спорна: вектор атаки теперь сместился с сервера на ВАС, или на вашу учетную запись, или на вашу личную машину, (...) - их может быть или нет легче взломать.
Принимая это решение, подумайте нестандартно. Получите вы или проиграете с точки зрения безопасности, зависит от остальной среды и других мер.
edit: О, только что увидел, что вы говорите о домашнем сервере. Я был в одной и той же ситуации, «пароль» или «USB-накопитель с ключом» всегда со мной? Я пошел за бывшим но изменил порт прослушивания SSH на какой-то другой, чем 22. Это останавливает всех этих неуклюжих скриптовых детишек, перебирающих целые сетевые диапазоны.
Вы частично ответили на свой вопрос - чем больше мест, откуда злоумышленник может подключиться, тем больше у него возможностей взломать ваш сервер с помощью брутфорса (рассмотрите DDoS).
Также сравните длину вашего пароля с размером ключа (обычно тысячи бит).
Когда вы входите в систему с паролем, вы передаете свой пароль на сервер. Это означает, что оператор сервера может изменить SSHD, чтобы получить доступ к вашему паролю. При аутентификации с открытым ключом они не могут получить ваш закрытый ключ, так как на сервер отправляется только ваш открытый ключ.
ssh-ключи предотвращают атаки человека посередине на ваш пароль.
когда вы пытаетесь войти в систему с помощью ключа, сервер создает запрос на основе вашего открытого ключа и отправляет его вашему клиенту. который расшифрует его и создаст соответствующий ответ для отправки.
Ваш закрытый ключ никогда не отправляется на сервер, и любой, кто его слушает, не может ничего сделать, кроме как перехватить этот единственный сеанс.
с паролем у них будут ваши учетные данные.
Мое решение - иметь переносной ssh-ключ в подходящих форматах на зашифрованном разделе на usb-ключе. это позволяет мне:
легко вытащите этот ключ в случае его утери.
ограничить, к каким серверам он разрешает мне доступ
и все еще носить его с собой
хотя установка программного обеспечения для монтирования - это боль (truecrypt)
Как говорит @MartinVejmelka, это компромисс.
Причина, по которой вы используете аутентификацию на основе ключа, заключается в том, что ключ намного превышает текущий или в ближайшем будущем брутфорс, который вам нужно либо исходить со своего ПК, либо иметь ключ на USB-накопителе или что-то подобное.
С паролем возникают следующие проблемы:
Ключ на несколько порядков длиннее и не отображается в любой момент, поэтому он позволяет избежать этих трех проблем.
Здесь уже упоминались хорошие моменты.
Что я считаю самым большим риском, учитывая, что вы позаботились об основах с помощью надежного пароля, это то, что на многих компьютерах установлены клавиатурные шпионы без ведома пользователя. Есть даже люди, которые создают целые сайты полезных утилит, содержащих трояны, так что это может случиться с лучшими из нас. Кейлоггер, например, отправит данные для входа хакеру по электронной почте, который затем легко сможет получить доступ к серверу.
Недавно Norton предупредил меня о загрузке установщика Zombee Mod (не jar, а установщика) для добавления полета в jar-файл Minecraft. Я изучил детали, и Нортон перечислил на этом сайте множество утилит, которые были помечены как содержащие троян. Я не знаю, правильно это или нет, но это было довольно специфично с именами файлов. Также известно, что трояны помещаются в (некоторые) варезы перед распространением.
Одно из потенциальных преимуществ SSH над паролями состоит в том, что если вы не укажете парольную фразу SSH, вам больше не придется вводить пароль ... вашему компьютеру внутренне доверяют на сервере, потому что у него есть ключ. Тем не менее, я обычно всегда использую парольную фразу SSH, поэтому я исключаю это преимущество.
Я считаю, что лучший ответ на вопрос, почему руководства пользователя часто рекомендуют SSH вместо аутентификации по паролю, можно найти в руководстве Ubuntu для SSHOpenSSHKeys. Я цитирую,
Если вы не думаете, что это важно, попробуйте регистрировать все злонамеренные попытки входа в систему на следующей неделе. На моем компьютере - совершенно обычном настольном ПК - было более 4000 попыток подобрать мой пароль и почти 2500 попыток взлома только за последнюю неделю. Как вы думаете, сколько тысяч случайных попыток угадают, прежде чем злоумышленник найдет ваш пароль?
По сути, если у вас есть надежный, длинный пароль с пунктуацией, прописными и строчными буквами и цифрами ... вы, вероятно, будете в порядке с аутентификацией по паролю. Также, если вы планируете следить за своими журналами и в любом случае не делаете «супербезопасных» вещей в сети ... то есть используете их для домашнего сервера. Тогда, конечно, пароль работает.
Метод аутентификации Passwd действительно небезопасен (имхо). С помощью этого механизма пароль будет передан на сервер sshd (как уже сказал @ramon). Это означает, что некоторые люди могут модифицировать сервер sshd для получения пароля. С помощью атаки Man-In-The-Middle это очень легко сделать в локальной сети.
Вы можете просто пропатчить 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