Як зберігати SSH ключі?

67

Я почав використовувати ключі SSH замість паролів зовсім недавно (звичайно, дякую GitHub), тому, будь ласка, майте на увазі, що я досить нова в цілому цій концепції. Наразі мої ключі просто лежать під ~ / .ssh, але я не впевнений, чи це хороша практика. Наприклад, якщо у мене є кілька машин, мені потрібно буде дублювати свої приватні ключі, що я вважаю небажаним. Або, якщо мій жорсткий диск перейде на капут, я втрачу ті ключі, які (я думаю) також небажані.

Отже, які найкращі практики зберігання SSH-ключів надійно, зручно та надійно?

Здається, використання смарт-картки - це варіант (див. Smartcards для зберігання gpg / ssh-ключів (Linux) - що мені потрібно? ), Це найкращий варіант?

Оновлення. Причиною виникнення питання було те, що багато сервісів (наприклад, GitHub, AWS EC2) надають посібники про те, як налаштувати SSH-ключі для користування сервісом, але мало на чому немає (наприклад, що робити, якщо у вас вже створений ключ по ssh-keygen[1], які рекомендовані заходи безпеки). І незрозуміло, чи є ця інформація насправді неважливою, чи очікується, що ви знаєте її "за замовчуванням".

Підсумовувати відповіді до цього моменту (але, будь ласка, прочитайте їх, і якщо у вас є що додати - будь ласка): здається, що в цьому випадку добре, якщо ви просто залишите свої приватні ключі в ~ / .ssh, якщо ви бережіть їх від інших людей; але переконайтесь, що у вас є інший спосіб отримати доступ до служби для завантаження або генерування нового ключа, якщо ви втратите його (як правило).

[1] GitHub використовувався для надання допомоги щодо управління кількома ключами .

security ssh-keys

— Антон Строгонов
джерело

Це посилання, здається, порушено help.github.com/multiple-ssh-keys

— KJ Ціна

@KJ Price, завдяки Wayback Machine Internet Archive , сторінка все ще доступна в Інтернеті, хоча не за її вихідним посиланням. Копію сторінки, заархівованої 2 вересня 2011 року, можна знайти за допомогою декількох ключів SSH .

— місячна точка

41

Наприклад, якщо у мене є кілька машин, мені потрібно буде дублювати приватні ключі, що я вважаю небажаним.

Ні, насправді ви цього не робите. Якщо у вас кілька машин, ви просто створите окремий приватний ключ на кожному. Для кожного приватного ключа просто завантажте відповідний відкритий ключ у GitHub, використовуючи той самий процес.

Крім того, якщо мій жорсткий диск перейде до капуту, я втрачу приватний ключ, який (я думаю) також небажаний.

Не зовсім; якщо ви втратите свій приватний ключ, просто створіть новий і завантажте відповідний відкритий ключ.

Що ви того варті, ви маєте рацію, що копіювання приватного ключа вкрай небажане. В ідеалі приватний ключ повинен генеруватися в одному файлі ( ~/.ssh/id_rsaнаприклад) і ніколи не повинен залишати цей файл - тобто він ніколи не повинен бути скопійований, переміщений та особливо не переданий через мережу. (наприклад, я виключаю їх із резервного копіювання) Через характер асиметричних протоколів аутентифікації вам потрібно потурбуватися лише про те, щоб не захищати приватний ключ від рук інших. Якщо ви переходите трохи за борт і самі втрачаєте це, це, як правило, не велика справа. (Це не слід плутати з приватними ключами асиметричного шифрування , наприклад, ключами GPG, до яких ви, мабуть, хочете утримувати.)

— Девід Z
джерело

14

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

— ТРЕЙ

2

@TREE: правильно, але, на мій досвід, надзвичайно рідко можна знайти сервер, який не надає альтернативного способу доступу (або принаймні додавання додаткового відкритого ключа, не проходячи через SSH).

— David Z

3

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

— Антон Строгонов

3

AWS не надає жодної іншої форми доступу, крім приватного ключа. Вам потрібно відключити накопичувач і обдурити його, щоб отримати доступ після втрати приватного ключа.

— Асад Саєдюддін

1

Зауважте, що ви можете ввести пароль у свій приватний ключ, якщо вам потрібен інший рівень захисту.

— судо

8

Я додам, що ~ / .ssh / читається вашим браузером, якщо ви використовуєте один і той же обліковий запис користувача для запуску обох.

Спробуй це! Наведіть веб-переглядач на ваш приватний ключ у вашому домашньому каталозі. Це весело.

Тому я рекомендую зберігати ssh-ключі в домашній каталог іншого облікового запису користувача.

слово на захисних ключах парольної фрази

У наші дні зламати не випадкові випадкові паролі дуже швидко. Ознайомтеся з хеш-котом
- (Хоча випадкові та довгі 12+ паролі для помилок все ще потребують досить тривалого часу)
- Таким чином, зашифровані ssh-ключі в AES є нездатними для огляду в майбутньому, якщо ви використовуєте хороші довгі парольні фрази. Див. Рекомендації github
Тож деякі веб-сайти можуть здогадатися-схопити ваш ключ без JavaScript. А потім жорстоко натисніть клавішу в автономному режимі.
І веб-переглядачі можуть також заглядати у ваш буфер обміну з Ж / С. Таким чином, вставлення копій дуже довгих парольових фраз також наражає вас на небезпеку більш складних атак JavaScript.

look_at_keys.html

 9 <HTML>
