действительно ли безопасно обмениваться системным сервером ssh-ключи?
Вместо того, чтобы обмениваться ftp/sftp учетными данными по электронной почте это более безопасный к обмениваться системными ssh-ключами по электронной почте? Если бы у человека не было физического ssh частного файла, то хакер смог бы получить доступ к серверу, просто зная общедоступную ssh-строку-ключа?
Суть криптосистемы с открытым ключом заключается в том, что открытый ключ может быть опубликован повсюду без ущерба для безопасности системы. Итак, нет, если хакер может перехватить открытые ключи сервера, он не получит никакой выгоды при попытке получить доступ к системе.
Как уже упоминалось в ответе wombles, вы в безопасности, если злоумышленник перехватит ключ. Это цель асимметричной криптографии.
Но , если злоумышленник не только может перехватить ключ, но также может манипулировать вашим каналом связи, он может заменить отправленный открытый ключ своим собственным ключом и получить доступ к ваши системы. Обычно это называется проблемой аутентификации.
Если вы параноик и знаете голос человека, который отправляет вам ключ, вам также следует проверить отпечаток ключа на телефоне, поскольку голосовой связью гораздо труднее управлять, чем электронной почтой .
Да, совершенно безопасно поделиться открытым ключом сервера, который используется для идентификации сервера, и человек в средней защите. После того, как вы «приняли» открытый ключ, ваш клиент запомнит его и предупредит вас, если он изменится. (Что было бы в случае атаки Man-in-the-Middle.)
Обычно можно пойти дальше и опубликовать отпечаток ключа в 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:
Пароль Аутентификация нет
Это позволит подключаться только клиентам с закрытыми ключами, перечисленными в ~ / .ssh / authorized_keys. Да, вы все равно можете использовать пароли в командной строке sudo / su, это просто не позволит вам войти в систему с именем пользователя и паролем через SSH. Требуется закрытый ключ.
Я бы порекомендовал остановиться, установив правильную сеть точек конского аккумулятора, если у вас возникли проблемы с придумыванием хорошей кодовой фразы.
(И да, кодовая фраза может содержать пробелы, что-то вроде «Защита благородных сестер». могут быть легко запоминаемыми и по-прежнему иметь достаточно энтропии для достаточной защиты - см. комикс XKCD № 936 под названием «Надежность пароля».)
Когда с закрытым ключом связана парольная фраза, файл .ppk или id_rsa, который хранится у клиента, зашифрован . Общая идея заключается в том, что вы (администратор сервера) никогда не узнаете этот пароль / кодовую фразу, используемую для шифрования ключа клиента. Как только клиент разблокирует / расшифровывает ключ, чтобы представить его вам (серверу) в качестве математической задачи, аутентификация продолжается. Невозможно восстановить парольную фразу клиента с сервера вообще, когда-либо (если только они не настолько глупы, чтобы загрузить свой закрытый ключ - не делайте этого! Используйте пересылку агента SSH или ключевой агент putty pageant.exe в Windows .)