57

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

Итак, каковы рекомендации по безопасному, удобному и надежному хранению ключей SSH?

Похоже, использование смарт-карты является опцией (см. Смарт-карты для хранения ключей gpg/ssh (Linux) - что мне нужно?), Это лучший?

Обновление. Причиной этого вопроса было то, что многие службы (например, GitHub, AWS EC2) предоставляют инструкции о том, как настроить ключи SSH для использования службы, но практически не имеют фона (например, что делать, если у вас уже есть сгенерированный ключ). по ssh-keygen [1], какие рекомендуемые меры безопасности). И неясно, является ли эта информация на самом деле неважной, или вы должны знать ее «по умолчанию».

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

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

5 ответов5

38

Например, если у меня несколько компьютеров, мне нужно будет дублировать закрытые ключи, что я считаю нежелательным.

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

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

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

Что бы это ни стоило, вы правы, что дублирование закрытого ключа крайне нежелательно. В идеале закрытый ключ должен быть сгенерирован в одном файле (например, ~/.ssh/id_rsa ) и никогда не должен оставлять этот файл, то есть он никогда не должен копироваться, перемещаться и особенно не передаваться по сети. (например, я исключаю их из резервных копий). Из-за природы асимметричных протоколов аутентификации вам нужно только заботиться о том, чтобы ваш личный ключ не попадал в руки других. Если вы идете немного за борт и сами это теряете, это, как правило, не имеет большого значения. (Это не следует путать с закрытыми ключами асимметричного шифрования , например с ключами GPG, которые вы, вероятно, хотите сохранить.)

8

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

Попытайся! Направьте ваш браузер на ваш закрытый ключ в вашем домашнем каталоге. Это весело.

Поэтому я бы рекомендовал хранить ssh-ключи в домашнем каталоге другой учетной записи пользователя.

слово о ключах защиты парольной фразы

  • В наши дни взломать неслучайные пароли очень быстро. Проверьте хэш-кошку
    • (Хотя случайные и длинные пароли с 12 и более символами все еще занимают достаточно много времени)
    • Таким образом, ssh-ключи, зашифрованные AES, в обозримом будущем не взломать, если вы используете хорошие длинные парольные фразы. Смотрите рекомендации github
  • Так что какой-то сайт может угадать ваш ключ без JavaScript. А затем перебор ключа.
  • И браузеры тоже могут заглянуть в ваш буфер обмена с JS. Таким образом, копирование очень длинных парольных фраз также подвергает вас риску от более сложных атак на 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>
7

Существует очень хороший инструмент под названием 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(это не мой основной пароль, безопасный), а затем мне просто нужно ввести в консоль мою пароль.

3

Я бы порекомендовал хранить закрытые ключи:

  • в автономном режиме (не в облаке)
  • в более чем одном месте
  • кроме всего, что связано с ним, например, ключа для ваших зашифрованных данных, храните их отдельно от данных

Я бы сказал, лучшее место было бы:

  • внешний жесткий диск
  • флэш-ключ
  • компьютер не подключен к интернету

Еще лучше, просто распечатайте его и положите в пожаробезопасный сейф.

1

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

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

Лично мне удобно просто копировать мои .ssh/ вещи повсюду (это также означает, что обычный ключ ssh мгновенно получает доступ к ssh, так как он уже находится в файле author_keys).

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .