Czy muszę wymienić klucze dla OpenSSH w odpowiedzi na Heartbleed?


9

Zaktualizowałem już swoje serwery za pomocą łatek.

Czy muszę ponownie wygenerować klucze prywatne w odniesieniu do OpenSSH? Wiem, że muszę zregenerować wszelkie certyfikaty SSL.

EDYCJA: Nie napisałem tego wystarczająco dokładnie. Wiem, że ta luka występuje w openssl, ale pytałem, jak to wpływa na openssh i czy muszę ponownie wygenerować klucze hosta openssh.


1
W rzeczywistości jest to prawdopodobnie duplikat serverfault.com/questions/587329/…
faker

Twój pierwszy i trzeci akapit wydają się sprzeczne.
CVn

@faker Niezupełnie - to pytanie nie dotyczy niczego na temat SSH ...
voretaq7

Odpowiedzi:


5

Luka nie wpływa na opensshnią wpływa openssl.
Która jest biblioteką używaną przez wiele usług - w tym openssh.

W tej chwili wydaje się jasne, że opensshta luka nie dotyczy, ponieważ OpenSSH korzysta z protokołu SSH, a nie z podatnego na atak protokołu TLS. Jest mało prawdopodobne, że Twój prywatny klucz ssh jest w pamięci i może być odczytany przez wrażliwy proces - nie jest to niemożliwe, ale mało prawdopodobne.

Oczywiście nadal musisz zaktualizować swoją opensslwersję.
Pamiętaj, że jeśli zaktualizowałeś, opensslmusisz także ponownie uruchomić wszystkie usługi, które z niego korzystają.
Obejmuje to oprogramowanie takie jak serwer VPN, serwer WWW, serwer poczty, moduł równoważenia obciążenia, ...


1
Należy pamiętać: można użyć tej samej części klucza prywatnego dla klucza prywatnego SSH i certyfikatu SSL. W takim przypadku, jeśli klucz certyfikatu SSL został użyty na podatnym serwerze WWW, należy również wymienić klucz prywatny SSH, którego dotyczy problem. (Aby to wykorzystać, ktoś musiałby wiedzieć, że to robisz, lub pomyśleć, aby spróbować - jest to BARDZO nietypowa konfiguracja z mojego doświadczenia, więc wątpię, by ktoś o tym pomyślał). Wszystko to mówiło, że nie ma nic złego w regeneracji kluczy prywatnych SSH, jeśli chcesz - mała paranoja nie jest złą rzeczą :-)
voretaq7

2

Wygląda więc na to, że SSH pozostaje nienaruszony:

Zasadniczo masz wpływ, jeśli uruchomisz jakiś serwer, na którym w pewnym momencie wygenerowałeś klucz SSL. Typowi użytkownicy końcowi nie są dotknięci (bezpośrednio). SSH nie ma wpływu. Nie ma to wpływu na dystrybucję pakietów Ubuntu (opiera się na sygnaturach GPG).

Źródło: ask ubuntu: Jak załatać CVE-2014-0160 w OpenSSL?


1

W odróżnieniu od tego, co powiedzieli tu inni, Schneier mówi tak.

Zasadniczo atakujący może pobrać 64 KB pamięci z serwera. Atak nie pozostawia śladu i można go wykonać wiele razy, aby pobrać inną losową 64K pamięci. Oznacza to, że wszystko w pamięci - klucze prywatne SSL, klucze użytkownika, cokolwiek - jest zagrożone. I musisz założyć, że wszystko jest zagrożone. Wszystko.

Nie dotyczy to bezpośrednio ssh (dowolnego typu), ale klucze ssh mogą być przechowywane w pamięci i można uzyskać do niej dostęp. Odnosi się to do wszystkiego innego, co jest przechowywane w pamięci, co jest uważane za tajne.


Wydaje się, że daje bardzo ogólny przegląd problemu tego zdania. Po raz pierwszy słyszę, że wszystko wszystkim pamięć została odsłonięta. Jak dotąd rozumiem, że narażona jest tylko pamięć, do której ma dostęp wrażliwy proces. Zobacz także: security.stackexchange.com/questions/55076/…
faker

0

OpenSSH nie używa rozszerzenia pulsu, więc nie ma to wpływu na OpenSSH. Twoje klucze powinny być bezpieczne, o ile żaden proces OpenSSL wykorzystujący bicie serca nie miał ich w pamięci, ale zwykle jest to bardzo mało prawdopodobne.

Więc jeśli jesteś / potrzebujesz być trochę paranoikiem, wymień je, jeśli nie, możesz spać stosunkowo dobrze, nie robiąc tego.


SSH nie używa OpenSSL. Duża różnica.
Jacob

2
OpenSSH korzysta z libcrypto części OpenSSL. Dlatego musisz ponownie uruchomić SSH po aktualizacji OpenSSL. Dlatego niektórzy ludzie pytają, czy muszą wymienić klucze SSH. Zobacz moją odpowiedź powyżej ... Więc jaki jest twój cel?
Denis Witt
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.