Комментарии 22
Кстати, небольшой оффтоп:
лично у меня файл с закрытым ключом отсутствует вообще:
mva@note ~ % ls ~/.ssh
authorized_keys config known_hosts
mva@note ~ % ssh router
router ~ %
Секрет в использовании GPG-ключа сгенерённого ещё не релизнутой (и хз когда релизнущейся) версией 2.1 (ибо текущая пока не умеет делать то, что надо) + gpg-agent'а в режиме эмуляции ssh-агента.
Правда, после Вашей статьи-перевода я задумался о том, безопасней ли это на самом деле, или не особо… :)
лично у меня файл с закрытым ключом отсутствует вообще:
mva@note ~ % ls ~/.ssh
authorized_keys config known_hosts
mva@note ~ % ssh router
router ~ %
Секрет в использовании GPG-ключа сгенерённого ещё не релизнутой (и хз когда релизнущейся) версией 2.1 (ибо текущая пока не умеет делать то, что надо) + gpg-agent'а в режиме эмуляции ssh-агента.
Правда, после Вашей статьи-перевода я задумался о том, безопасней ли это на самом деле, или не особо… :)
И
ssh-copy-id у вас работает? Очень интересный способ, надо что-то поподробнее почитать.да, работает (а уведомление о Вашем комменте я, почему-то, не получил на почту. прошу прощения) :)
Да и публичный ключ можно посмотреть с помощью ssh-add -L ;)
Да и публичный ключ можно посмотреть с помощью ssh-add -L ;)
Тут секрет прост. PGP ключ использует RSA/DSA пару для подписей. Собственно закрытый и открытый ключи RSA/DSA, которые используются SSH'ем является частью PGP ключа.
Интересен gpg-agent'а, предоставляющий ключи для SSH по надобности.
Интересен gpg-agent'а, предоставляющий ключи для SSH по надобности.
тут скорее наоборот: сгенерировать нужный закрытый 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
Спасибо за статью, весьма неожиданно с паролем получилось.
На всякий случай напомню пользователям ssh-ключей, что не стоит пренебрегать возможностью ограничивать варианты использования ключа настройкой публичной части (секция AUTHORIZED_KEYS FILE FORMAT в man sshd), в частности, крайне рекомендую указывать в опции from="" список хостов, с которых разрешено логиниться данному ключу, например
Если ключ только для git (или других очень узких целей), то можно и список разрешенных команд настроить.
На всякий случай напомню пользователям ssh-ключей, что не стоит пренебрегать возможностью ограничивать варианты использования ключа настройкой публичной части (секция AUTHORIZED_KEYS FILE FORMAT в man sshd), в частности, крайне рекомендую указывать в опции from="" список хостов, с которых разрешено логиниться данному ключу, например
from="1.2.3.4,5.6.7.8" ssh-dss AAAAB3NzaC...bla-bla...WWng==Если ключ только для git (или других очень узких целей), то можно и список разрешенных команд настроить.
Весьма сомнительная рекомендация, по-моему. Это нужно быть на 100% уверенным, что никогда не понадобится зайти не со своего компа и что провайдер адрес не поменяет.
Ограничение по хостам почти полностью нивелирует преимущества от использования персональных ключей. Те ключи, по которым одни сервера общаются с другими — другое дело.
А еще openssh уже достаточно давно умеет ecdsa, который афаик надежнее rsa. Кстати, а что надежнее dsa или rsa?
DSA не рекомендуются.
security.stackexchange.com/questions/5096/rsa-vs-dsa-for-ssh-authentication-keys
security.stackexchange.com/questions/5096/rsa-vs-dsa-for-ssh-authentication-keys
по поводу «более надёжный» можно ещё и поспорить. Ибо это как сравнивать самолёт и вертолёт. Они просто разные. Конечно, люди проводят аналогии в сравнениях, но самое главное, что мне однажды удалось нарыть:
Прошу обратить особое внимание на последнее предложение и вчитаться в то, что посередине.
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.
Прошу обратить особое внимание на последнее предложение и вчитаться в то, что посередине.
У DSA проблема в другом — атака на рандом и вскрытие ключа таким образом.
ЧТо такое ECC в данном контексте? Если ECDSA, то знаю, что это самый надежный из алгоритмов в линейке: RSA, DSA, ECDSA. Просто у меня телефон и планшет его не умеют. Поэтому выбираю между RSA и простым DSA.
ECC — вероятно, elliptic curve cryptography, как и ecdsa — dsa на эллиптических кривых
и таки, повторюсь, я бы воздержался от высказываний а-ля «знаю, что самый надёжный». И опять повторюсь, вы сравниваете не очень сравниваемые вещи. Прочитайте, пожалуйста, оригинал статьи.
Да, «матиматика эллиптических кривых» в криптографии показывает лучше результаты, чем теория простых чисел. Но сравнивать ECС и RSA как нечто одинаковое — не очень правильно.
К слову, да, libssh пока что не очень хорошо умеет в ecdsa в текущих релизнутых версиях (в ещё не релизнутой 0.6 уже добавили). Как следствие — куча софта для работы с тем же sftp колбасится при виде соответствующего ключа.
Да, «матиматика эллиптических кривых» в криптографии показывает лучше результаты, чем теория простых чисел. Но сравнивать ECС и RSA как нечто одинаковое — не очень правильно.
К слову, да, libssh пока что не очень хорошо умеет в ecdsa в текущих релизнутых версиях (в ещё не релизнутой 0.6 уже добавили). Как следствие — куча софта для работы с тем же sftp колбасится при виде соответствующего ключа.
Круто конечно, но у меня в Ubuntu Seahorse не понимает, что это именно SSH ключ.
Познавательно, спасибо.
Однако вот это:
неверно (если я правильно понял алгоритм, конечно).
В данном случае хэш-функция используется только для того, чтобы сделать ключ шифрования более «псевдослучайным» — при этом злоумышленник даже в случае компрометации MD5 ничего сделать не может, ибо не видит результат хэширования. В случае применения вместо AES идеальной PRP хэширование можно вообще не применять с тем же результатом.
Однако вот это:
Если выяснится, что MD5 недостаточно безопасен, будут проблемы.
неверно (если я правильно понял алгоритм, конечно).
В данном случае хэш-функция используется только для того, чтобы сделать ключ шифрования более «псевдослучайным» — при этом злоумышленник даже в случае компрометации MD5 ничего сделать не может, ибо не видит результат хэширования. В случае применения вместо AES идеальной PRP хэширование можно вообще не применять с тем же результатом.
Неделя криптобезопасности на хабре. Прирост SSH-ключей увеличился вдвое.
Тем, кто так же попадает из поисковой системы сюда, то в 2016 имеются улучшения для повышения безопасности хранения ssh-ключей:
Однако ни один из способов не работает при использовании PuTTY, да и вообще на виндовых клиентах, которые пробовал. На Debian 8.6 Stable все ок.
- Вместо 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 все ок.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Повышаем безопасность закрытых ssh-ключей