Вместо обмена учетными данными ftp / sftp по электронной почте, безопаснее ли обмениваться системными ssh-ключами по электронной почте? Если бы у человека не было физического приватного файла ssh, смог бы хакер получить доступ к серверу, просто зная строку публичного ssh-ключа?
Суть криптосистемы с открытым ключом заключается в том, что открытый ключ может быть опубликован повсюду без ущерба для безопасности системы. Итак, нет, если хакер может перехватить открытые ключи сервера, он не получит никакой выгоды от попытки получить доступ к системе.
Как уже упоминалось в ответе wombles, вы в безопасности, если злоумышленник перехватит ключ. В этом цель асимметричной криптографии.
Но если злоумышленник не только может перехватить ключ, но и манипулировать вашим каналом связи, он может заменить отправленный открытый ключ своим собственным и получить доступ к вашим системам. Обычно это называется проблемой аутентификации.
Если вы параноик и знаете голос человека, который отправляет вам ключ, вам также следует проверить отпечаток ключа на телефоне, поскольку голосовой связью гораздо сложнее манипулировать, чем электронной почтой.
Да, совершенно безопасно делиться открытым ключом сервера, который используется для идентификации сервера, и человеком в средней защите. После того, как вы «приняли» открытый ключ, ваш клиент запомнит его и предупредит вас, если он изменится. (Что было бы в случае атаки «Человек посередине».)
Обычно можно пойти дальше и опубликовать отпечаток ключа в DNS, согласно rfc4255: http://www.ietf.org/rfc/rfc4255.txt
Это позволяет клиенту получить отпечаток ключа перед фактическим подключением к демону ssh для получения открытого ключа через порт 22.
Если отпечаток пальца совпадает с открытым ключом, предоставленным сервером; соединение будет продолжено.
Вот несколько основных инструкций по обеспечению этого. https://simon.butcher.name/archives/2011/01/16/SSH-key-fingerprints-in-DNS
Что касается закрытых ключей, сгенерированных вами или вашим клиентом, они должны храниться в абсолютном секрете и храниться с надежной парольной фразой.
В общем, я бы рекомендовал отключить пароли через SSH с помощью параметра / etc / ssh / sshd_config:
PasswordAuthentication no
Это позволит подключаться только клиентам с закрытыми ключами, перечисленными в ~ / .ssh / authorized_keys. Да, вы все равно можете использовать пароли в командной строке sudo / su, это просто не позволит вам войти в систему с именем пользователя и паролем через SSH. Требуется закрытый ключ.
Я бы порекомендовал остановиться, установив правильную сетку с точками для лошадиных аккумуляторов, если у вас возникли проблемы с приданием правильной кодовой фразы.
(И да, фраза-пароль может содержать пробелы, что-то вроде «Защита благородных сестер» можно легко запомнить и при этом нести достаточно энтропии для достаточной защиты - см. Комикс XKCD № 936 под названием «Надежность пароля».)
Когда с закрытым ключом связана парольная фраза, файл .ppk или id_rsa, который хранится у клиента, зашифрован. Общая идея заключается в том, что вы (администратор сервера) никогда не узнаете этот пароль / кодовую фразу, используемую для шифрования ключа клиента. Как только клиент разблокирует / расшифровывает ключ, чтобы представить его вам (серверу) в качестве математической задачи, аутентификация продолжается. Невозможно восстановить парольную фразу клиента с сервера вообще, когда-либо (если только они не настолько глупы, чтобы загрузить свой закрытый ключ - не делайте этого! Используйте пересылку агента SSH или ключевой агент putty pageant.exe в Windows .)