Чому Google радить видалити SSH ключі з GCE?


15

Нижче посилання на документацію Google більше не відповідає дійсності.

Google рекомендує видалити SSH ключі з екземпляра GCE, щоб захистити SSH. Це не має для мене ніякого сенсу. Ключі є для безпеки, правда? Коли я виймаю ключі, SSHD перестає працювати. Я, мабуть, пропускаю їхню думку. Чи може хтось пояснити, що означає це:

Видаліть хости ключі ssh

Не використовуйте хости ключі ssh зі своїм екземпляром. Видаліть їх наступним чином:

rm /etc/ssh/ssh_host_key
rm /etc/ssh/ssh_host_rsa_key*
rm /etc/ssh/ssh_host_dsa_key*
rm /etc/ssh/ssh_host_ecdsa_key*

2
Документ рекомендує включити, StrictHostKeyCheckingа пізніше рекомендує відключити його. Я підозрюю, що це не дуже ретельно відредагований документ. Моя порада - довіряти власному судженням і використовувати ключі хоста, якщо немає вагомих причин цього не робити.
aecolley

@aecolley Я також помітив це. Я надіслав їм відгук. Побачимо, чи повернуться до мене.
Мартін Прикрил

1
Я розповів нижче, але це зводиться до контексту - сторінка, яку ви переглядаєте, дає поради щодо створення нових зображень, а не для загальної безпеки машини. Я оновлюю документи, щоб включити більш детальну інформацію про те, коли і чому ви хочете видалити свої хост-ключі, оскільки причини не зрозумілі.
Бенсон

Відповіді:


12

Найважливішою деталлю є те, що сторінка, на яку ви посилаєтесь, стосується створення нового зображення машини Compute Engine. Зокрема, створюючи новий образ віртуальної машини, ви хочете переконатися, що він НЕ містить жодних ключів хоста. Таким чином, коли зображення клонується та відновлюється у фактичну VM, скрипт запуску sshd визнає відсутність хост-ключів та автоматично генерує нові. Це бажано, оскільки мати декілька машин, які використовують один і той же ключ хоста, дуже погана ідея.

Так, у загальному випадку не слід видаляти хост-ключі, але якщо ви створюєте нове зображення, це важливий крок для того, щоб переконатися, що між хост-ключами та машинами існує взаємозв'язок один на один.


1
Спасибі. Це має сенс. Хоча якесь пояснення допоможе. "Не використовуйте хости ключі ssh зі своїм екземпляром." насправді заплутане фразування.
Мартін Прикрил

Я погоджуюся повністю - дуже дякую, що вказали на це. Я фактично подав оновлення в документи, щоб уточнити формулювання, яке, підозрюю, незабаром буде витіснене.
Бенсон

1
Оновлені документи тепер доступні: developers.google.com/compute/docs/images#removesshkeys
Бенсон

13

Єдиною можливою причиною, про яку я можу подумати, є те, що вони хочуть змусити вас відновлювати нові ключі.
Оскільки ці ключі були згенеровані до того, як у вас був доступ, вони можуть не довіряти їм.
Видалення та перезапуск sshdключів відновить для вас.
Однак документ насправді цього не дає зрозуміти.

Це чисті спекуляції, і було б краще зв’язатися з ними та отримати уточнення з цього приводу.


4
Дякую за Вашу відповідь. Мені потрібно ssh на сервер, щоб перезапустити sshd. Але для підключення мені потрібно прийняти хост-ключ "не довіреного" сервера. Тому нічого, що я роблю під час сеансу, не можна довіряти. Навіть перезапуск sshd. Правильно?
Мартін Прикрил

1
Я думаю, головне занепокоєння полягатиме в тому, що чомусь інший клієнт отримує ті самі ключі, що і ви (зауважте: це не дозволяє їм отримати доступ до вашого примірника, але полегшує атаку на вас людиною в середині). Якщо ви не довіряєте постачальнику зображень, тоді вам нічого не слід запускати там (вони практично мають фізичний доступ).
факер

1
IIRC проводили деякі дослідження, які показують, що якість ентропії в деяких системах, особливо вбудованих, але це може також включати деякі категорії щойно запущених віртуальних машин, не дуже висока. Коли відкриті ключі створюються під час першого завантаження, наприклад, ключі хостів SSH, це можуть бути передбачувані.
HBruijn

@HBruijn Дякую за коментар Але їх видалення та надання sshd відтворити їх при перезапуску не робить їх кращими. Вам доведеться завантажити свій. Але це не висвітлено в документі.
Мартін Прикрил

1
Я надіслав відгук Google. Побачимо, чи повернуться до мене.
Мартін Прикрил
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.