Публикация id_rsa.pub для более легкой настройки новых сред?

20

Чтобы упростить настройку SSH без пароля на новых машинах и в других средах, есть ли причина, по которой id_rsa.pubфайл (только открытая половина пары ключей) не может быть опубликован где-то в Интернете? Например, в репозитории dotfiles GitHub.

Я знаю, что:

id_rsaфайл (частная половина пары ключа) должен быть тщательно охраняется и
пара ключей должна быть защищена парольной фразой

Но мои поиски не дали никаких явных советов о том, что это разрешено или поощряется.

Из любопытства, будет ли такой же совет для пары ключей без ключевой фразы?

— DouglasDD
источник

2

Хотя это может быть безопасно в общем случае (при условии правильно сгенерированного ключа), в прошлом существовали недостатки (известная ошибка Debian OpenSSH ), которые строго ограничивали пространство ключей и оставляли частный ключ угадываемым на основе открытого ключа. Так что всегда есть такой риск - как вы узнаете, что ваш SSH keygen не страдает от подобного недостатка?

— Боб

2

Один механизм для этого уже существует: ssh-import-id

— MikeyB

так вы можете поделиться id_rsa.pub между машинами?

— Федерико

26

RSA специально разработан для того, чтобы вы могли поделиться этим открытым ключом, так что да, вы можете опубликовать его. Это очень похоже на то, как работает x.509 (и SSL) с сертификатами RSA.

Прежде чем публиковать файл, посмотрите на него; единственные вещи, которые должны быть там - это ключевое слово «ssh-rsa» и ключ в кодировке base64. Возможно, вы захотите сохранить это (я считаю, что это по умолчанию сейчас).

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

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

Я предлагаю использовать 4096-битный ключ (указать -b 4096), чтобы кому-то было труднее, чем обычно (по умолчанию 2048), кто-то инвертировать ваш открытый ключ в закрытый. Это единственный значительный риск при этом, и он не очень большой, поскольку алгоритм специально разработан, чтобы сделать его непрактичным.

— Сокол Момот
источник

33

Это уже есть. :) Просто поместите ".keys" в конце URL вашего профиля на Github, вот так:

https://github.com/tjmcewan.keys

— tjmcewan
источник

Тан действительно интересный. Для чего GitHub предоставляет это?

— Ричардниш

Удобство. :) В конце концов, это открытый ключ - он предназначен для совместного использования. Теперь гораздо проще получить ключ нового соавтора и добавить его на свои серверы. Сохраняет туда и обратно электронную почту.

— tjmcewan

Я не осознавал, что они это сделали.

— Зеб

1

+1 за интересную находку на Github.

— Раймонд Тау

5

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

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

Существует угловой случай атаки, который, вероятно, не применяется, но если вы вспомните фиаско с Debian, случайно нарушившим PRNG openssl , любой ключ ssh, сгенерированный в уязвимой системе, легко предсказуем и может быть идентифицирован по его открытому ключу. Так что в этом случае публикация открытого ключа может привести к неприятностям. Или, более уместно, использование этого ключа для чего-либо может привести к неприятностям.

— tylerl
источник

вектор 1. как насчет столкновения отпечатков пальцев? он намного короче самого открытого ключа; Vector 2 MIM-атака типа «Ой, сервер должен был быть переустановлен, у него другой ключ, но все равно, пожалуйста, войдите в систему» и подделайте успешную аутентификацию для заданных открытых ключей пользователя (если это возможно, я не уверен)

1

Да, вы можете опубликовать свой SSH pubkey. И вы можете опубликовать отпечаток сервера, используя запись SSHFP в DNS! Это может быть очень удобно, например, если вам нужно обновить / изменить SSH-ключ сервера.

— jldugger
источник