Состоялся (http://lists.mindrot.org/pipermail/openssh-unix-dev/2016-Aug...) релиз OpenSSH 7.3 (http://www.openssh.com/), открытой реализации клиента и сервера для работы по протоколам SSH 2.0 и SFTP. Поддержка устаревших протоколов SSH 1.3 и 1.5 в OpenSSH 7.3 сохранена, но требует активации на этапе компиляции. В OpenSSH 7.4 будет удалён (https://www.opennet.dev/opennews/art.shtml?num=44380) код, связанный с использованием SSHv1 на стороне сервера, а летом 2017 года планируют удалить код клиентской части SSHv1. В будущих выпусках также планируют запретить использование любых RSA-ключей, размером менее 1024 бит.Изменения в OpenSSH 7.3:
- В файл конфигурации ssh_config добавлена директива Include, позволяющая включать содержимое других файлов;
- Для клиента ssh реализована настройка ProxyJump и опция командной строки "-J", позволяющая упростить настройку проброса через один или несколько промежуточных SSH-хостов;- В ssh добавлена настройка IdentityAgent, через которую можно указать произвольный сокет для ssh-agent, который будет использован вместо сокета, указанного через переменную окружения;
- В ssh реализована возможность переопределения значений параметров ExitOnForwardFailure и ClearAllForwardings через их переустановку в командной строке при помощи "ssh -W";
- В ssh и sshd добавлена поддержка режима терминала IUTF8 (https://tools.ietf.org/html/draft-sgtatham-secsh-iutf8-01);
- В ssh и sshd добавлена поддержка дополнительных фиксированных групп Diffie-Hellman, размером 2K, 4K и 8K;
- В ssh-keygen, ssh и sshd добавлена поддержка цифровых подписей на базе SHA256 и SHA512 в сертификатах RSA;
- В ssh разрешено использовать символы UTF-8 в выводимом перед аутентификацией приглашении, поступающем от сервера;
- В ssh и sshd обеспечено автоматическое отключение шифров, не поддерживаемых OpenSSL;
- Решены проблемы со сборкой на платформах AIX и Solaris;
- В sshd расширен список архитектур для которых активируется механизм фильтрации системных вызовов seccomp-bpf;- Устранено несколько уязвимостей:
- Устранена потенциальная DoS-уязвимость в sshd, возникающая из-за слишком большого потребления ресурсов при обработке функцией crypt слишком длинных паролей. Начиная с OpenSSH 7.3 запрещена передача паролей, длиннее 1024 символов;- Устранена уязвимость CVE-2016-6210 (https://www.opennet.dev/opennews/art.shtml?num=44802), позволяющая на основе ответа сервера определить существует или нет пользователь в системе. Применявшийся для внесения задержки для несуществующих пользователей хэш BLOWFISH на слишком длинных паролях выполняется заметно дольше, чем применяемые для существующих пользователей хэши SHA256/SHA512, что позволяет по времени выполнения операции определить факт существования проверяемого логина в системе;
- Устранены различия во времени формирования добавочного заполнения (padding oracle) в шифрах CBC (отключен по умолчанию);- Устранены проблемы с порядком проверки MAC для алгоритмов Encrypt-then-MAC (EtM) - MAC теперь всегда проверяется до расшифровки блоков. Разница в порядке проверки могла применяться для оценки параметров расшифрованных данных на основе времени их расшифровки;
- В переносимой версии sshd теперь игнорируются переменные окружения PAM при наличии настройки UseLogin=yes, что блокирует возможности атаки на /bin/login через подстановку переменной окружения LD_PRELOAD через PAM (уязвимость CVE-2015-8325);
URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/2016-Aug...
Новость: http://www.opennet.dev/opennews/art.shtml?num=44889
> Для клиента ssh реализована настройка ProxyJump и опция командной строки "-J", позволяющая упростить настройку проброса через один или несколько промежуточных SSH-хостов;Я джва года этого ждал.
А что не так?
Раньше тоже можно было сделать себе удобно (в т.ч. цепочки) через ProxyCommand в файле ~/.ssh/config
Тут ещё фишка в том, что цепочки можно сделать чисто через аргументы, без редактирования конфига.
Прямо праздник какой-то.
Сегодня, наконец-то, в openSUSE обновили openssh с 6.6 на 7.2.
Подумал, не ужели у меня, наконец-то, будет свежий openssh, но не тут-то было.
В тамблвид что-ли? В 42.1 все так же 6.6.
> В тамблвид что-ли? В 42.1 все так же 6.6.Ага, причём после обновления, клиенты не хотели соединятся с серверами из-за 2-ух устарелых строчек в конфиге связанных с GSSAPI, пока не удалил их из конфига.
Хорошо, что только клиент, исправил локально, соединился с сервером, исправил удалённо.
Но вот если на сервере такое случится, а "Protocol 2" и там и там.
Самое разумное будет в версии 7.3 убедится, что в openSUSE собрали без этого рудимента, и убрать эту строку из конфига, но теперь чёрт его знает, когда openSUSE вздумается его снова обновить.
В репозитории network есть 7.2. Не обязательно сетовать на tmblwd.
> В репозитории network есть 7.2. Не обязательно сетовать на tmblwd.Спасибо, накушался я на номерных версиях, на каждое нужное приложение более свежей версии чем в Oss, причём не факт что актуальной, добавлять свой репозиторий.
Ну, тогда rpm -ivh из внешних rpm. Т.е. проблемы, как таковой, нет. Но да, приятней было бы не подключать 100500 репозиториев для более новых версий программ.
> OpenSSH 7.4 будет удалён код, связанный с использованием SSHv1 на стороне сервера, а летом 2017 года планируют удалить код клиентской части SSHv1.А сервер и клиент со строчкой в конфиге "Protocol 2" окажутся неработоспособными?
> А сервер и клиент со строчкой в конфиге "Protocol 2" окажутся неработоспособными?нет, ведь SSHv2 остается. удалится все *но связанное с SSHv1
>> А сервер и клиент со строчкой в конфиге "Protocol 2" окажутся неработоспособными?
> нет, ведь SSHv2 остается. удалится все *но связанное с SSHv1Но ведь и эта опция станет бессмысленной, которую могут удалить, и с которой я опять буду лицезреть "Connection reset by peer".
Хорошо, действительно, если не придётся.
Как можно было вообще к такому выводу прийти?
> Как можно было вообще к такому выводу прийти?Во-первых, это был вопрос!
Во-вторых, на основании печального опыта неработоспособности клиента после обновления, когда в новой версии сделали устарелыми некоторые строки конфигурации.
> В файл конфигурации ssh_config добавлена директива Include, позволяющая включать содержимое других файлов;Не прошло и 20 лет, как запилили
Лучше RegExp в условии с хостом для подмены ключей по маске одним шаблоном (Amazon EC2)
Бред. Генерируйте файл, или используйте более продвинутые инструменты, типа nixops
Оставьте свой DevOps при себе.
> В файл конфигурации ssh_config добавлена директива Include, позволяющая включать содержимое других файлов;Это распространяется на sshd_config?
Отвечаю сам себе — увы, нет. Грусть-печаль.
>Применявшийся для внесения задержки для несуществующих пользователей хэш BLOWFISH на слишком длинных паролях выполняется заметно дольше, чем применяемые для существующих пользователей хэши SHA256/SHA512Может быть знающие люди пояснят, зачем использовать разные хеши? Разве использование одинаковых (когда мы уже знаем о том, что пользователя нет) создаёт какую-то угрозу безопасности?
Проблем со сборкой на Solaris и AIX в 7.2 не было. А в 7.3 они появились - и какие! Без плясок с бубном 64 бита не собираются совсем. На том же самом железе, где 7.2 собирается со свистом. Убивать надо таких исправляльщиков!
Мамочки, скелет из музея палеонтологии разговаривает!
Вы там еще живы? держитесь денег нету!