LINUX.ORG.RU

OpenSSH 7.7

 , ,


1

2

OpenSSH — это реализация протокола SSH 2.0, включающая в себя sftp клиент и сервер.

В этом релизе прекращена поддержка некоторых очень старых реализаций SSH, включая ssh.com старше 2.* и OpenSSH старше 3.*. Эти версии были выпущены до 2001 года и на тот момент еще не было конечной версии RFC, следовательно прекращение поддержки не влияет на совместимые с RFC реализации SSH.

Новая функциональность:

  • Добавлена экспериментальная поддержка ключей PQC XMSS (Extended Hash-Based Signatures). Не присутствует в сборке по умолчанию.
  • В sshd_config добавлен критерий «rdomain», позволяющий указывать определенные параметры в зависимости от того, с какого домена маршрутизации пришло соединение (поддерживается только OpenBSD и Linux).
  • Добавлена опция «expiry-time», позволяющая указать время жизни записей в authorized_keys.
  • Добавлена опция BindInterface, позволяющая завязать исходящее соединение с адресом интерфейса.
  • В LocalCommand теперь можно использовать спецификатор %T, указывающий на интерфейс, созданный при перенаправлении tun/tap. Это позволяет использовать LocalCommand для настройки интерфейса при старте.
  • Добавлена поддержка URI для ssh, sftp и scp, например ssh://user@host или sftp://user@host/path. При этом другие параметры не поддерживаются.
  • В ssh-keygen можно указывать только начала действия или только конца действия сертификата (ранее можно было только оба или ни одного).
  • sftp теперь поддерживает команды «cd» и «lcd» без явного указания пути в аргументе. «lcd» при этом будет переходить в домашнюю директорию пользователя, а «cd» в директорию, откуда началась сессия.
  • Теперь проверка конфигурационного файла (sshd -T) происходит с учетом критериев (Match).

Некоторые из исправленных ошибок:

  • Более пристальная проверка типов подписей во время обмена ключей. Не позволяет снизить безопасность переходом от SHA-256/512 к SHA-1.
  • Исправлена поддержка клиентов с версией протокола «1.99» (отображает, что клиент подготовлен для как SSHv1, так и SSHv2).
  • ssh теперь отображает предупреждение в том случае, если агент возвращает SHA1 вместо SHA2-256/512.
  • В ssh-keyscan добавлена опция "-D", выводящая результат в формате SSHFP.
  • Отключена поддержка RemoteCommand и RequestyTTY в том случае, если сессия начата scp.
  • ssh-keygen теперь будет завершать свою работу в том случае, если невозможно записать все ключи. Ранее он мог тихо проигнорировать ошибки.
  • Таймеры теперь используют монотонное время.
  • Множественные исправления в руководствах.

Переносимость:

  • MIPS ABI теперь определяется корректно во время конфигурирования.
  • Прекращена поддержка UNICOS. Решение связано с наличием оборудования в основном только в музеях, следовательно поддерживать проблемно.
  • Включена поддержка флага «retpoline» (если он доступен) для снижения вероятности эксплуатации Spectre 2.
  • Множественные исправления в RPM spec'е.

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Ответ на: комментарий от KennyMinigun

зачем разработчики OpenSSH делают работу мейнтейнеров дистрибутивов.

Скорее всего просто взяли обновлённые спеки из некоторых дистрибутивов. А ещё вероятнее - сами мантейнеры патчи и прислали, либо кто-то из разработчиков ещё и мантейнер где-то. Не думаю, чтобы это кто-то делал отдельно и целенаправленно.

AS ★★★★★ ()

Теперь проверка конфигурационного файла (sshd -T) происходит с учетом критериев.

Ну потрясающе, а раньше проверка была без критериев? Надмозги, ёлки-палки.

anonymous ()
Ответ на: комментарий от anonymous

Ну потрясающе, а раньше проверка была без критериев?

Ага. Имеются ввиду подобные участки конфига:

Match Address 1.2.3.4
    PasswordAuthentication yes

Надмозги, ёлки-палки.

Возможно. Если знаешь как перевести лучше — напиши.

jollheef ★★★★★ ()

