🥇Релиз 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» или выставить переменную окружения SSH_SK_PROVIDER, указав путь к внешней библиотеке libsk-libfido2.so (export SSH_SK_PROVIDER=/path/to/libsk-libfido2.so). Возможна сборка openssh со встроенной поддержкой библиотеки-прослойки (—with-security-key-builtin), в этом случае необходимо выставить параметр «SecurityKeyProvider=internal».
Далее нужно запустить «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).

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

В sshd_config добавлена директива Include, позволяющая включать содержимое других файлов в текущую позицию файла конфигурации (при задании имени файла допускается применение glob-масок);
В ssh-keygen добавлена опция «no-touch-required», отключающая необходимость физического подтверждения доступа к токену при генерации ключа;
В sshd_config добавлена директива PubkeyAuthOptions, объединяющая разные опции, связанные с аутентификацией по открытым ключам. В настоящее время поддерживается только флаг «no-touch-required» для пропуска проверки физического присутствия при авторизации при помощи токена. По аналогии в файл authorized_keys добавлена опция «no-touch-required»;
В ssh-keygen добавлена опция «-O write-attestation=/path», позволяющая записать дополнительные аттестационные сертификаты FIDO при генерации ключей. OpenSSH пока не использует данные сертификаты, но они в дальнейшем могут быть использованы для проверки размещения ключа в заслуживающем доверия аппаратном хранилище;
В настройках 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().