И все же вопрос остается нерешенным относительно того, как задействовать Rutoken ECP2 в качестве HSM на сервере?

К сожалению мы такую задачу не решали, так как это очень нестандартное применение.

Сложно что-то рекомендовать, но есть например opensource с неплохими отзывами.

У Рутокен относительно демократичная цена.

А какой HSM вы порекомендуете, да еще за относительно небольшую цену?

И все же вопрос остается нерешенным относительно того, как задействовать Rutoken ECP2 в качестве HSM на сервере?

Ознакомьтесь с инструкцией по хранению ключей на рутокене из статьи на портале документации.
Счетчик подписей на токене учитывает только подписи, сделанные отечественными криптоалгоритмами.

Светлана, большое спасибо за описание схемы аутентификации OpenSSH.

По поводу приведенной инструкции, там ведь речь идет только о клиентских ключах для аутентификации клиента?

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

Меня интересует, как настроить sshD (сервер, а не клиент), чтобы он хранил серверный (а не клиентский) закрытый ключ в Rutoken, соответственно в таком случае USB dongle подключается к серверу, а не к рабочей станции.

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

У вас есть подобная инструкция?

Клиентский ключ как описано в инструкции я уже настраивал, с этим вопросов нет.

Счетчик подписей на токене учитывает только подписи, сделанные отечественными криптоалгоритмами. Ограничить количество ssh-подключений, задать смену режима обращения к токену и внести прочие ограничения аутентификации вы можете посредством подбора/написания/модификации PAM-модулей. Это стандартный механизм Linux для обеспечения требуемой функциональности

RSA использует асимметричное шифрование для создания ключа сеанса. В отличие от DH, пара открытого/закрытого ключей играет большую роль.

Вот как это происходит:
Клиент и сервер обмениваются двумя простыми числами (x и y), которые называют случайными числами.
Клиент генерирует pre-master secret (a), а затем использует открытый ключ сервера для его шифрования и отправки на сервер.
Сервер расшифровывает pre-master secret с помощью соответствующего закрытого ключа. Теперь обе стороны имеют все три входных переменных и смешивают их с некоторыми псевдослучайными функциями (PRF) для создания мастер-ключа.
Обе стороны смешивают мастер-ключ с ещё большим количеством PRF и получают совпадающие сеансовые ключи.

Также необходимо смотреть настройки openssh, а именно вызов функции C_GenearteRandom из PKCS#11.
Вам могут быть полезны следующие ссылки:
OpenSSH "Entropy Gathering Daemon"
OpenSSH с switch - with-egd-pool

Возможно ли хранение серверных ключей OpenSSH в Rutoken ECP2?
Т.е. ключа типа /etc/ssh/ssh_host_rsa_key
http://web.archive.org/web/202007310956 … eys/2495/6

https://framkant.org/2017/10/strong-aut … re-tokens/
Rutoken настраивается аналогично?

    # ssh-agent -a /root/yubikey-agent
    setenv SSH_AUTH_SOCK /root/yubikey-agent;
    setenv SSH_AGENT_PID 10894;
    echo Agent pid 10894;
    # setenv SSH_AUTH_SOCK /root/yubikey-agent;
    # ssh-add -s /usr/local/lib/opensc-pkcs11.so
    Enter passphrase for PKCS#11: 
    Card added: /usr/local/lib/opensc-pkcs11.so
    # ssh-add -l
    2048 SHA256:qBbMpdbUeabLe4PnfjrjPbGPu8zfbkbK+ni4mXOnV24 /usr/local/lib/opensc-pkcs11.so (RSA)

    # ssh-keygen -D /usr/local/lib/opensc-pkcs11.so > /etc/ssh/yubikey_host_key.pub
    # echo "HostKey /etc/ssh/yubikey_host_key.pub" >> /etc/ssh/sshd_config
    # echo "HostKeyAgent /root/yubikey-agent" >> /etc/ssh/sshd_config

Возможен ли доступ к нему сервера SSH без запроса пина Rutoken?
А вообще SSH агент как часто спрашивает аппаратный пин? Это настраиваемо?

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

Количество SSH подключений косвенно учитывается внутренними счетчиками Rutoken, которые вероятно не подделать так просто?
Наверно, какие-то операции типа подписи RSA2048 и т.п.?

Смутно представляю, какие асимметричные операции выполняются во время проверки аутентификации хостов SSH, в частности проверки самого сервера (защита от MITM).

Кстати, качество генерируемого симметричного сессионного ключа как-то зависит от криптостойкости асимметричных ключей, используемых для создания сессии? Или сессионный ключ - чистый рандом?

Например, есть ли разница в качестве сессионного ключа для вариантов использования RSA2048 и RSA4096 для установки сессии? От чего зависит качество сессионного ключа? Только от его рандомности и насколько безопасно он был передан другой стороне?

Нельзя ли его частично хотя бы генерировать внутри Rutoken? Например, задействовать ГСЧ Рутокена?