OpenSSH 8.2 c поддержкой токенов двухфакторной аутентификации FIDO/U2F

После четырёх месяцев разработки представлен релиз OpenSSH 8.2, открытой реализации клиента и сервера для работы по протоколам SSH 2.0 и SFTP.

Ключевым улучшением в выпуске OpenSSH 8.2 стала возможность использования двухфакторной аутентификации при помощи устройств, поддерживающих протокол U2F, развиваемый альянсом FIDO. U2F позволяет создавать недорогие аппаратные токены для подтверждения физического присутствия пользователя, взаимодействие с которыми производится через USB, Bluetooth или NFC. Подобные устройства продвигаются в качестве средства для двухфакторной аутентификации на сайтах, уже поддерживаются основными браузерами и выпускаются различными производителями, включая Yubico, Feitian, Thetis и Kensington.

Для взаимодействия с устройствами, подтверждающими присутствие пользователя, в OpenSSH добавлены новые типы ключей "ecdsa-sk" и "ed25519-sk", в которых используются алгоритмы цифровой подписи ECDSA и Ed25519, в сочетании с хэшем SHA-256. Процедуры взаимодействия с токенами вынесены в промежуточную библиотеку, которая загружается по аналогии с библиотекой для поддержки PKCS#11 и является обвязкой над библиотекой libfido2, предоставляющей средства для коммуникации с токенами поверх USB (поддерживается протоколы FIDO U2F/CTAP 1 и FIDO 2.0/CTAP 2). Подготовленная разработчиками OpenSSH промежуточная библиотека libsk-libfido2 включена в основной состав libfido2, как и HID-драйвер для OpenBSD.

Для аутентификации и генерации ключа необходимо указать в настройках параметр "SecurityKeyProvider=internal", предварительно собрав openssh со встроенной поддержкой библиотеки-прослойки (--with-security-key-builtin), или выставить переменную окружения SSH_SK_PROVIDER, указав путь к внешней библиотеке libsk-libfido2.so (export SSH_SK_PROVIDER=/path/to/libsk-libfido2.so). Далее нужно запустить "ssh-keygen -t ecdsa-sk" или, если ключи уже созданы и настроены, подключиться к серверу при помощи "ssh". При запуске ssh-keygen созданная пара ключей будет сохранена в "~/.ssh/id_ecdsa_sk" и может использоваться аналогично другим ключам.

Открытый ключ (id_ecdsa_sk.pub) следует скопировать на сервер в файл authorized_keys. На стороне сервера только проверяется цифровая подпись, а взаимодействие с токенами производится на стороне клиента (на сервере не нужно устанавливать libsk-libfido2, но сервер должен поддерживать тип ключей "ecdsa-sk"). Сгенерированный закрытый ключ (id_ecdsa_sk) по сути является дескриптором ключа, образующим реальный ключ только в сочетании с секретной последовательностью, хранимой на стороне токена U2F. В случае попадания ключа id_ecdsa_sk в руки атакующего, для прохождения аутентификации ему также потребуется получить доступ к аппаратному токену, без которого сохранённый в файле id_ecdsa_sk закрытый ключ бесполезен.

Кроме того, по умолчанию при выполнении любых операций с ключами (как при генерации, так и при аутентификации) требуется локальное подтверждение физического присутствия пользователя, например, предлагается коснуться сенсора на токене, что затрудняет проведение удалённых атак на системы с подключенным токеном. В качестве ещё одного рубежа защиты на этапе запуска ssh-keygen также может быть задан пароль для доступа к файлу с ключом.

В новой версии OpenSSH также объявлено о предстоящем переводе в разряд устаревших алгоритмов, использующих хеши SHA-1, в связи с повышением эффективности коллизионных атак с заданным префиксом (стоимость подбора коллизии оценивается примерно в 45 тысяч долларов). В одном из ближайших выпусков планируют отключить по умолчанию возможность использования алгоритма цифровых подписей по открытому ключу "ssh-rsa", который упоминается в оригинальном RFC для протокола SSH и остаётся широко распространённым на практике (для проверки применения ssh-rsa в своих системах можно попробовать подключиться по ssh с опцией "-oHostKeyAlgorithms=-ssh-rsa").

