Чи впливає остання помилка Heartbleed на сш-ключі, які я створив і використовую для натискання / перетягування коду з Github, Heroku та іншими подібними сайтами?
Чи потрібно мені замінити ключі, якими я користувався?
Чи впливає остання помилка Heartbleed на сш-ключі, які я створив і використовую для натискання / перетягування коду з Github, Heroku та іншими подібними сайтами?
Чи потрібно мені замінити ключі, якими я користувався?
Відповіді:
Ні, Heartbleed насправді не впливає на SSH-ключі, тому вам, ймовірно, не потрібно замінювати SSH-ключі, якими ви користувалися.
По-перше, SSL і SSH - це два різних протоколи безпеки для двох різних цілей. Аналогічно, OpenSSL та OpenSSH також є двома абсолютно різними програмними пакетами, незважаючи на подібність у їх назвах.
По-друге, експлуатація Heartbleed змушує вразливий аналог OpenSSL TLS / DTLS повертати випадкові 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 змушує вразливий одноранговий OpenSSL TLS / DTLS повертати випадкові 64 КБ пам'яті, але він майже напевно обмежується пам'яттю, доступною для цього процесу, що використовує OpenSSL."
якщо машина стає компрометованою, то як ви можете їй довіряти що-небудь, включаючи ssh? від heartbleed.com
"Які витоки на практиці?
Ми перевірили деякі власні послуги з точки зору нападника. Ми атакували себе ззовні, не залишаючи сліду. Не використовуючи жодної привілейованої інформації чи облікових даних, ми змогли викрасти у себе секретні ключі, які використовуються для наших сертифікатів X.509, імен користувачів та паролів, миттєвих повідомлень, електронних листів та важливих для бізнесу документів та комунікацій. "
хтось, можливо, поставив приватний ключ, без парольної фрази, на сервер, який він вважав, що він не є зловмисним ... але виявилося. b / c SSL-помилка дозволила вийти з пароля користувача, користувача, у якого "sudo" ... це, мабуть, не проблема .... але ...
люди іноді роблять божевільні речі
http://blog.itionsource.org/2010/08/28/mining-passwords-from-public-github-repositories/