Релиз OpenSSH 8.2 c поддержкой токенов двухфакторной аутентификации FIDO/U2F
14 февраля 2020 года
После четырёх месяцев разработки представлен релиз 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().
Источники[править]
Любой участник может оформить статью: добавить иллюстрации, викифицировать, заполнить шаблоны и добавить категории.
Любой редактор может снять этот шаблон после оформления и проверки.
Комментарии[править]
Если вы хотите сообщить о проблеме в статье (например, фактическая ошибка и т. д.), пожалуйста, используйте обычную страницу обсуждения.
Комментарии на этой странице могут не соответствовать политике нейтральной точки зрения, однако, пожалуйста, придерживайтесь темы и попытайтесь избежать брани, оскорбительных или подстрекательных комментариев. Попробуйте написать такие комментарии, которые заставят задуматься, будут проницательными или спорными. Цивилизованная дискуссия и вежливый спор делают страницу комментариев дружелюбным местом. Пожалуйста, подумайте об этом.
Несколько советов по оформлению реплик:
- Новые темы начинайте, пожалуйста, снизу.
- Используйте символ звёздочки «*» в начале строки для начала новой темы. Далее пишите свой текст.
- Для ответа в начале строки укажите на одну звёздочку больше, чем в предыдущей реплике.
- Пожалуйста, подписывайте все свои сообщения, используя четыре тильды (~~~~). При предварительном просмотре и сохранении они будут автоматически заменены на ваше имя и дату.
Обращаем ваше внимание, что комментарии не предназначены для размещения ссылок на внешние ресурсы не по теме статьи, которые могут быть удалены или скрыты любым участником. Тем не менее, на странице комментариев вы можете сообщить о статьях в СМИ, которые ссылаются на эту заметку, а также о её обсуждении на сторонних ресурсах.