И полгода не прошло: вышел релиз OpenSSH 8.5. Подробности о новинке03.03.2021 15:33

В ближайшем будущем разработчики обещают отключить по умолчанию возможность использования алгоритма цифровых подписей по открытому ключу «ssh-rsa». Сейчас он все еще широко распространен.
Для того, чтобы проверить, используется ли этот ключ в собственной системе, нужно попробовать подключиться по ssh с опцией »-oHostKeyAlgorithms=-ssh-rsa». Важный момент: отключение по умолчанию цифровых подписей такого типа не является полным отказом от использования RSA-ключей. Проблема в том, что, помимо SHA-1, протокол SSH допускает применение других алгоритмов вычисления хэшей. В числе прочих возможностей разработчики оставят использование связок «rsa-sha2–256» (RSA/SHA256) и «rsa-sha2–512» (RSA/SHA512).

Чтобы упростить переход на новые алгоритмы, в новом релизе по дефолту включена настройка UpdateHostKeys. Она-то как раз и переводит клиенты на новые алгоритмы. Функция активирует специальное расширение протокола «hostkeys@openssh.com», которое дает возможность серверу информировать клиента о всех доступных ключах хоста сразу после прохождения аутентификации. Клиент может отразить эти ключи в файле ~/.ssh/known_hosts, что дает возможность организовать обновление ключей хоста с упрощением смены ключей на сервере.

Стоит отметить, что использование UpdateHostKeys возможно с рядом нюансов:

• он должен быть упомянут в UserKnownHostsFile и не использоваться в GlobalKnownHostsFile;
• ключ должен присутствовать только под одним именем,
• не должен применяться сертификат хостового ключа;
• в known_hosts не должно применяться масок по имени хоста;
• настройка VerifyHostKeyDNS должна быть отключена;
• параметр UserKnownHostsFile должен быть активен .

• 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).

Подробности об изменениях в новой версии

Безопасность:

• Ликвидирована уязвимость в ssh-agent, которая вызвана повторным освобождением уже освобожденной области памяти. Эта проблема была актуальна с выпуска OpenSSH 8.2. Злоумышленник потенциально может использовать ее при наличии доступа к сокету ssh-agent на локальной системе. Правда, это не слишком опасно, поскольку доступ к сокету есть только у рута и самого пользователя. Но зато можно направить агент на учетную запись, которая подконтрольна злоумышленнику, либо на хост, к которому у киберпреступника есть root-доступ.
• В sshd появилась защита от передачи очень больших параметров с именем пользователя в РАМ-подсистему. Это дает возможность блокировать уязвимости в системных модулях PAM (Pluggable Authentication Module). Нововведение дает возможность предотвратить использование sshd в качестве вектора для эксплуатации недавно выявленной root-уязвимости в Solaris (CVE-2020–14871).

• В ssh и sshd переработаны специализированный метод обмена ключами, который устойчив к подбору на квантовом компьютере. Как известно, квантовые системы способны подбирать сложнейшие пароли за считанные секунды. В частности, это реализовано благодаря разложению натурального числа на простые множители. Именно эта задача является основой современных асимметричных алгоритмов шифрования, причем на традиционных системах решить ее не получится. Новый метод получилось реализовать благодаря алгоритму NTRU Prime, разработанном для постквантумных криптосистем, и методе обмена ключами на базе эллиптических кривых X25519. Вместо sntrup4591761×25519-sha512@tinyssh.org метод теперь идентифицируется как sntrup761×25519-sha512@openssh.com (алгоритм sntrup4591761 заменен на sntrup761).
• В ssh и sshd изменили порядок анонсирования поддерживаемых алгоритмов цифровых подписей. Вместо ECDSA первый теперь ED25519.
• Здесь же установка параметров качества обслуживания TOS/DSCP для интерактивных сеансов производится до установки TCP-соединения.
• Шифр ijndael-cbc@lysator.liu.se, который идентичен aes256-cbc и использовался до утверждения RFC-4253, больше не поддерживается.
• Отключен по дефолту параметр CheckHostIP. Он не особо полезен, но значительно усложняет ротацию ключей для хостов за балансировщиками нагрузки.

• В sshd разработчики добавили настройки PerSourceMaxStartups и PerSourceNetBlockSize для ограничения интенсивности запуска обработчиков в привязке к адресу клиента. Ограничениями на запуск процессов теперь можно управлять более тонко.
• В ssh и sshd появилась настройка LogVerbose, которая дает возможность принудительно поднять уровень сбрасываемой в лог отладочной информации, с возможностью фильтрации по шаблонам, функциям и файлам.
• В ssh обеспечивается показ всех имен хостов и IP-адресов, которые ассоциированы с ключом. Это происходит при принятии нового хостового ключа.
• В ssh есть явное разрешение опции UserKnownHostsFile=none для отключения использования файла known_hosts при идентификации хостовых ключей.
• В ssh-config добавлена настройка KnownHostsCommand, позволяющая получить данные known_hosts из вывода указанной команды.
• Плюс там же добавлена возможность PermitRemoteOpen, которая позволяет ограничить точку назначения при использовании опции RemoteForward с SOCKS.
• В ssh для ключей FIDO теперь обеспечивается повторный запрос PIN в случае сбоя операции с цифровой подписью из-за неправильного PIN либо отсутствия запроса PIN у пользователя. Такое происходит в том случае, если система не получает корректные биометрические данные, так что устройство откатывается на ручной ввод PIN.
• Разработчики обновили утилиту contrib/ssh-copy-id.