Сегодня я работал с партнером, которому нужно было загрузить файлы на мой сервер, используя scp. У меня пароли отключены в конфигурации SSH сервера, поэтому я хотел, чтобы они использовали аутентификацию с открытым ключом. Я сгенерировал для них пару ключей на сервере, дал им закрытый ключ и поместил открытый ключ в соответствующий authorized_keys файл.
После кучи проблем с их настройкой работы, они наконец-то привлекли более опытного системного администратора, и он отругал меня за такое обращение с генерацией ключей. Он сказал, что, дав им закрытый ключ, сгенерированный в моей системе, я позволил им провести атаку методом перебора других ключей, сгенерированных на том же сервере.
Я даже спросил его "Итак, если у меня есть учетная запись на сервере, и я могу войти в систему с паролем, но я хочу что-то автоматизировать, и я создаю пару ключей в этой системе, дает ли это мне вектор атаки для грубого взлома ключей других пользователей? " и сказал он да.
Я никогда об этом не слышал, правда? Может ли кто-нибудь указать мне на обсуждение этой атаки?
Ну ... нет, в подавляющем большинстве случаев это неверно из-за правильной генерации случайности в системе. Однако сервер теоретически может генерировать случайность, имеющую предвзятость, если разработчики (в случае Linux - разработчики ядра) не позаботятся о том, чтобы источник случайности был «хорошим». Если есть систематическая ошибка в случайности, атака может быть выполнена быстрее, чем грубая сила по ключам сервера. Однако это гораздо больше теоретическая проблема, чем реальная - на практике слабость в ГСЧ (Генераторе случайных чисел) является гораздо менее вероятной атакой, чем атака по побочному каналу на криптографическое программное обеспечение или получение доступа к серверу. по-разному.
Короче говоря, нет, он неправ. За исключением фундаментальных криптографических основ (генерируются ли ключи DSA по умолчанию? RSA?), Один ключ ssh не содержит никакой информации о любом другом ключе ssh, сгенерированном в той же системе.
Суть закрытого ключа заключается в том, что он является личным для пользователя и известен только ему. Как пользователь я бы не хотел, чтобы другие люди генерировали мой закрытый ключ, потому что это означает, что кто-то другой имеет доступ к моему закрытому ключу и, следовательно, имеет возможность действовать, если это я в системах, в которых публичная половина этого ключа установлена как действительные учетные данные.
Со стороны вашего PoV у вас тоже больше ответственности. Вам нужно не только обеспечить безопасность вашей системы, чтобы неподходящие открытые ключи нельзя было установить в места, но вы также несете ответственность за обеспечение безопасности генерируемых вами закрытых ключей на протяжении всего их жизненного цикла. Если с данной парой ключей в качестве аутентификации было предпринято нежелательное действие, и пользователь знает, что у кого-то была (или была) копия ключа, или если ключ был доставлен не совсем безопасным способом, то они могут развернуться (правильно или ошибочно) и говорят, что они сохранили свою копию в полной безопасности, поэтому это должна быть ваша копия, которая была взломана либо на вашей стороне, либо в пути. Это может показаться просто прикрытием задницы, и это потому, что это так: как от вашего PoV, так и от пользователей, поскольку вы проверяете, кто несет ответственность за то, что правильно отмечено.
Итак, обоснованы ли опасения, высказанные вашим экспертом, или нет (насколько я понимаю, такие атаки теоретически возможны, но, насколько мне известно, далеко из практически реализуемого в следующем поколении или несколько, если не будет обнаружена новая серьезная дыра в математике или общей реализации (что несколько маловероятно)), как в моей шляпе пользователя, так и в шляпе администратора, я предпочитаю, чтобы пользователи полностью контролировали их закрытых ключей и администраторов (конечно, вместе со всеми остальными на планете), чтобы их нельзя было подпускать к ним.
Даже если вы не согласны с вышеизложенным, проблема с переносом ключа далеко не тривиальна: как вы можете быть на 100% уверены, что закрытый ключ был увиден предполагаемым пользователем и только предполагаемый пользователь и не был сохранен (намеренно или случайно) небезопасным способом (например, оставлен в почтовом ящике электронной почты или во временном файле, который возник в результате того, что он был отключен от указанной почты и не был зашифрован). Если вы используете безопасный транспортный метод, который требует аутентификации пользователя, как получить данные аутентификации для который систему пользователю безопасно? Конечно, есть способы сделать ключевой транспортный вопрос «достаточно безопасным» (где «достаточно» очень сильно зависит от того, к чему ключи предоставляют людям доступ) для большинства применений, но если пользователь генерирует свои ключи и распространяет общедоступные части, тогда вы у вас вообще нет проблемы с распределением ключей, о которой нужно беспокоиться в этом смысле (вам просто нужно беспокоиться о том, что пользователи сохранят личные части в безопасности, но нет ничего, что могло бы помешать действительно неосторожному пользователю быть небезопасным, так что это проблема не важно, что ты предпримешь).
И последнее замечание: одна вещь, которая может быть проблемой, если все ваши закрытые ключи сгенерированы в одном и том же месте, - это то, что в этом месте позже будет обнаружена неправильная настройка генерации ключей, как проблема, обнаруженная в пакете OpenSSL Debian / Lenny в прошлом году. . В таком случае вам придется отозвать и восстановить множество закрытых ключей. Это может быть частью беспокойства вашего внешнего эксперта по данному вопросу.
Я почти уверен, что это чушь. Приват должен генерироваться случайным образом. Итак, пока в этой случайности нет предвзятости, не может быть связи между разными закрытыми ключами.
Случайное семя обычно происходит от / dev / случайный. Если вы каким-либо образом не изменили ssh-keygen для использования другого случайного начального числа (вы бы знали, если бы вы это сделали), маловероятно, что кто-то сможет взломать этот ключ, чтобы выяснить, как сгенерировать новый ключ для взлома вашего система.