Как хранить ключи 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.

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