awolf 29 мая 2013 в 07:20

Повышаем безопасность закрытых ssh-ключей

8 мин

66K

Информационная безопасность *

Перевод

+92

Комментарии 22

mva 29 мая 2013 в 08:10

Кстати, небольшой оффтоп:
лично у меня файл с закрытым ключом отсутствует вообще:
mva@note ~ % ls ~/.ssh
authorized_keys config known_hosts
mva@note ~ % ssh router
router ~ %

Секрет в использовании GPG-ключа сгенерённого ещё не релизнутой (и хз когда релизнущейся) версией 2.1 (ибо текущая пока не умеет делать то, что надо) + gpg-agent'а в режиме эмуляции ssh-агента.

Правда, после Вашей статьи-перевода я задумался о том, безопасней ли это на самом деле, или не особо… :)

philpirj 30 мая 2013 в 11:35

И ssh-copy-id у вас работает? Очень интересный способ, надо что-то поподробнее почитать.

mva 15 июл 2013 в 19:03

да, работает (а уведомление о Вашем комменте я, почему-то, не получил на почту. прошу прощения) :)
Да и публичный ключ можно посмотреть с помощью ssh-add -L ;)

philpirj 17 июл 2013 в 15:30

Тут секрет прост. PGP ключ использует RSA/DSA пару для подписей. Собственно закрытый и открытый ключи RSA/DSA, которые используются SSH'ем является частью PGP ключа.
Интересен gpg-agent'а, предоставляющий ключи для SSH по надобности.

mva 17 июл 2013 в 20:09

тут скорее наоборот: сгенерировать нужный закрытый PGP-ключ может только не релизнутая (и, судя по всему, не скоро релизнущаяся) версия gnupg. В то время, как даже текущая версия gpg-agent'a из коробки того же gnupg текущей версии спокойно подхватывает нужный gpg-ключ и добавляет его в псево-ssh-агент если агент запущен с --enable-ssh-support.

У меня, например:

mva PID 0.0 0.0 16948 1568? Ss июл14 0:10 /usr/bin/gpg-agent --daemon --write-env-file /home/mva/.gpg-agent-info --enable-ssh-support --no-use-standard-socket --allow-mark-trusted

(А если быть точнее, то в /etc/kde/startup/agent-startup.sh)

if [[ -z $(pgrep gpg-agent -U $UID) ]]; then
        if [[ -x /usr/bin/gpg-agent ]]; then
                eval "$(/usr/bin/gpg-agent --daemon --write-env-file ${HOME}/.gpg-agent-info --enable-ssh-support --no-use-standard-socket --allow-mark-trusted)"
        fi;
else
        if [[ -f "${HOME}/.gpg-agent-info" ]]; then
                source "${HOME}/.gpg-agent-info"
                export GPG_AGENT_INFO
                export SSH_AUTH_SOCK
                export SSH_AGENT_PID
                ln -sf "${GPG_AGENT_INFO/:*/}" "${HOME}/.gnupg/S.gpg-agent"
                GPG_TTY=${TTY}
                export GPG_TTY
        fi
fi

zuborg 29 мая 2013 в 08:54

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

На всякий случай напомню пользователям ssh-ключей, что не стоит пренебрегать возможностью ограничивать варианты использования ключа настройкой публичной части (секция AUTHORIZED_KEYS FILE FORMAT в man sshd), в частности, крайне рекомендую указывать в опции from="" список хостов, с которых разрешено логиниться данному ключу, например
from="1.2.3.4,5.6.7.8" ssh-dss AAAAB3NzaC...bla-bla...WWng==
Если ключ только для git (или других очень узких целей), то можно и список разрешенных команд настроить.

VolCh 29 мая 2013 в 09:07

Весьма сомнительная рекомендация, по-моему. Это нужно быть на 100% уверенным, что никогда не понадобится зайти не со своего компа и что провайдер адрес не поменяет.

zuborg 29 мая 2013 в 09:10

Я же не говорил, что пароли отменяются )

ComodoHacker 29 мая 2013 в 10:29

Ограничение по хостам почти полностью нивелирует преимущества от использования персональных ключей. Те ключи, по которым одни сервера общаются с другими — другое дело.

J_o_k_e_R 29 мая 2013 в 09:35

А еще openssh уже достаточно давно умеет ecdsa, который афаик надежнее rsa. Кстати, а что надежнее dsa или rsa?

datacompboy 29 мая 2013 в 10:00

DSA не рекомендуются.
security.stackexchange.com/questions/5096/rsa-vs-dsa-for-ssh-authentication-keys

