Нужно ли заменять ключи для OpenSSH в ответ на Heartbleed?


9

Я уже обновил свои серверы патчами.

Нужно ли восстанавливать какие-либо закрытые ключи в отношении OpenSSH? Я знаю, что я должен восстановить любые сертификаты SSL.

РЕДАКТИРОВАТЬ: Я не сказал это достаточно точно. Я знаю, что уязвимость в openssl, но я спрашивал, как это влияет на openssh и нужно ли мне заново генерировать ключи хоста openssh.


1
На самом деле это, вероятно, дубликат serverfault.com/questions/587329/...
обманщик

Ваш первый и третий абзацы кажутся противоречивыми.
CVn

@ faker Не совсем - этот вопрос ничего не говорит о SSH ...
voretaq7

Связанный вопрос: serverfault.com/questions/587433/...
voretaq7

Ответы:


5

Уязвимость не влияет, opensshа влияет openssl.
Какая библиотека используется многими сервисами - в том числе openssh.

На данный момент кажется очевидным, что opensshэта уязвимость не затронута, поскольку OpenSSH использует протокол SSH, а не уязвимый протокол TLS. Маловероятно, что ваш закрытый ключ ssh находится в памяти и может быть прочитан уязвимым процессом - не невозможно, но маловероятно.

Конечно, вы все равно должны обновить свою opensslверсию.
Обратите внимание, что если вы обновили, opensslвам также необходимо перезапустить все сервисы, которые его используют.
Это включает в себя программное обеспечение, как VPN-сервер, веб-сервер, почтовый сервер, балансировщик нагрузки, ...


1
Что следует иметь в виду: можно использовать одну и ту же часть закрытого ключа для закрытого ключа SSH и сертификата SSL. В этом случае, если ключ SSL-сертификата был использован на уязвимом веб-сервере, вам также необходимо заменить уязвимый SSH-ключ. (Чтобы это можно было использовать, кому-то нужно знать, что вы делаете это, или подумать над тем, чтобы попробовать - это ОЧЕНЬ необычная конфигурация в моем опыте, поэтому я сомневаюсь, что кто-нибудь подумает об этом). Все, что говорит, что нет ничего плохого в том, чтобы восстановить ваши SSH Private Key (s), если вы хотите - небольшая паранойя не плохая вещь :-)
voretaq7

2

Таким образом, кажется, что SSH не затронут:

Как правило, это затрагивает вас, если вы запускаете какой-либо сервер, на котором в какой-то момент вы сгенерировали ключ SSL. На типичных конечных пользователей это не влияет (напрямую). SSH не затрагивается. Распространение пакетов Ubuntu не затронуто (оно опирается на подписи GPG).

Источник: спросите Ubuntu: Как установить исправление CVE-2014-0160 в OpenSSL?


1

В отличие от того, что здесь говорили другие, Шнайер говорит, что да.

По сути, злоумышленник может получить 64 КБ памяти с сервера. Атака не оставляет следов и может быть проведена несколько раз, чтобы захватить другую случайную 64 КБ памяти. Это означает, что что-либо в памяти - закрытые ключи SSL, пользовательские ключи, что угодно - уязвимо. И вы должны предположить, что все это скомпрометировано. Все это.

Дело не в том, что ssh (любой тип) был напрямую затронут, а в том, что ключи ssh могут быть сохранены в памяти, и к памяти можно получить доступ. Это касается всего, что хранится в памяти, и считается секретным.


Кажется, он дает очень общий обзор проблемы с этим предложением. Это первый раз , когда я слышу , что все все ваша память была разоблачена. До сих пор я понимаю, что только память, к которой имеет доступ уязвимый процесс. См. Также: security.stackexchange.com/questions/55076/…
мошенник

0

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

Так что если вы / должны быть немного параноиком, замените их, если нет, вы можете спать относительно хорошо без этого.


SSH не использует OpenSSL. Большая разница там.
Джейкоб

2
OpenSSH использует часть libcrypto OpenSSL. Вот почему вы должны перезапустить SSH после обновления OpenSSL. Вот почему некоторые люди спрашивают, должны ли они заменить свои SSH-ключи. Смотри мой ответ выше ... Так в чем твоя точка зрения?
Денис Витт
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.