The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

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

14.02.2020 11:14

После четырёх месяцев разработки представлен релиз 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().


  1. Главная ссылка к новости (https://lists.mindrot.org/pipe...)
  2. OpenNews: В OpenSSH добавлена поддержка универсальной двухфакторной аутентификации
  3. OpenNews: Релиз OpenSSH 8.1
  4. OpenNews: В OpenSSH добавлена защита от атак по сторонним каналам
  5. OpenNews: Релиз OpenSSH 8.0
  6. OpenNews: Уязвимости в реализациях SCP из OpenSSH, PuTTY и WinSCP
Лицензия: CC-BY
Тип: Программы
Ключевые слова: openssh, fido, u2f
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (101) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 11:43, 14/02/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    "предварительно собрав openssh со встроенной поддержкой библиотеки-прослойки (--with-security-key-builtin), или выставить переменную окружения SSH_SK_PROVIDER, указав путь к внешней библиотеке libsk-libfido2.so (export SSH_SK_PROVIDER=/path/to/libsk-libfido2.so)."

    как то еще не для "домохозяек" :))

     
     
  • 2.25, Crazy Alex (ok), 14:04, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Где ssh и где домохозяйки? И вообще, дальнейшее - к дистрибутивам.
     
  • 2.32, Аноним (32), 14:45, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И часто домохозяйки ssh пользуются?
     

  • 1.2, edv (?), 11:51, 14/02/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    YubiKey из opensource стал closed-source. Поделитесь, кто в курсе открытых аналогов?

    Кстати, как сейчас с их доставкой в РФ? Не посадють?

    Кто-нибудь пробовал заказывать Librem Key от Purism?

     
     
  • 2.8, Ольга (??), 12:05, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не посодют. Официально их распространяет the_kernel, через softline.
     
  • 2.14, anonymous (??), 12:18, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Solo / Nitrokey
     
  • 2.22, coaxmetal (?), 13:38, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Юзаю Nitrokey Pro, всё прекрасно работает из коробки
     
     
  • 3.71, Аноним (71), 09:29, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Плюсую Nitrokey Pro

    https://gentoo.org/news/2019/04/16/nitrokey.html

     
     
  • 4.81, нах. (?), 14:30, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Плюсую Nitrokey Pro

    Encrypted Backups
    Nitrokey HSM supports key backup to protect against
    data loss.
    это та херня, на которой они якобы позволяют строить pki.

    Расходимся, тут не на что смотреть.
    Опять у разработчиков представления о безопасности решения на уровне младшей группы детского сада.

     
  • 2.26, Crazy Alex (ok), 14:05, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Trezor. Он вообще биткоин-кошелёк, но и fido-токеном тоже быть умеет.
     
  • 2.29, fi (ok), 14:22, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > Кстати, как сейчас с их доставкой в РФ? Не посадють?

    последние веяние - лотерея: могут случайно выбрать, тогда посадка.

    и еще, теперь слово crypt вне закона.

     

  • 1.3, Аноним (3), 11:56, 14/02/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Что-то не могу подключиться теперь: на сервере ключ не принимает, а локально меня не просит его разблокировать. Что я опять сломал?
     
  • 1.4, Аноним (4), 11:57, 14/02/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    А почему FTP в разрезе HTTP считается устаревшим и не нужным протоколом.
    А тот же SSH в разрезе HTTPS и к примеру RESTful не считается устаревшим.
     
     
  • 2.13, Аноним (13), 12:15, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    FTP - 1971 год
    SSH - 1995 год

    А теперь внимание вопрос для товарища гуманитария: "Почему FTP считается устаревшим?"

     
     
  • 3.18, анон (?), 13:03, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    и что ты предлагаеш взамет FTP? WebDav что-ли? ЛОЛ
     
     
  • 4.27, Crazy Alex (ok), 14:06, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • +11 +/
    sftp?
     
  • 3.31, Ю.Т. (?), 14:32, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Архитектура фон Неймана - 1948 год.
     
     
  • 4.48, GentooBoy (ok), 20:07, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Если бы он был такой же проворный как Ларри Эллисон то деньжат хватило бы еще и пра правнукам
     
     
  • 5.51, Ю.Т. (?), 20:25, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Если бы он был такой же проворный как Ларри Эллисон то деньжат
    > хватило бы еще и пра правнукам

    Он и без того не остался внакладе.

     
  • 5.73, нах. (?), 10:40, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Если бы он был такой же проворный как Ларри Эллисон то деньжат
    > хватило бы еще и пра правнукам

    А мы бы до сих пор пользовались холлеритовским табулятором, у кого денег хватит, остальные - счетами, угу.

    К счастью, он не был такой проворный, и проворонил бохатство.


     
  • 2.33, Аноним (32), 14:48, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А почему FTP в разрезе HTTP считается устаревшим и не нужным протоколом.

    В любом разрезе, протокол, использующий два соединения, при наличии альтернатив, использующих одно — будет устаревшим.

     
     
  • 3.42, пох. (?), 19:10, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    любой протокол, использующий порт, отличный от 443 - будет тоже устаревшим, по той же самой причине.

    Макака настраивала файрвол, написанный таким же низшим приматом.

    Ну ничего, ничего, скоро-скоро прекрасный http3 во все дыры, написанный каким-то осьминогом - и руки из жопы, и голова в жопе, и сама эта жопа - с ушами. Вот тут-то мы над владельцами г-нофайрволов и похохочем. Если успеем, конечно, пока самих не завалят дешевым и эффективым ddos.

     

  • 1.5, Аноним (5), 11:59, 14/02/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Че-то как-то сложно и неудобно. А можно просто кож ввести из Google Authenticator?
     
     
  • 2.6, кэп (?), 12:02, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Можно.
     
  • 2.7, Ольга (??), 12:03, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Можно, соответствующий libpam должен быть в репозитории.
    Но может быть несовместим с некоторыми клиентами, которые не ожидают иных запросов ввода, кроме логина/пароля.
     
  • 2.11, Аноним (11), 12:09, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    зачем использовать Google Authenticator, когда есть свободные аналоги? FreeOTP, например
     
     
  • 3.16, Аноним (16), 12:59, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    andOTP и Aegis получше будут. На крайняк FreeOTP+, там хоть экспорт есть.
     
     
  • 4.38, Аноним (38), 17:40, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >там хоть экспорт есть.

    Однажды нужно было экспорт из FreeOTP сделать, только через adb backup вышло вручную вытащить базу. Так что да, нормальный экспорт это плюс

     
     
  • 5.62, нах. (?), 00:31, 15/02/2020 Скрыто модератором
  • –1 +/
     

  • 1.10, Броколь (?), 12:08, 14/02/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Может еще привязку к телефону сделать?
     
     
  • 2.30, Обдолбим (?), 14:28, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вы, батенька, мечта любого маркетолога-спамера
     

  • 1.12, Аноним (13), 12:12, 14/02/2020 Скрыто модератором [﹢﹢﹢] [ · · · ]
  • –3 +/
     
     
  • 2.15, авторы (?), 12:36, 14/02/2020 Скрыто модератором
  • –2 +/
     

  • 1.17, Аномномномнимус (?), 12:59, 14/02/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Как это бекапить?
     
     
  • 2.21, нах. (?), 13:30, 14/02/2020 Скрыто модератором
  • –4 +/
     
     
  • 3.23, Аномномномнимус (?), 13:40, 14/02/2020 Скрыто модератором
  • +1 +/
     
     
  • 4.43, пох. (?), 19:20, 14/02/2020 Скрыто модератором
  • –2 +/
     
  • 3.24, Аноним (24), 13:52, 14/02/2020 Скрыто модератором
  • +/
     
  • 2.28, Crazy Alex (ok), 14:11, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Зависит от ключа. Если с "секьюрным элементом" - никак, и оно будет с закрытым кодом, так что верьте разработчикам на слово. Если что-то открытое - то бэкап или есть, или не особо сложно допилить. У трезора всё генерируется из одного базового ключа, который можно забэкапить при инициалищации железки.
     
     
  • 3.44, пох. (?), 19:23, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Зависит от ключа. Если с "секьюрным элементом" - никак, и оно будет
    > с закрытым кодом, так что верьте разработчикам на слово. Если что-то
    > открытое - то бэкап или есть, или не особо сложно допилить.
    > У трезора всё генерируется из одного базового ключа, который можно забэкапить
    > при инициалищации железки.

    поэтому он еще большее г-но чем "с закрытым кодом", где хотя бы можно поверить разработчикам на слово.

    Скажите, а _нормальных_ шва...6еш...э...открытых решений человечество еще так и не родило? Ну что же, жги, Господь! Тут и двух праведников не наберется, какие нахрен три.

     
     
  • 4.53, Crazy Alex (ok), 20:41, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Дядь, проходи со своими ынтырпрайзами мимо Мне надо чтобы работало, а не чтобы ... большой текст свёрнут, показать
     
     
  • 5.58, нах. (?), 00:11, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    какой, в опу, интерпрайс с сесехе Меня интересуют мои собственные системы даж... большой текст свёрнут, показать
     
  • 4.57, Fedd (ok), 23:54, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    С чего это Юбики дырявый? Не откроешь а зря, первым же предложением там For security, the firmware on the YubiKey does not allow for secrets to be read from the device after they have been written to the device. Therefore you cannot duplicate or back up a YubiKey or Security Key.
     
     
  • 5.59, нах. (?), 00:20, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    он не в этом месте дырявый (хотя оно, скорее всего, тоже вызовет вопросы - например, точно ли ты единственный, у кого есть копия - коли механизм слива старательно предусмотрен, очень трудно поверить, что он - одноразовый)

    там то что на нем понареализовано, включая бесполезный u2f - сплошной ад, трэш и п-ц.

    Не, для gmail'а-то - ок, а это и есть его основное назначение. Главное, писем с паролями в том гмыле не храни.

     

  • 1.19, Аноним (19), 13:04, 14/02/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Не понимаю, зачем нужны отдельные _sk-типы ключей на сервере?
    Ведь можно использовать обычные RSA или Ed25519, достаточно лишь модифицировать клиента, чтобы на нём не было реального секретного ключа (а вместо него лишь дескриптор, отпечаток или публичный ключ), и все криптографические операции с ключами унести на внешнее устройство через PKCS#11 или что-то подобное на USB-токен.
     
     
  • 2.20, нах. (?), 13:28, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    проблема в том, что дерьмовые поделки а-ля убикей НЕ УМЕЮТ ssh-протокол (даже в той его небольшой части, где, собственно, шифрование)

    поэтому просто так "унести" на них криптографию - не получится.
    Вот и приходится хранить ключ который не ключ, но который позволяет создать сессию, а потом уже, внутри нее - лазить к токену за собственно данными.

     
  • 2.56, gogo (?), 23:42, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    таки для того, чтобы не страшно было брелок потерять )
     
     
  • 3.60, нах. (?), 00:22, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    нахер он тебе нужен, если его не страшно потерять? Ключ от квартиры тоже не страшно потерять, запасной-то ты под коврик положил заранее? Ню-ню...

    P.S. нет, *те* ключи не помогут тебе, если ты потерял брелок, это место у них вполне разумно сделано.

     
     
  • 4.78, anonymous (??), 14:21, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Чего плохого в восстановлении ключа из seed? Запомнить, например, 24 слова на всю жизнь вполне возможно.

    Если тем, что формально это не фактор "владею", а "знаю", то и что? Как это мешает решить бытовые проблемы с постоянными рисками компроментации паролей и ключей шифрования? Эти 24 слова тебе нужно применять крайне редко и в максимально защищённой среде.

     
     
  • 5.85, нах. (?), 16:52, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    в том, что нет ни малейших гарантий, что его можешь восстановить только ты как ... большой текст свёрнут, показать
     
     
  • 6.94, anonymous (??), 18:23, 16/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > в том, что нет ни малейших гарантий, что его можешь восстановить только ты.

    Гарантия в том, что никто другой не знает твою последовательность слов.

    А конкретно в моём случае запомнена не всё последовательность, а половина. А вторая половина записана ручкой на бумаге, запломбирована и находится в недоступном для злоумышленников месте.

    > как минимум, такой seed должен вводиться - тобой,

    Именно так я и делаю в Trezor. Там запускаешь восстановление из seed и вводишь последовательность, которую генерируешь как хочешь (хоть просто тыкая пальцем в распечатанный словарь).

    > То есть уже неизвестно, владеешь ты ключом или нет.

    Это какая-то XY-проблема. Изначальная задача аутентифицировать пользователя, и не важно то, через пароль это делается, ключ или ещё что. Важно, чтобы только конкретный пользователь мог пройти аутентификацию под его учётную запись (и никто другой). И можно набросать модель угроз. Основные угрозы -- это утечка пароля (чего в данном случае не возможно), потерянное устройство (защищено Trezor-ом, а тот PIN-кодом) и т.п. Так что давайте переместим разговор в сторону конкретной угрозы, на которую вы бы хотели обратить внимание.

    > вполне немифический источник утечки.

    Прошу простить, но я не понял, что именно является источником утечки.

    > А токеном может воспользоваться любой, хакнувший твой компьютер или уговоривший тебя авторизоваться не с него.

    Как? Тот же Trezor требует ввести PIN-код и подтвердить каждое использование каждого ключа (то есть нужно механически взаимодействовать с Trezor-ом, чтобы им пользоваться). То есть теоретически, ты можешь авторизоваться даже с чужого компьютера, где логируется каждое действие; и единственное, что получит злоумышленник -- это одноразовую подпись. Хотя если пользоваться неправильно, то можно, конечно, слить и какой-то важный ключ.

     
     
  • 7.97, нах. (?), 11:48, 17/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    ну где гарантия-то? Механизм слива волшебного ключа (само по себе - дерьмо, не должно быть никаких волшебных ключей) - предусмотрен? Ну вот, рот есть - значит, сольет.

    Гарантия что его можно слить только однажды - не стоит бумаги, на которой написана.

    Зачем это делают трезоры - понятно, там риск вообще лишиться всех своих миллиардов оправдывает второй ключ под ковриком. А почему нет нормального решения, кроме approved by visa - совершенно непонятно.

     
     
  • 8.103, anonymous (??), 11:25, 18/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Я согласен, что добавление этого механизма -- это была бредовая идея Но во-перв... текст свёрнут, показать
     

  • 1.34, Аноним (34), 15:26, 14/02/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Так не совсем понял libopenssh2-dev или как его устанавливать?
     
  • 1.35, Michael Shigorin (ok), 16:45, 14/02/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > ecdsa-sha2-nistp256/384/521

    Гм, а "521" по ссылке точно не очепятка (дважды)?

     
     
  • 2.50, GentooBoy (ok), 20:16, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    нет, это такие кривые, хотя конечно многих приводит в замешательство и думают что ошибка
     
  • 2.79, anonymous (??), 14:23, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    BTW, лучше использовать ED25519. Он спроектирован гораздо защищённее к Timing атакам, работает быстрее, и автор вызывает больше доверия.
     

  • 1.36, Аноним (36), 16:54, 14/02/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > Ключевым улучшением в выпуске OpenSSH 8.2 стала возможность использования двухфакторной аутентификации при помощи устройств

    Зачем нужно делать поддержку в коде если всё это работало и раньше, через pam?

     
     
  • 2.39, Аноним (39), 18:50, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    OpenSSH, внезапно, работает не только на системах с PAM.
     
     
  • 3.40, пох. (?), 19:04, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    проверяли, точно-точно работает?
    А то как бы не оказалось - "работал". Еще лет десять назад.

     
     
  • 4.67, Аноним (39), 02:11, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Внезапно, родная ОС — OpenBSD — прекрасно живет с альтернативой под названием BSD auth. Что-то мне подсказывает, что в Windows PAM тоже отсутствует.  Дальше сами догадаетесь как проверять?
     
     
  • 5.74, нах. (?), 10:47, 15/02/2020 Скрыто модератором
  • –1 +/
     
  • 3.45, Crazy Alex (ok), 19:24, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А они бывают ещё, не музейные и не "от одарённых",  и без PAM? Даже на Qnx есть.
     
     
  • 4.68, Аноним (39), 02:14, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Одно дело «в ОС можно использовать PAM», и другое — когда таковой является частью непосредственно ОС, а не ставится в качестве дополнительной фичи. И, да, PAM ужасен и, слава богам, не так распространён, как кажется некоторым.
     
     
  • 5.89, Crazy Alex (ok), 17:46, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Чем именно ужасен и таки где его нет? А то ты написал кучу чего-то неконкретного, а понятно только то, что ты PAM за что-то не любишь - но не ясно даже, саму концепцию внешне настраиваемой авторизации или конкретную реализацию.
     
     
  • 6.90, PereresusNeVlezaetBuggy (ok), 23:00, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Чем именно ужасен и таки где его нет? А то ты написал
    > кучу чего-то неконкретного, а понятно только то, что ты PAM за
    > что-то не любишь - но не ясно даже, саму концепцию внешне
    > настраиваемой авторизации или конкретную реализацию.

    PAM подгружает модули авторизации внутри одного процесса. Сама концепция плагинов-то не плоха, а вот соседство написанных разными лицами кусков кода в одном крайне чувствительном процессе — уже идея так себе.

    Ну а то, что синтаксис для того, чтобы этот оркестр взлетел, напоминает кошмар времён Samba 1.x я вообще молчу. Не, могло быть и хуже, конечно, и при должном старании (как правило, со стороны разработчиков дистрибутива) оно в дефолтах работает. Но ни разу не помню, чтобы ощущения после работы с PAM были «ой как клёво».

    Справедливости ради, BSD auth тоже есть за что пинать. Но оно хотя бы понадёжнее будет.

     
     
  • 7.98, нах. (?), 11:50, 17/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > PAM подгружает модули авторизации внутри одного процесса.

    причем через callback'и, с указателями на указатели на указатели.
    Поэтому надежно оно не будет никогда и ни у кого.

    Ну а чо вы хотите - зато - ентер-прайс (идею сперли то ли у солярки, то ли у aix)

     
  • 2.46, пох. (?), 19:30, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >> Ключевым улучшением в выпуске OpenSSH 8.2 стала возможность использования двухфакторной аутентификации при помощи устройств
    > Зачем нужно делать поддержку в коде если всё это работало и раньше,
    > через pam?

    затем, что через pam, внезапно, не работало.
    Можно было только подменить одну аутентификацию другой. Не предназначен он для такого.

    Впрочем, и сейчас аутентификация, на самом деле, не двухфакторная. Примитивный пароль на ключ не является полноценным вторым фактором, поскольку находится тоже у клиента, а не на сервере, где ему положено быть.
    Почему ssh двадцать лет не могут научить спрашивать пароль ПОСЛЕ авторизации ключом - ну так - макаки, сэр.

     
     
  • 3.52, GentooBoy (ok), 20:27, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >Почему ssh двадцать лет не могут научить спрашивать пароль ПОСЛЕ авторизации ключом - ну так - макаки, сэр.

    лол спасибо поржал, сразу вспомнил басню мартышка и очки

     
  • 3.54, Аноним (54), 22:46, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > спрашивать пароль ПОСЛЕ авторизации ключом

    Кто сильно беспокоится - может завернуть 22й порт в Ipsec  в транспортном режиме. После того, как к лебедю или еноту прикрутят сабж.

     
  • 3.69, Аноним (39), 02:15, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Харе прикидываться чужим ником.
     
  • 3.80, anonymous (??), 14:28, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > затем, что через pam, внезапно, не работало.
    > Можно было только подменить одну аутентификацию другой.

    Вообще-то нет, двухфакторная авторизация прекрасно работала и работает. Тупо ставишь нужный модуль PAM и добавляешь строчки в нужные книги.

     
     
  • 4.82, anonymous (??), 14:30, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    s/книги/конфиги/ (автозамена)
     

  • 1.37, Аноним (37), 17:14, 14/02/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    https://web.archive.org/web/20190128070703/https://bugzilla.mindrot.org/show_bug.cgi?id=2319
     
     
  • 2.47, пох. (?), 19:38, 14/02/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > https://web.archive.org/web/20190128070703/https://bugzilla.mindrot.org/show_bug.cgi?id=2319

    ну как обычно - заболтать, вместо того чтоб самому прочитать (сперва спек u2f, потом, о Б-же, lgpl - похоже он правда т..пой настолько, что не понимает разницы, и читать напрочь не хочет) - потом изобрести тот же самый велосипед, но с треугольными колесами (надо признать, что тот-то был - с квадратными) и гордо объявить авторство.

    Впопенсорсе - перевод чужого труда и времени.

     
     
  • 3.70, Аноним (37), 06:33, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ты на дату публикации посмотри.
     
     
  • 4.77, нах. (?), 14:17, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ты на дату публикации посмотри.

    Reported: 2014-11-19 06:53
    о том и речь - утопили идею в дурацких вообще не относящихся к патчу придирках, ревьюеру лень было, видите ли, читать документацию и лицензию, ему все должны были принести на блюдечке и на коленях подать к рассмотрению. Причем автор проборолся пару лет, но так и плюнул - у него-то уже два года все что надо и так работало.

    Опенусёрсе как оно есть. Перевод в помойку чужого труда и времени.

     
     
  • 5.91, PereresusNeVlezaetBuggy (ok), 23:04, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >> Ты на дату публикации посмотри.
    > Reported:  2014-11-19 06:53
    > о том и речь - утопили идею в дурацких вообще не относящихся
    > к патчу придирках, ревьюеру лень было, видите ли, читать документацию и
    > лицензию, ему все должны были принести на блюдечке и на коленях
    > подать к рассмотрению. Причем автор проборолся пару лет, но так и
    > плюнул - у него-то уже два года все что надо и
    > так работало.
    > Опенусёрсе как оно есть. Перевод в помойку чужого труда и времени.

    Как будто мир closed source чем-то в этом плане отличается. А то у меня есть историй про то как компании от денег отказываются — не потому что предлагают мало, а потому что «не хотим дорабатывать, и всё» (как правило, потому что оригинальных разработчиков давно прогнали, понабрав взамен эффективных менеджеров, ну да не суть).

     
     
  • 6.99, нах. (?), 11:53, 17/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Как будто мир closed source чем-то в этом плане отличается.

    нет ножек, нет варенья - там ты хотя бы этот мир не пытаешься улучшать, и заранее знаешь что все зависит от момента, когда именно разогнали разработчиков и наняли "разработчиков на игогошечке".

    В аналогичном случае - ну хакнул бы кто-то dll'ку для своей пользы, и не терял бы время на бесполезные объяснения и уговоры - уже меньше потерь.

     

  • 1.49, крок (?), 20:15, 14/02/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Инклюд - два года жаждил!
     
  • 1.55, Аноним (54), 23:32, 14/02/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Чота мне это ихнее U2F как-то не вдохновляет Опять равнение на идиотов, у котор... большой текст свёрнут, показать
     
     
  • 2.61, нах. (?), 00:29, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > На USB-токен вполне можно вкорячить три или четыре вот таких свича

    можно. И кому от чего они помогут, если у тебя его отожмут пацаны?
    Или ты собираешься каждый раз, заходя на свой локалхост, сперва выставлять микроскопическими свитчами свой супер-секретный пароль, а потом еще и старательно скручивать их в неправильное положение? Не забывая, понятен, прятаться под стол, пока крутишь, а то ж камеры!

    Не кури эту гадость. Идея еще глупее чем ubikey.

    Ключ вполне может храниться в открытом виде, задача в том, чтобы прочитать его оттуда было невозможно банальным способом, типа выпаивания чипа.

     
     
  • 3.63, Аноним (54), 01:33, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Мне. От утечки. Если украли - пусть крутят, три попытки - и досвидос. Если стоят за плечом - блокировочная комбинация и тоже досвидос. От камер и микрофонов (каждый щелчок уникален же!!!11) тоже методы есть.
    А насчёт выпаивания чипа - сомневаюсь, что у производителей этих бирюлек своё литографическое оорудование и они сами пекут чипы, причём каждый уникален и реверс-инжинирить каждый придётся независимо от других. 100% что оно собрано на простейшей комплектухе и содержимое ппзу из не
     
     
  • 4.66, qwerty123 (??), 02:08, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >Если стоят за плечом - блокировочная комбинация и тоже досвидос.

    Досвидос, чувак, мы тебя больше не увидим!

    Если у тебя будут "стоять за плечами", то ключ к квартире, где деньги лежат,
    будет меньшей из твоих проблем.

     
  • 3.64, Аноним (54), 01:34, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Мне. От утечки. Если украли - пусть крутят, три попытки - и досвидос. Если стоят за плечом - блокировочная комбинация и тоже досвидос. От камер и микрофонов (каждый щелчок уникален же!!!11) тоже методы есть.
    А насчёт выпаивания чипа - сомневаюсь, что у производителей этих бирюлек своё литографическое оорудование и они сами пекут чипы, причём каждый уникален и реверс-инжинирить каждый придётся независимо от других. 100% что оно собрано на простейшей комплектухе и содержимое ппзу из неё дампится на раз, дизасемблится тоже без проблем и ключ - как на ладони.
     
     
  • 4.72, нах. (?), 10:36, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Мне. От утечки. Если украли - пусть крутят, три попытки - и

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

    > реверс-инжинирить каждый придётся независимо от других. 100% что оно собрано на
    > простейшей комплектухе и содержимое ппзу из неё дампится на раз, дизасемблится
    > тоже без проблем и ключ - как на ладони.

    "простейшая комплектуха" включает в себя pic'и и прочие memory-on-chip, где выпаивать, внезапно, нечего, сдампить после пережигания невозможно, производятся миллионными тиражами.
    Но и просто заказать у китайца партию специализированных чипов не так дорого, как тебе мнится (и уж точно выйдет в сборе дешевле чем какие-то бестолковые микропереключатели) - а в ubi-nano вряд ли поместится память на флэшечке, приклеенной эпоксидкой чтоб-никто-не-догадался (привет, оладьин)

    Так что вопрос только в том, насколько разработчики железа у них внимательные и аккуратные.
    У меня что-то хреновое предчувствие(c).

    Но это вовсе не означает, что нельзя сделать нормально и надежно. Но вместо этого мы имеем - "вообще-то оно кошелек" :-( И последний на всю Ресурсию банк, умеющий offline otp генератор встроенный прямо в кредитку (сюрприз, сюрприз, так можно было, при том что они производятся в микроколичествах), без пяти минут банкрот, ибо никто из его владельцев не имел счастья родиться в той же питерской подворотне, что один крысиный император.

     
     
  • 5.75, Аноним (54), 11:14, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > так ты ж уже накрутил?

    Если я уже сижу за клавой залогиненный и меня огрели по башке - токен, вобщем-то, и не нужен, сеанс уже открыт. А так - да, "вынь и перекрути" - это вопрос "гигиены" и правильных привычек. Тем более, что можно сделать и более современно - жк экранчик и три кнопки - вверх, вниз и установить. выставляешь последовательно цифры пин-кода, после первого обращения оно сбрасывается.
    > сдампить после пережигания невозможно

    Так и не нужно, если флэшка работает в любых руках.

     
     
  • 6.76, нах. (?), 14:14, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > - да, "вынь и перекрути" - это вопрос "гигиены" и правильных
    > привычек. Тем более, что можно сделать и более современно - жк

    Это вопрос геморроя.

    Да, можно сделать запрос пин-кода. Почему убиквитя и все прочие поделки этого не умеют - вопрос к их разработчикам.

    > Так и не нужно, если флэшка работает в любых руках.

    некоторые режимы, даже, afair, в убиквити, и некоторых других недоступных в рф поделках умеют пин. Но его должен спросить софт, в результате, надежность все равно никакая.

     
     
  • 7.83, anonymous (??), 14:39, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Почему убиквитя и все прочие поделки этого не умеют - вопрос к их разработчикам.

    Trevor умеет

     
     
  • 8.84, anonymous (??), 14:40, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    s Trevor Trezor автозамена ... текст свёрнут, показать
     
  • 8.86, нах. (?), 16:56, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    он разьве умеет это с кнопок С компьютера-то и тот немец умеет, и, afair, убикв... текст свёрнут, показать
     
     
  • 9.95, anonymous (??), 18:28, 16/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Во-первых Trezor T умеет это с собственного экрана без участия компьютера Во-... текст свёрнут, показать
     
  • 8.88, нах. (?), 17:05, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    а, блин посмотрел видео Нда не могу сказать, что мне нравится идея лучше б... текст свёрнут, показать
     
     
  • 9.96, anonymous (??), 18:29, 16/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Я немного тупенький, поэтому лучше бы они _что_ сделали отключаемым ... текст свёрнут, показать
     
     
  • 10.100, нах. (?), 11:57, 17/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    жуть с перемешиванием цифр для one, понятно, почему по другому нельзя, но для в... текст свёрнут, показать
     
     
  • 11.104, anonymous (??), 11:28, 18/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вообще, я видел как охраняется один военный объект Там тоже пинкоды путаются... текст свёрнут, показать
     
  • 7.92, Аноним (54), 00:12, 16/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Но его должен спросить софт

    Это какой-то неправильный пин. Прикол был бы в том, что пин спрашивает сам чип флэшки, и именно через минимальный hid-ингтерфейс на самой флэшке. Причём он корректность пина проверить не может - просто слепо раскодирует ключ тем пином, который дали. Попал - молодец, не попал - сервер получает неверный респонс. Три попытки - сервер помечает флэшку как дискредитированную.

     
     
  • 8.101, нах. (?), 11:58, 17/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    в смысле, подключенный к флэшке, а не к компьютеру Ну вон трезор попытался Инт... текст свёрнут, показать
     
     
  • 9.102, Аноним (54), 23:12, 17/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    У меня дисциплина, самообладание и мелкая моторика А для нервных можно сделать ... текст свёрнут, показать
     

  • 1.65, qwerty123 (??), 02:04, 15/02/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Для взаимодействия с устройствами, подтверждающими присутствие пользователя

    Поправил:

    "Для взаимодействия с устройствами, подтверждающими присуствие паяльника в нижнем отверстии пользователя"

     
     
  • 2.87, нах. (?), 16:57, 15/02/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Поправил:
    > "Для взаимодействия с устройствами, подтверждающими присуствие паяльника в нижнем отверстии
    > пользователя"

    фу, зачем ты так? Там же не сканер отпечатка, а банальная контактная кнопка, совершенно незачем пачкать хороший паяльник, можно самому "нажать".

    И так у них все.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру