Влияет ли недавняя ошибка Heartbleed на ssh-ключи, которые я сгенерировал и использовал для отправки / извлечения кода с Github, Heroku и другими подобными сайтами?
Нужно ли заменить ключи, которые я использовал?
Влияет ли недавняя ошибка Heartbleed на ssh-ключи, которые я сгенерировал и использовал для отправки / извлечения кода с Github, Heroku и другими подобными сайтами?
Нужно ли заменить ключи, которые я использовал?
Ответы:
Нет, 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-ключи в зашифрованном виде на диске, то, я полагаю, вы могли бы использовать некоторую программу передачи файлов или резервного копирования OpenSSL с использованием TLS для копирования или резервного копирования вашего домашнего каталога по сети (включая ваш ~/.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/