Добавлена опция «expiry-time», позволяющая указать время жизни записей в authorized_keys.

Гуд! Хотя хотелось-бы расширенный вариант, когда этот time считается от последнего успешного логина пользователя...

log4tmp ★★★★ ()

пост-квантовая криптография? гм, ну ладно (одевает вторую шапочку из фольги).

а самое главное, теперь можно переписывать SendEnv в клиентском конфиге? или всё так же, только добавлять?

last_man_standing ()
Ответ на: комментарий от hobbit

О, вот наконец, программа, где спек идёт из коробки от авторов.

Как будто что-то хорошее

Интересно, они ухитрились сделать один спек для федоры, центоса и опензюзи?

Каноничен RHEL (ну и Fedora на подтяжках). И мне что-то подсказывает что все равно в RHEL и Fedora свои спеки (и причем разные).

https://anongit.mindrot.org/openssh.git/tree/contrib/redhat

UPD А нет, там в Changelog меняли и из @redhat.com. Ну что же...

KennyMinigun ★★★★★ ()
Последнее исправление: KennyMinigun (всего исправлений: 2)

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

AVL2 ★★★★★ ()
Ответ на: комментарий от slvrn

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

AVL2 ★★★★★ ()
Ответ на: комментарий от hobbit

Интересно, они ухитрились сделать один спек для федоры, центоса и опензюзи

Да почти весь епель такой. В случае с пакетом без привязки к системд, ядру и все такое, это несложно.

AVL2 ★★★★★ ()
Ответ на: комментарий от KennyMinigun

Нет, мейнтейнер дистрибутива, это человек отслеживающий появление новых версий и решающий дистрибутивно-специфичные проблемы.

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

AVL2 ★★★★★ ()
Ответ на: комментарий от AVL2

Вы не валите в одну кучу аутентификацию удалённого сервера и аутентификацию этим сервером пользователя, СЛУЧАЙНО?

Аутентификация сервера и сейчас делается посредством пары ключ+сертификат. Файлы /etc/ssh/*_key* видели? Так вот это оно.

Аутентификация пользователя также возможна посредством сертификатов. Для этого в ssh_config есть CertificateFile.

Когда-то в OpenSSH была поддержка сертификатов X.509, но потом её дропнули из-за сложности корректной реализации инфраструктуры в целом.

Если вам не нравится политика по умолчанию (разрешать подключения к незнакомым хостам только после явного одобрения пользователем, кешировать отпечаток сервера) — сделайте себе StrictHostKeyChecking=yes в ssh_config, и раскидывайте отпечатки серверов ручками, а на самих серверах поставьте аутентификацию только по ключам. И будет вам счастье.

Кстати, есть такая штатная утилита ssh-keyscan. Позволяет автоматически наполнить known_hosts.

anonymous ()
Ответ на: комментарий от anonymous

Ничего я не смешиваю. Речь идет про аутентификацию сервера в первую очередь. И для этого нужно не ключи в днс пихать, а сертификаты x509 поддерживать. Все на них сидят, а им сложно...

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

AVL2 ★★★★★ ()
Ответ на: комментарий от AVL2

У X.509 сильная сторона — универсальность, а слабые вытекают из этого свойства: корректная работа с ними действительно нетривиальна. Я наблюдал (и сейчас слежу) процессы развития LibreSSL — там настоящий ад местами, даже после серьёзных чисток. Так что, как ни жаль, X.509 в OpenSSH больше нет.

Что до пользователя, «ключ» и «сертификат», по сути одно и то же. А управлять ключами/сертификатами пользователей не так уж сложно.

anonymous ()
Ответ на: комментарий от anonymous

Да не было их там никогда. Был какой то форк израильский, это не в счёт. Это как файрфокс с поддержкой гостов, виртуальность одна...

Для пользователя разница тоже большая. В сертификате куча доп. информации передается. Срок действия, списки отзыва, логин, сфера использования. Все это позволяет разделить деятельность админа и офицера безопасности.

Но в целом вы правы, ибо все это в теории, а на практике все настолько дремучие, что какие там офицеры, какая там безопасность...

AVL2 ★★★★★ ()
Последнее исправление: AVL2 (всего исправлений: 1)