mva 29 мая 2013 в 12:13

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

It all comes down to key size. A 384 bit elliptical curve key is equivalent to a 7680 bit RSA key in terms of security, and at some point (I don't know exactly where), ECC starts outperforming RSA for the same level of security.

The advantage to RSA is simplicity. RSA can encrypt arbitrary data, so it can be used directly for both signing and key exchange, and can even encrypt data directly.
ECC cannot be used to encrypt data directly, and requires separate algorithms to derive keys and generate/verify signatures.

The biggest problem with ECC is it's tangled in a web of patents, which makes implementing it risky unless you really want to spend a lot of time reading patents.

Прошу обратить особое внимание на последнее предложение и вчитаться в то, что посередине.

datacompboy 29 мая 2013 в 12:25

У DSA проблема в другом — атака на рандом и вскрытие ключа таким образом.

J_o_k_e_R 29 мая 2013 в 13:08

ЧТо такое ECC в данном контексте? Если ECDSA, то знаю, что это самый надежный из алгоритмов в линейке: RSA, DSA, ECDSA. Просто у меня телефон и планшет его не умеют. Поэтому выбираю между RSA и простым DSA.

merlin-vrn 29 мая 2013 в 13:15

ECC — вероятно, elliptic curve cryptography, как и ecdsa — dsa на эллиптических кривых

mva 29 мая 2013 в 15:10

и таки, повторюсь, я бы воздержался от высказываний а-ля «знаю, что самый надёжный». И опять повторюсь, вы сравниваете не очень сравниваемые вещи. Прочитайте, пожалуйста, оригинал статьи.

Да, «матиматика эллиптических кривых» в криптографии показывает лучше результаты, чем теория простых чисел. Но сравнивать ECС и RSA как нечто одинаковое — не очень правильно.

К слову, да, libssh пока что не очень хорошо умеет в ecdsa в текущих релизнутых версиях (в ещё не релизнутой 0.6 уже добавили). Как следствие — куча софта для работы с тем же sftp колбасится при виде соответствующего ключа.

seriyPS 29 мая 2013 в 12:32

Круто конечно, но у меня в Ubuntu Seahorse не понимает, что это именно SSH ключ.

seriyPS 29 мая 2013 в 12:43

Пардон, после того, как удалил и снова импортировал ключ через интерфейс Seahorse всё заработало.

pfa 29 мая 2013 в 12:41

Познавательно, спасибо.
Однако вот это:

Если выяснится, что MD5 недостаточно безопасен, будут проблемы.

неверно (если я правильно понял алгоритм, конечно).

В данном случае хэш-функция используется только для того, чтобы сделать ключ шифрования более «псевдослучайным» — при этом злоумышленник даже в случае компрометации MD5 ничего сделать не может, ибо не видит результат хэширования. В случае применения вместо AES идеальной PRP хэширование можно вообще не применять с тем же результатом.

datacompboy 29 мая 2013 в 13:03

эта конкретно строчка да, ни ап чом
а вот проблема с AES есть — нам надо только один первый раунд. так как мы знаем, что после расшифровки будет ASN.1 — мы можем даже атаку на известный открытый текст проводить.

iago 30 мая 2013 в 05:58

Неделя криптобезопасности на хабре. Прирост SSH-ключей увеличился вдвое.

melt 11 окт 2016 в 11:32

Тем, кто так же попадает из поисковой системы сюда, то в 2016 имеются улучшения для повышения безопасности хранения ssh-ключей:

Вместо des3 можно использовать aes-256-cfb или aes-256-cbc:
```
openssl pkcs8 -in id_rsa -topk8 -v2 aes-256-cfb -out id_rsa_cfb
```
С помощью ssh-keygen приватный ключ можно хранить в новом формате [-o], который позволяет указывать количество итераций хэширования [-a]. Ключ, полученный в следующем примере, на Intel i5 проверяется при подключении на удаленный сервер около 10 секунд (я в свое окно укладываюсь, но можно и снизить паранойю)
```
ssh-keygen -o -a 2048 -t rsa -b 8192
# новый формат хранения для имеющегося ключа (перед этим сделать его копию):
ssh-keygen -o -a 2048 -p -f id_rsa
```
Что внутри ключа:
```
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAA....
....bla-bla....
-----END OPENSSH PRIVATE KEY-----
```

Однако ни один из способов не работает при использовании PuTTY, да и вообще на виндовых клиентах, которые пробовал. На Debian 8.6 Stable все ок.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий