☰

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

tag-icon • tag-icon security ssh-keys
Как хранить SSH-ключи?

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

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

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

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

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

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

решение1

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

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

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

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

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

решение2

Есть очень хороший инструмент под названием KeePass2 (http://keepass.info/) с расширением (http://lechnology.com/software/keeagent/)

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

Я сам им пользуюсь и очень доволен. У меня более 30 VPS и корневых серверов с определенным количеством различных ключей SSH, и единственное, что мне нужно сделать, это открыть KeePass (это не мой основной сейф с паролями), а затем мне просто нужно ввести в консоли свою парольную фразу.

решение3

Я бы добавил, что ~/.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>

решение4

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

ssh -i identity_file [email protected]

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

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

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

задает путь к файлу конфигурации.

P.S. Я бы создал псевдоним alias ssh='ssh -i ... -F ...'и добавил его в ваш профиль.

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

Связанный контент