Как я могу определить, содержит ли чей-то SSH-ключ пустую фразу-пароль?


44

Некоторые из моих систем Linux и FreeBSD имеют десятки пользователей. Персонал будет использовать эти узлы "ssh gateway" для SSH на другие внутренние серверы.

Мы обеспокоены тем, что некоторые из этих людей используют незашифрованный закрытый SSH-ключ (ключ без ключевой фразы . Это плохо , потому что, если взломщик когда-либо получит доступ к своей учетной записи на этом компьютере, он может украсть закрытый ключ и получить доступ на любой компьютер, который использует этот же ключ. В целях безопасности мы требуем, чтобы все пользователи шифровали свои закрытые ключи SSH с помощью ключевой фразы.

Как я могу узнать, что закрытый ключ не зашифрован (например, не содержит парольную фразу)? Есть ли другой способ сделать это на ключе, защищенном ASCII, и ключе, не защищенном ASCII?

Обновить:

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


2
grumble ssh-agent grumble На шлюзе не должно быть закрытых ключей.
Дероберт

Несколько педантичных примечаний: - Пользователи часто имеют плохую фразу-пароль . - Пользователи могут менять парольные фразы. - Пользователь может хранить свои ключи в нескольких местах. - Пользователи, скорее всего, будут использовать ssh agent, чтобы они могли один раз разблокировать ключ, скажем, на своем ноутбуке.
Бен Хайд

Ответы:


59

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

Зашифрованные закрытые ключи объявляются как таковые в файле закрытых ключей. Например:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,7BD2F97F977F71FC

BT8CqbQa7nUrtrmMfK2okQLtspAsZJu0ql5LFMnLdTvTj5Sgow7rlGmee5wVuqCI
/clilpIuXtVDH4picQlMcR+pV5Qjkx7BztMscx4RCmcvuWhGeANYgPnav97Tn/zp
...
-----END RSA PRIVATE KEY-----

Так что-то вроде

# grep -L ENCRYPTED /home/*/.ssh/id_[rd]sa

должен сделать свое дело.


3
@ jmanning2k: Я только что создал закрытый ключ RSA без ключевой фразы, и он не содержит строку «Шифрование: нет».
Стефан Ласевский

@ jmanning2k: -Lфлаг отображает только имена файлов, которые не соответствуют шаблону. Так что этот ответ верен сам по себе.
Багамат

Я исправлен, комментарий удален для ясности. Для записи у меня скопировано несколько файлов закрытого ключа Putty, которые читают «Шифрование: нет».
jmanning2k

2
или строка OPENSSH: см. tedunangst.com/flak/post/…
Джек

10

Я искал повсюду для этого и никогда не находил удовлетворительного ответа, но мне удалось построить один, так что ...

Обратите внимание, что это обновит файл, если он будет работать, поэтому, если вы пытаетесь не быть замеченным пользователями, ключи которых вы тестируете, вы можете сначала скопировать ключ. OTOH, поскольку вы только что поймали своего пользователя с помощью пароля без пароля, возможно, вам все равно, заметят ли они. : D

$ ssh-keygen -p -P '' -N '' -f ~/.ssh/KEYTEST
Key has comment '/home/rlpowell/.ssh/KEYTEST'
Your identification has been saved with the new passphrase.
$ echo $?
0

$ ssh-keygen -p -P '' -N '' -f ~/.ssh/KEYTEST
Bad passphrase.
$ echo $?
1

3
Почему бы не сделать -N ''так, чтобы фраза-пароль всегда оставалась неизменной?
хорошо относитесь к своим модам

Facepalm Это отлично, большое спасибо.
rlpowell

+1, потому что это решение работает даже с новым форматом закрытого ключа SSH.
Себастьян Крысманский

8

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

Если у вас нет доступа к закрытому ключу, я сомневаюсь, что вы можете обнаружить это. Цель ключевой фразы - «разблокировать» закрытый ключ, он не имеет функции в отношении открытого ключа.

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.