Безопасно ли расшаривать id_rsa.pub для всех?

в сторожке скучно, да?

да. :(

безопасно ли размещать его на каком-нибудь github

Более чем безопасно.

тогда вот тебе краткий ответ на твой вопрос:

публичный ключ давай ограниченному и доверенному кругу лиц
приватный - НИКОМУ

Почему пятикопеечная монета в левую ноздрю влезает, а в правую нет? :(

по той же причине, почему мой правый глаз видет хуже, чем левый

Когда придется работу искать?) и какую?

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

нахрена тогда вообще асимметричное шифрование нужно?

ЕМНИП, именно публичный-то и нужно как можно больше распространять.

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

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

Вот это охеренная идея! Спасибо.

Не только хост-ключи, я ещё сделаю, чтобы клиентские ключи автоматически перегенерировались после каждого соединения.

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

А смысл?

Чтобы нельзя было узнать почему ssh ругается на смену отпечатка — из-за человека-посередине или из-за записи крона.

публикация и показ ключей - это оговоренная и штатная процедура.

ЕМНИП для их верификации есть специальные команды и хранят ключи на специальных серверах.

Пример: ключи (хэши) исошников и архивов.

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

нда уж.

хостовые ключи перегенерировались каждый раз при запуске сервера.

Это идиотизм. Или ты предлагаешь после каждого ребута сообщать всем новый отпечаток и просить выпилить старый из authorized_hosts?

клиентские ключи автоматически перегенерировались после каждого соединения.

wat? На кой хрен? И после каждого соединения править на сервере known_hosts?

если скомпроментируют один

Если скомпрометируют один, то скорее всего скомпрометируют и все остальные. ИМХО, польза в наличии нескольких ключей исчезающе мала.

безопасно ли размещать его на каком-нибудь github, аки dotfiles, на доступ всем?

Ясен хрен, безопасно. Это как бы идея асимметричного шифрования.

ЕМНИП, именно публичный-то и нужно как можно больше распространять.

s/нужно/можно/
Никакой потребности в «больше распространять», по крайней мере в случае с ssh, нет.
Но, таки-да, слово «публичный» в термине «публичный ключ» таки намекает.

Вроде-бы ssh сервер и так отдаёт свои публичные ключи всем желающим.

Пример: ключи (хэши) исошников и архивов.

Публичные ключи из асимметричного шифрования не имеют ничего общего с криптохэшами.

В общем-то да, но с отдельными ключами как-то аккуратнее.

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

Ключи (что клиентские, что хостовые) используются только для аутентификации. Их компрометация делает возможным man-in-the-middle (злоумышленник, врезавшийся в соединение и обладающий чьим-нибудь приватным ключом, может выдать себя за того, чьим приватным ключом обладает), но не делает возможным пассивный перехват.

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

безопасно ли размещать его на каком-нибудь github, аки dotfiles, на доступ всем?

Публичный ключ на то и публичный, что ты его можешь хоть себе на лбу написать.

угу, отдает
но это не повод их кидать налево-направо помимо этого

публичный ключ давай ограниченному и доверенному кругу лиц

С чего такая избирательность? Публичный ключ на то и публичный.

Нет причин дополнительно запариваться распространением публичных ключей. нет причин заприваться их не-распространением.

И как сия конструкция символизирует свящь между публичными ключами и криптографическими хэшами?

Ну вот уже второй раз на ЛОРе мне дают понять, что мои собственные представления о работе криптосистем на самом деле являются заблуждениями.
А вот не понимаю, почему нельзя создать криптосистему в которой не только аутентификация, но и сама передача данных будут идти по ассиметричному алгоритму? Зачем нужны сеансовые ключи? Ведь если хакер найдёт способ похитить сеансовый ключ из оперативной памяти клиента - он сможет расшифровать весь сеанс связи, а вот если бы передача данных шла по ассиметричному алгоритму - то такое бы не прокатило.

security by obscurity лишним не будет, при условии что всё остальное в порядке.

Привычка выставлять напоказ все что можно выставить ни к чему хорошему не приведет.

Т.е. конструкция осуществляющая поиск по открытой базе публичных ключей не имеет ничего общего с публичными ключами? Оок.

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

почему нельзя

Можно. Однако симметричное шифрование намного быстрее асимметричного. Подобный подход же позволяет получить преимущества обоих.

похитить сеансовый ключ из оперативной памяти клиента

Есть мнение, что если компрометирована оперативная память, все уже плохо.

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

А если хакер найдёт способ залезть в оперативную память клиента, то дальше что-то делать в принципе бессмысленно.

Короче, аноним успел быстрее меня.

если хакер найдёт способ похитить сеансовый ключ из оперативной памяти клиента

Кстати, есть способы залить ключ в процессор и оттуда его уже хрен достанешь, даже если применять https://ru.wikipedia.org/wiki/Cold_boot_attack .

Ты зачем удалил ключ из гитхаба? Я хотел тут его запостить, типа я m3g4hack5r и такой-то облом... :(

так никто не делает, потому что это (очень) медленно и увеличивает объём данных

На сколько я понимаю асимметричная криптография всё-таки применяется для шифрования, но относительно редко. Например PGP/MIME и S/MIME шифруют почту без симметричного шифрования. Скорость и вес там не особо важны.
Хотя конечно шифровать так трафик — занятие для знатоков извращений.

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

Насколько поразительно бессмысленная идея

На сколько я понимаю асимметричная криптография всё-таки применяется для шифрования, но относительно редко. Например PGP/MIME и S/MIME шифруют почту без симметричного шифрования. Скорость и вес там не особо важны. Хотя конечно шифровать так трафик — занятие для знатоков извращений.

Когда твои наивные заблуждения развеиваются таким образом - это навевает на размышления. Когда вы в учебнике прочитали о том как Алиса передаёт Бобу шифрованное послание вы тоже наверняка подумали, что технология придумана именно для процесса шифрования трафика, а не процесса аутентификации? Так значит трафик шифруется сеансовым ключем? Вот я несколько месяцев назад создавал тему, может кто помнит? А вопрос оказывается был правильный. Зачем хранить файл с параметрами Диффи-Хеллмана, используемый для генерации сеансового ключа на диске, да ещё и никогда не перегенерировать его, если только это не лазейка для «большого брата»?

Когда вы в учебнике прочитали о том как Алиса передаёт Бобу шифрованное послание вы тоже наверняка подумали, что технология придумана именно для процесса шифрования трафика, а не процесса аутентификации?

Нет, я подумал что речь о письме или чём-то похожем (не забывай когда все эти RSA создавались).
Трафик, хоть он и состоит из набора посланий (пакетов), зачастую удобнее рассматривать как поток.
По началу какое-то время были иллюзии что асимметричное шифрование можно использовать напрямую повсеместно, но они быстро прошли.

Я вам написал ответ в той теме, прочитайте.