Для сглаживания перехода на новые алгоритмы в OpenSSH в одном из следующих выпусков по умолчанию будет включена настройка UpdateHostKeys, которая позволит автоматически перевести клиентов на более надёжные алгоритмы. Среди рекомендуемых для миграции алгоритмов упомянуты rsa-sha2-256/512 на базе RFC8332 RSA SHA-2 (поддерживается с OpenSSH 7.2 и используется по умолчанию), ssh-ed25519 (поддерживается с OpenSSH 6.5) и ecdsa-sha2-nistp256/384/521 на базе RFC5656 ECDSA (поддерживается с OpenSSH 5.7).

В версии OpenSSH 8.2 возможность подключения с использованием "ssh-rsa" пока оставлена, но данный алгоритм удалён из списка CASignatureAlgorithms, определяющего алгоритмы, допустимые для цифровой подписи новых сертификатов. Аналогично из поддерживаемых по умолчанию алгортимов обмена ключами удалён алгоритм diffie-hellman-group14-sha1. Отмечается, что использование SHA-1 в сертификатах сопряжено с дополнительным риском, так как атакующий имеет неограниченное время на поиск коллизии для существующего сертификата, в то время как время атаки на хостовые ключи ограничены таймаутом подключения (LoginGraceTime).

При выполнении ssh-keygen теперь по умолчанию применяется алгоритм rsa-sha2-512, который поддерживается начиная с OpenSSH 7.2, что может создать проблемы с совместимостью при попытке обработки сертификатов, заверенных в OpenSSH 8.2, на системах со старыми выпусками OpenSSH (для обхода проблемы при формировании подписи можно явно указать "ssh-keygen -t ssh-rsa" или использовать алгоритмы ecdsa-sha2-nistp256/384/521, поддерживаемые с OpenSSH 5.7).

Другие изменения:

В ssh-keygen добавлена опция "no-touch-required", отключающая необходимость физического подтверждения доступа к токену при генерации ключа;
В sshd_config добавлена директива PubkeyAuthOptions, объединяющая разные опции, связанные с аутентификацией по открытым ключам. В настоящее время поддерживается только флаг "no-touch-required" для пропуска проверки физического присутствия при авторизации при помощи токена. По аналогии в файл authorized_keys добавлена опция "no-touch-required";
В ssh-keygen добавлена опция "-O write-attestation=/path", позволяющая записать дополнительные аттестационные сертификаты FIDO при генерации ключей. OpenSSH пока не использует данные сертификаты, но они в дальнейшем могут быть использованы для проверки размещения ключа в заслуживающем доверия аппаратном хранилище;
В sshd_config добавлена директива Include, позволяющая включать содержимое других файлов в текущую позицию файла конфигурации (при задании имени файла допускается применение glob-масок);
В настройках ssh и sshd через директиву IPQoS теперь возможна установка режима приоритезации трафика LE DSCP (Lower-Effort Per-Hop Behavior);
В ssh при установке значения "AddKeysToAgent=yes", если ключ не содержит поля с комментарием, он будет добавлен в ssh-agent c указанием в качестве комментария пути к ключу. В ssh-keygen и ssh-agent в качестве комментариев в ключу также теперь используются метки PKCS#11 и имя субъекта X.509, вместо пути к библиотеке;
В ssh-keygen добавлена возможность экспорта PEM для ключей DSA и ECDSA;
Добавлен новый исполняемый файл ssh-sk-helper, используемый для изоляции библиотеки доступа к токенам FIDO/U2F;
В ssh и sshd добавлена сборочная опция "--with-zlib" для компиляции с поддержкой библиотеки zlib;
В соответствии с требованием RFC4253 в выводимом при подключении баннере обеспечен вывод предупреждения о блокировке доступа из-за превышения лимитов MaxStartups. Для упрощения диагностики невозможности подключиться в заголовке процесса sshd, видимого при использовании утилиты ps, обеспечено отображение числа аутентифицированных в данный момент соединений и состояния лимита MaxStartups;
В ssh и ssh-agent при вызове программы для вывода на экран приглашения, задаваемой через $SSH_ASKPASS, теперь дополнительно передаётся флаг с типом приглашения: "confirm" - диалог подтверждения (yes/no), "none" - информационное сообщение, "blank" - запрос пароля;
В ssh-keygen добавлена новая операция с цифровыми подписями "find-principals" для поиска в файле allowed-signers пользователя, связанного с указанной цифровой подписью;
Улучшена поддержка изоляции процесса sshd в Linux при помощи механизма seccomp: запрещены системные вызовы IPC, разрешены clock_gettime64(), clock_nanosleep_time64 и clock_nanosleep().