Влияет ли Heartbleed на ssh-ключи?
Влияет ли недавняя ошибка Heartbleed на ssh-ключи, которые я сгенерировал и использовал для отправки / извлечения кода с Github, Heroku и другими подобными сайтами?
Нужно ли заменить ключи, которые я использовал?
2 ответа
Нет, Heartbleed на самом деле не влияет на ключи SSH, поэтому вам, вероятно, не нужно заменять используемые вами ключи SSH.
Во-первых, SSL и SSH - это два разных протокола безопасности для двух разных применений. Аналогично, OpenSSL и OpenSSH также являются двумя совершенно разными программными пакетами, несмотря на сходство их названий.
Во-вторых, эксплойт Heartbleed приводит к тому, что уязвимый узел TLS/DTLS OpenSSL возвращает случайные 64 КБ памяти, но он почти наверняка ограничен памятью, доступной этому процессу, использующему OpenSSL. Если этот процесс, использующий OpenSSL, не имеет доступа к вашему секретному ключу SSH, он не может утечь его через Heartbleed.
Кроме того, вы обычно размещаете свой открытый ключ SSH только на серверах, к которым вы используете SSH, и, как следует из названия, открытый ключ - это ключ, который вы можете опубликовать. Неважно, кто это знает. Фактически, вы хотите, чтобы публичный пользователь знал ваш правильный открытый ключ.
Спасибо @Bob за указание на то, что уязвимость может повлиять на клиентские приложения, которые используют уязвимые версии OpenSSL в качестве своей клиентской библиотеки TLS/DTLS. Так, например, если ваш веб-браузер или VPN-клиент на основе SSL использовали уязвимую версию OpenSSL и подключены к вредоносному серверу, этот вредоносный сервер может использовать Heartbleed для просмотра случайных фрагментов памяти этого клиентского программного обеспечения. Если у этого клиентского приложения по какой-то причине была копия ваших закрытых ключей SSH в памяти, оно могло бы просочиться через Heartbleed.
Сверх того, я не думаю ни о каком программном обеспечении, кроме SSH, которое могло бы иметь копию вашего незашифрованного закрытого ключа SSH в памяти. Что ж, это предполагает, что вы храните свои SSH-ключи в зашифрованном виде на диске. Если вы не храните свои закрытые SSH-ключи в зашифрованном виде на диске, то я полагаю, что вы могли бы использовать некоторую программу передачи файлов или резервного копирования с использованием TLS с использованием OpenSSL для копирования или резервного копирования вашего домашнего каталога по сети (включая ваш ~/.ssh/id_rsa или другой закрытый ключ SSH), тогда он может иметь незашифрованную копию вашего закрытого ключа SSH в памяти. Опять же, если вы резервировали свой незашифрованный закрытый ключ SSH на вредоносный сервер, у вас, вероятно, больше забот, чем у Heartbleed.:-)
"Во-вторых, эксплойт Heartbleed приводит к тому, что уязвимый узел TLS/DTLS OpenSSL возвращает случайные 64 КБ памяти, но он почти наверняка ограничен памятью, доступной этому процессу, использующему OpenSSL".
если машина скомпрометирована, то как вы можете доверять чему-либо на ней, включая ssh? от heartbleed.com
"Что протекает на практике?
Мы проверили некоторые из наших собственных сервисов с точки зрения злоумышленника. Мы напали на себя извне, не оставив следа. Без использования какой-либо конфиденциальной информации или учетных данных мы смогли украсть у себя секретные ключи, используемые для наших сертификатов X.509, имен пользователей и паролей, мгновенных сообщений, электронных писем и важных для бизнеса документов и коммуникаций. "
кто-то мог положить закрытый ключ без ключевой фразы на сервер, который, как он предполагал, не был вредоносным... но оказался. Ошибка b / c SSL позволила выдать пароль пользователя, который имел "sudo"... это, вероятно, не проблема.... но...
люди иногда делают сумасшедшие вещи
http://blog.visionsource.org/2010/08/28/mining-passwords-from-public-github-repositories/