После пяти месяцев разработки представлен (http://lists.mindrot.org/pipermail/openssh-unix-dev/2019-Apr... релиз OpenSSH 8.0 (http://www.openssh.com/), открытой реализации клиента и сервера для работы по протоколам SSH 2.0 и SFTP.
Основные изменения:- В ssh и sshd добавлена экспериментальная поддержка метода обмена ключами, стойкого к подбору на квантовом компьютере. Квантовые компьютеры кардинально быстрее решают задачу разложения натурального числа на простые множители, которая лежит в основе современных асимметричных алгоритмов шифрования и эффективно не решаема на классических процессорах. Предложенный метод основан на алгоритме NTRU Prime (https://ntruprime.cr.yp.to/) (функция ntrup4591761), разработанному для постквантумных криптосистем, и методе обмена ключами на базе эллиптических кривых X25519;
- В sshd в директивах ListenAddress и PermitOpen прекращена поддержка устаревшего синтаксиса "host/port", реализованного в 2001 году в качестве альтернативы "host:port" для упрощения работы с IPv6. В современных условиях для IPv6 устоялся синтаксис "[::1]:22", а "host/port" часто путают с указанием подсети (CIDR);
- В ssh, ssh-agent и ssh-add реализована поддержка ключей ECDSA (https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signatu... в токенах 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;
- Устранена уязвимость (https://www.opennet.ru/opennews/art.shtml?num=49953) (CVE-2019-6111) в реализации утилита scp, позволяющая перезаписать произвольные файлы в целевом каталоге на стороне клиента при обращении к подконтрольному злоумышленнику серверу. Проблема заключается в том ,что при применении scp сервер принимает решение о том, какие файлы и каталоги отправить клиенту, а клиент лишь проверяет корректность возвращённых имён объектов. Проверка на стороне клиента ограничена лишь блокированием выхода за границы текущего каталога ("../"), но не учитывает передачу файлов с именами, отличающимися от изначально запрошенных. В случае рекурсивного копирования (-r) кроме имён файлов подобным способом можно манипулировать и именами подкаталогов.
Например, в случае копирования пользователем в домашний каталог файлов, подконтрольный атакующим сервер может выдать вместо запрошенных файлов файлы с именами .bash_aliases или .ssh/authorized_keys, и они будут сохранены утилитой scp в домашнем каталоге пользователя. В новом выпуске в утилиту scp добавлена проверка соответствия запрошенных и отданных имён файлов, выполняемая на стороне клиента. При этом могут возникнуть проблемы с обработкой масок, так как символы раскрытия масок могут по разному обрабатываться на стороне сервера и клиента. На случай, если из-за подобных различий клиент перестанет принимать файлы в scp добавлена опция "-T", позволяющая отключить проверку на стороне клиента. Для полноценного исправления проблемы требуется концептуальная переделка протокола scp, который сам по себе уже устарел, поэтому вместо него рекомендовано использовать более современные протоколы, такие как sftp и rsync.
URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/2019-Apr...
Новость: https://www.opennet.ru/opennews/art.shtml?num=50533
Круто, пойду обновляться и изучать новые возможности.
Ждем ебилдов
//оффтоп
"scp, который сам по себе уже устарел ... более современные протоколы, такие как ... rsync"ничего про сам протокол, но слово:
rsync Первый выпуск 19 июня 1996
> ничего про сам протокол, но слово:а вот откройте анонс 1996го года, и прочтите в нем: rsync is a rcp replacement with some special features
правда, по факту получилось как всегда - special features понадобились не только лишь всем, а rcp еще лет десять прожил после того, потому что иногда надо просто и без лишнего геморроя скопировать ровно один файлик.
> OpenSSL 3.xЭто что за зверь?
OpenSSL 3.0 is a major release and will be a significant change to the internal architecture of OpenSSL.
"инвесторы любят большие числа".
А потом будет версия 40.
> В ssh-keygen размер ключа RSA по умолчанию увеличен до 3072 бит, в соответствии с новыми рекомендациями NIST;Ну, до 2030 года 2048 считается безопасным в соответствии с этими самыми рекомендациями. А загадывать на 10 лет вперед я бы не рискнул, прогресс заметно ускоряется с каждым годом, возможно, к тому времени уже что-то совсем иное будет.
Берут на вырост. Какой-нибудь OpenSSH 8.x попадет в RHEL 8, который вполне может дожить до 2030 года.
И что мешает увеличить размер ключа в каком-нибудь 8.x?
Тут дело не в этом. Нужно рассчитывать на то, что сгенерированные пользователями ключи будут использоваться длительное время.
> И что мешает увеличить размер ключа в каком-нибудь 8.x?Ничего, в жизненном цикле 6-ки вроде как раз увеличивали. Есть все механизмы, чтобы сделать это на уровне конфигов.
чтобы утекший или забытый ключ десять лет назад уволившегося сотрудника еще лет десять подходил бы ко всем дверям, правильно.
Нет бы наоборот, принудительно удалять все ключи старше трех месяцев (в отличие от идиотских политик принудительной смены паролей - эта как раз имеет смысл - если, конечно, не пользоваться сертификатами по каким-то религиозным причинам)
Последнее время ушёл на «Dropbear» с файерволом 22 по ip.
А поддержка UDP в SOCKS (-o DynamicForward / -D) будет?