Pull to refresh

Comments 22

Кстати, небольшой оффтоп:
лично у меня файл с закрытым ключом отсутствует вообще:
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 ;)
Тут секрет прост. PGP ключ использует RSA/DSA пару для подписей. Собственно закрытый и открытый ключи RSA/DSA, которые используются SSH'ем является частью PGP ключа.
Интересен 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="" список хостов, с которых разрешено логиниться данному ключу, например
from="1.2.3.4,5.6.7.8" ssh-dss AAAAB3NzaC...bla-bla...WWng==
Если ключ только для git (или других очень узких целей), то можно и список разрешенных команд настроить.
Весьма сомнительная рекомендация, по-моему. Это нужно быть на 100% уверенным, что никогда не понадобится зайти не со своего компа и что провайдер адрес не поменяет.
Я же не говорил, что пароли отменяются )
Ограничение по хостам почти полностью нивелирует преимущества от использования персональных ключей. Те ключи, по которым одни сервера общаются с другими — другое дело.
А еще openssh уже достаточно давно умеет ecdsa, который афаик надежнее rsa. Кстати, а что надежнее dsa или rsa?
по поводу «более надёжный» можно ещё и поспорить. Ибо это как сравнивать самолёт и вертолёт. Они просто разные. Конечно, люди проводят аналогии в сравнениях, но самое главное, что мне однажды удалось нарыть:

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

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

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

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

В данном случае хэш-функция используется только для того, чтобы сделать ключ шифрования более «псевдослучайным» — при этом злоумышленник даже в случае компрометации MD5 ничего сделать не может, ибо не видит результат хэширования. В случае применения вместо AES идеальной PRP хэширование можно вообще не применять с тем же результатом.
эта конкретно строчка да, ни ап чом
а вот проблема с AES есть — нам надо только один первый раунд. так как мы знаем, что после расшифровки будет ASN.1 — мы можем даже атаку на известный открытый текст проводить.
Неделя криптобезопасности на хабре. Прирост SSH-ключей увеличился вдвое.
Тем, кто так же попадает из поисковой системы сюда, то в 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 все ок.
Only those users with full accounts are able to leave comments. Log in, please.