Как хранить ключи SSH?

67

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

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

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

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

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

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

security ssh-keys Антон Строгонов
источник
Эта ссылка, кажется, не работает help.github.com/multiple-ssh-keys
KJ Price
@KJ Price, благодаря Wayback Machine Интернет-архива , страница все еще доступна в Интернете, хотя и не по ее первоначальной ссылке. Копию страницы, заархивированную 2 сентября 2011 года, можно найти в разделе Несколько ключей SSH .
лунная точка

Ответы:

41

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

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

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

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

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

Дэвид З
источник
14
Это работает, только если у вас есть какой-то другой метод доступа к серверам, к которым этот закрытый ключ предоставляет доступ. Вы можете загрузить новый открытый ключ, только если у вас есть этот резервный доступ.
ДЕРЕВО
2
@TREE: верно, но по моему опыту, очень редко можно найти сервер, который не предоставляет какой-либо альтернативный метод доступа (или, по крайней мере, добавления дополнительного открытого ключа без прохождения SSH).
Дэвид Z
3
Спасибо, это многое проясняет. Действительно, потеря личного SSH-ключа не выглядит проблемой, поскольку для всех служб, которые я использую, всегда есть другой способ получить доступ к службе для загрузки новой.
Антон Строгонов
3
AWS не предоставляет никакой другой формы доступа, кроме закрытого ключа. Вы должны отключить диск и дурачиться с ним, чтобы получить доступ, как только вы потеряли свой закрытый ключ.
Асад Саидуддин
1
Обратите внимание, что вы можете поставить пароль на свой закрытый ключ, если вы хотите еще один уровень безопасности.
Судо
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>
HeyWatchThis
источник
17
Чтобы быть понятным, только потому, что браузер может читать ваш закрытый ключ, но это не значит, что веб-сайт работает в браузере.
Ajedi32
6
Но если вы внедрите процесс в процесс браузера. Тогда вы можете взять под контроль и браузер. Так что этот аргумент совершенно справедлив.
BigSack
Но тогда вам придется взломать процесс, который внедряет процессы в регистр процессов вашего процессора.
Скид Кадда
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-файл, в котором есть мои настройки пользователя (.bashrc, .ssh / и другие файлы конфигурации), которые я храню в безопасном месте. Когда я получаю новую учетную запись оболочки, я распаковываю в нее файл tar.

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

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

EightBitTony
источник
Я предполагаю, что шифрование ~ / .ssh, висящего на флешке, избавит от необходимости генерировать и загружать новый ключ в случае аппаратного сбоя. Однако, поскольку у меня очень мало серверов, к которым я использую ключи SSH (и очень мало машин, к которым я подключаюсь), генерация новых ключей не вызовет больших накладных расходов.
Антон Строгонов
2
Это лошади для курсов и зависит от того, почему вы используете ключи. Я не вижу проблемы при копировании закрытого ключа ssh по уже зашифрованной ссылке SSH. Но если вы не доверяете целевому компьютеру и не знаете, кто имеет root-доступ, вы не должны помещать на сервер ничего, что вы не можете позволить себе потерять.
EightBitTony
Вы не хотите помещать свой закрытый ключ на чужой сервер. Любой пользователь с доступом Root на этом сервере может прочитать ваш закрытый ключ, а затем он может выдать себя за вас в системах, к которым вы получаете доступ с помощью этого закрытого ключа. Вы должны только поставить свой открытый ключ для доступа к серверу. И не думайте, что ключевая фраза очень помогает, если вы используете ее на удаленной машине для расшифровки закрытого ключа.
Codeguy007
Вы можете переслать ssh-agent через ssh. Таким образом, вам не нужно хранить закрытый ключ на сервере или отправлять вашу фразу-пароль по сети. stackoverflow.com/questions/12257968/…
Codeguy007
1

Вы можете хранить ваши ключи ssh в отдельном каталоге внутри зашифрованного раздела. Затем вы можете использовать ssh, указывая на этот каталог -i:

ssh -i identity_file me@example.com

Полное описание ( man ssh):

-i identity_file

Выбирает файл, из которого читается идентификатор (закрытый ключ) для аутентификации с открытым ключом. По умолчанию используется ~ / .ssh / identity для протокола версии 1 и ~ / .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.

Ярослав Никитенко
источник