10 <HEAD>
11 <TITLE>look at keys</TITLE>
12 </HEAD>
13 <FRAMESET cols="20%, 80%">
14   <FRAMESET rows="100, 200">
15       <FRAME src="/Users/yourname/.ssh/stuff.pem">
16       <FRAME src="blah.html">
17   </FRAMESET>
18   <FRAME src="contents_of_frame3.html">
19 </FRAMESET>
20 </HTML>

— HeyWatchЦе
джерело

17

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

— Ajedi32

6

Але, якщо ви вводите процес у процес браузера. Тоді ви також можете взяти під контроль браузер. Тож цей аргумент цілком справедливий.

— BigSack

Але тоді вам доведеться зламати процес, який вводить процеси в реєстр процесорних одиниць вашого браузера.

— Skid Kadda

8

Є дуже приємний інструмент на ім'я KeePass2 ( http://keepass.info/ ) з розширенням ( http://lechnology.com/software/keeagent/ )

Ви можете зберігати там паролі, ключі SSH та багато іншого (на офіційній сторінці KeePass набагато більше корисних розширень)
Якщо ви хочете автоматично входити в систему за допомогою ключів SSH, вам просто потрібно встановити PuTTY, Pageant та KeePass з KeeAgent. Якщо ви правильно налаштували, вам не потрібно встановлювати клавіші в PuTTY, Pageant або FileZilla.

Я сам це використовую, і я дуже радий цьому. У мене більше 30 VPS і Root Server з певною кількістю різних SSH ключів, і єдине, що мені потрібно зробити, відкрити KeePass (Це не мій основний безпечний пароль), і тоді мені просто потрібно ввести в консоль свою парольну фразу.

— CentrixDE
джерело

3

Я рекомендую зберігати приватні ключі:

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

Я б сказав, найкраще місце було б:

зовнішній жорсткий диск
клавіша спалаху
комп’ютер, не підключений до Інтернету

Ще краще, просто роздрукуйте його і покладіть в сейф, захищений від пожежі.

— бла
джерело

4

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

— zaTricky

1

У мене є файл tar, у якому встановлено моє налаштування dir користувача (.bashrc, .ssh / та інші конфігураційні файли), яке я зберігаю в безпечному місці. Коли я десь отримую новий обліковий запис оболонки, я розпаковую файл tar.

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

Особисто мені зручно просто копіювати .ssh / речі скрізь (це також означає, що звичайний ключ ssh отримує ssh доступ миттєво, оскільки він вже є у файлі санкціонованих_кіїв).

— EightBitTony
джерело

Я думаю, що зашифрований ~ / .ssh висів навколо USB-накопичувача врятував би від необхідності генерувати та завантажувати новий ключ у разі відмови обладнання. Однак, оскільки існує дуже мало серверів, до яких я використовую SSH-ключі (і дуже мало машин, з яких я підключаюсь), генерування нових ключів не призведе до великих витрат.

— Антон Строгонов

2

Це коні на курси і залежить від того, для чого ви використовуєте ключі. Я не бачу проблеми з копіюванням приватного ключа ssh через уже зашифроване посилання SSH. Але якщо ви не довіряєте цільовій машині і не знаєте, хто має кореневий доступ, вам не слід ставити нічого на сервер, який ви не можете дозволити собі втратити.

— EightBitTony

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

— Codeguy007

Ви можете переслати ssh-агент через ssh. Таким чином, вам не потрібно зберігати приватний ключ на сервері або надсилати свою парольну фразу через мережу. stackoverflow.com/questions/12257968 / ...

— Codeguy007

1

Ви можете зберігати ключі ssh в окремому каталозі всередині зашифрованого розділу. Тоді ви можете використовувати ssh, що вказує на цей каталог за допомогою -i:

ssh -i identity_file me@example.com

Повний опис ( man ssh):

-i ідентифікаційний_файл

Вибирає файл, з якого зчитується особа (приватний ключ) для аутентифікації відкритого ключа. За замовчуванням для версії протоколу 1 є ~ / .ssh / ідентифікатор та ~ / .ssh / id_dsa, ~ / .ssh / id_ecdsa, ~ / .ssh / id_ed25519 та ~ / .ssh / id_rsa для версії протоколу 2. Файли посвідчень можуть бути також буде вказано на основі хоста у файлі конфігурації.
Можливо мати кілька опцій -i (та кілька ідентичностей, вказаних у файлах конфігурації). Якщо в директиві CertificateFile чітко не вказано жодних сертифікатів, ssh також спробує завантажити інформацію сертифіката з імені файлу, отриманого додаванням -cert.pub до імен файлів ідентичності.

Мій підхід до безпеки полягає в тому, що я поділяю інформацію на приватну та загальну. Я не хочу шифрувати весь свій домашній розділ, тому я копіюю секретні файли (як і ті, що є ~/.ssh) в зашифрований розділ.

Я думаю, що це забезпечує досить ефективну безпеку, оскільки зловмисне програмне забезпечення не знайде нічого в ~ / .ssh, і, ймовірно, воно не сканує всю вашу систему або профілі оболонки, щоб знайти це місце.

-F configfile

встановлює шлях до конфігураційного файлу.

PS Я б створив псевдонім alias ssh='ssh -i ... -F ...'і помістив його у ваш профіль.

PPS Я цього ще не перевіряв, і не знаю, як інші програми (наприклад, git) будуть працювати з цими налаштуваннями ssh.

— Ярослав Нікітенко
джерело