The OpenNET Project / Index page

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

Релиз OpenSSH 8.0

18.04.2019 15:08

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

Основные изменения:

  • В ssh и sshd добавлена экспериментальная поддержка метода обмена ключами, стойкого к подбору на квантовом компьютере. Квантовые компьютеры кардинально быстрее решают задачу разложения натурального числа на простые множители, которая лежит в основе современных асимметричных алгоритмов шифрования и эффективно не решаема на классических процессорах. Предложенный метод основан на алгоритме NTRU Prime (функция ntrup4591761), разработанном для постквантумных криптосистем, и методе обмена ключами на базе эллиптических кривых X25519;
  • В sshd в директивах ListenAddress и PermitOpen прекращена поддержка устаревшего синтаксиса "host/port", реализованного в 2001 году в качестве альтернативы "host:port" для упрощения работы с IPv6. В современных условиях для IPv6 устоялся синтаксис "[::1]:22", а "host/port" часто путают с указанием подсети (CIDR);
  • В ssh, ssh-agent и ssh-add реализована поддержка ключей ECDSA в токенах PKCS#11;
  • В ssh-keygen размер ключа RSA по умолчанию увеличен до 3072 бит, в соответствии с новыми рекомендациями NIST;
  • В ssh разрешено использование настройки "PKCS11Provider=none" для переопределения директивы PKCS11Provider, заданной в ssh_config;
  • В sshd обеспечено отображение в логе ситуаций, когда соединение завершено при попытке выполнения команд, блокированных ограничением "ForceCommand=internal-sftp" в sshd_config;
  • В ssh при выводе запроса на подтверждение приёма нового хостового ключа, вместо ответа "yes" теперь воспринимается правильный fingerprint-отпечаток ключа (в ответ на приглашение подтвердить подключение пользователь может через буфер обмена скопировать отдельно полученный эталонный хэш, чтобы вручную не заниматься его сравнением);
  • В ssh-keygen обеспечено автоматическое увеличение номера последовательности в сертификате при создании цифровых подписей для нескольких сертификатов в командной строке;
  • В scp и sftp добавлена новая опция "-J", эквивалентная настройке ProxyJump;
  • В ssh-agent, ssh-pkcs11-helper и ssh-add добавлена обработка опции командной строки "-v" для увеличения информативности вывода (при указании данная опция передаётся и дочерним процессам, например, когда из ssh-agent вызывается ssh-pkcs11-helper);
  • В ssh-add добавлена опция "-T" для тестирования пригодности ключей в ssh-agent для выполнения операций создания и верификации цифровых подписей;
  • В sftp-server реализована поддержка расширения протокола "lsetstat at openssh.com", добавляющего для SFTP поддержку операции SSH2_FXP_SETSTAT, но без следования по символическим ссылкам;
  • В sftp добавлена опция "-h" для выполнения команд chown/chgrp/chmod с запросами, не использующими символические ссылки;
  • В sshd обеспечено выставление переменной окружения $SSH_CONNECTION для PAM;
  • Для sshd в ssh_config добавлен режим сопоставления "Match final", аналогичный "Match canonical", но не требующий включения нормализации имени хоста;
  • В sftp добавлена поддержка префикса '@' для отключения трансляции вывода команд, выполняемых в пакетном режиме;
  • При выводе содержимого сертификата при помощи команды "ssh-keygen -Lf /path/certificate" теперь отображается алгоритм, использованный удостоверяющим центром для заверения сертификата;
  • Улучшена поддержка окружения Cygwin, например обеспечено сравнение имён групп и пользователей без учёта регистра символов. Процесс sshd в порте для Cygwin изменён на cygsshd для того чтобы избежать пересечений с портом OpenSSH, поставляемым Microsoft;
  • Добавлена возможность сборки с экспериментальной веткой OpenSSL 3.x;
  • Устранена уязвимость (CVE-2019-6111) в реализации утилиты scp, позволяющая перезаписать произвольные файлы в целевом каталоге на стороне клиента при обращении к подконтрольному злоумышленнику серверу. Проблема заключается в том, что при применении scp сервер принимает решение о том, какие файлы и каталоги отправить клиенту, а клиент лишь проверяет корректность возвращённых имён объектов. Проверка на стороне клиента ограничена лишь блокированием выхода за границы текущего каталога ("../"), но не учитывает передачу файлов с именами, отличающимися от изначально запрошенных. В случае рекурсивного копирования (-r) кроме имён файлов подобным способом можно манипулировать и именами подкаталогов. Например, в случае копирования пользователем в домашний каталог файлов, подконтрольный атакующим сервер может выдать вместо запрошенных файлов файлы с именами .bash_aliases или .ssh/authorized_keys, и они будут сохранены утилитой scp в домашнем каталоге пользователя.

    В новом выпуске в утилиту scp добавлена проверка соответствия запрошенных и отданных сервером имён файлов, выполняемая на стороне клиента. При этом могут возникнуть проблемы с обработкой масок, так как символы раскрытия масок могут по разному обрабатываться на стороне сервера и клиента. На случай, если из-за подобных различий клиент перестанет принимать файлы в scp добавлена опция "-T", позволяющая отключить проверку на стороне клиента. Для полноценного исправления проблемы требуется концептуальная переделка протокола scp, который сам по себе уже устарел, поэтому вместо него рекомендовано использовать более современные протоколы, такие как sftp и rsync.



  1. Главная ссылка к новости (http://lists.mindrot.org/piper...)
  2. OpenNews: Релиз OpenSSH 7.8
  3. OpenNews: Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2
  4. OpenNews: Ещё одна уязвимость в OpenSSH, позволяющая определить наличие пользователей
  5. OpenNews: Уязвимости в реализациях SCP из OpenSSH, PuTTY и WinSCP
  6. OpenNews: Выявлен 21 вид вредоносных программ, подменяющих OpenSSH
Лицензия: CC-BY
Тип: Программы
Ключевые слова: openssh, ssh
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (14) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, Вася (??), 15:20, 18/04/2019 Скрыто модератором [﹢﹢﹢] [ · · · ]
  • +2 +/
     
  • 1.2, Аноним (2), 15:22, 18/04/2019 Скрыто модератором [﹢﹢﹢] [ · · · ]
  • –2 +/
     
  • 1.7, J.L. (?), 17:19, 18/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    //оффтоп
    "scp, который сам по себе уже устарел ... более современные протоколы, такие как ... rsync"

    ничего про сам протокол, но слово:
    rsync Первый выпуск 19 июня 1996

     
     
  • 2.8, нах (?), 17:30, 18/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > ничего про сам протокол, но слово:

    а вот откройте анонс 1996го года, и прочтите в нем: rsync is a rcp replacement with some special features

    правда, по факту получилось как всегда - special features понадобились не только лишь всем, а rcp еще лет десять прожил после того, потому что иногда надо просто и без лишнего геморроя скопировать ровно один файлик.

     

  • 1.9, Аноним (9), 17:55, 18/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > OpenSSL 3.x

    Это что за зверь?

     
     
  • 2.12, Аноним (12), 23:21, 18/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    OpenSSL 3.0 is a major release and will be a significant change to the internal architecture of OpenSSL.

    https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/

     
  • 2.15, нах (?), 10:55, 19/04/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    "инвесторы любят большие числа".
    А потом будет версия 40.
     

  • 1.10, AnonPlus (?), 19:36, 18/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > В ssh-keygen размер ключа RSA по умолчанию увеличен до 3072 бит, в соответствии с новыми рекомендациями NIST;

    Ну, до 2030 года 2048 считается безопасным в соответствии с этими самыми рекомендациями. А загадывать на 10 лет вперед я бы не рискнул, прогресс заметно ускоряется с каждым годом, возможно, к тому времени уже что-то совсем иное будет.

     
     
  • 2.11, h31 (ok), 21:53, 18/04/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Берут на вырост. Какой-нибудь OpenSSH 8.x попадет в RHEL 8, который вполне может дожить до 2030 года.
     
     
  • 3.13, Аноним (13), 00:17, 19/04/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    И что мешает увеличить размер ключа в каком-нибудь 8.x?
    Тут дело не в этом. Нужно рассчитывать на то, что сгенерированные пользователями ключи будут использоваться длительное время.
     
     
  • 4.14, Stax (ok), 09:14, 19/04/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > И что мешает увеличить размер ключа в каком-нибудь 8.x?

    Ничего, в жизненном цикле 6-ки вроде как раз увеличивали. Есть все механизмы, чтобы сделать это на уровне конфигов.

     
  • 4.16, нах (?), 11:04, 19/04/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    чтобы утекший или забытый ключ десять лет назад уволившегося сотрудника еще лет десять подходил бы ко всем дверям, правильно.
    Нет бы наоборот, принудительно удалять все ключи старше трех месяцев (в отличие от идиотских политик принудительной смены паролей - эта как раз имеет смысл - если, конечно, не пользоваться сертификатами по каким-то религиозным причинам)

     

  • 1.17, Чёртик (?), 22:39, 19/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Последнее время ушёл на «Dropbear» с файерволом 22 по ip.
     
  • 1.18, Аноним (18), 23:56, 19/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А поддержка UDP в SOCKS (-o DynamicForward / -D) будет?
     

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



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

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