The OpenNET Project / Index page

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

Релиз OpenSSH 5.7

24.01.2011 10:44

Доступен релиз OpenSSH 5.7, открытой реализации клиента и сервера для работы по протоколу SSH версии 1.3, 1.5 и 2.0, и включающей в себя поддержку SFTP.

В новой версии исправлено 18 ошибок и добавлено несколько новшеств:

  • Реализован режим шифрования по эллиптическим кривым (RFC 5656), который может быть использован для обмена ключами (ECDH) и для хранения ключей хоста/пользователя (ECDSA). По сравнению с ранее поддерживаемыми методами DH и DSA, методы ECDH и ECDSA обеспечивают более высокую производительность, как для идентичных по размеру симметричных ключей, так и для более коротких ключей. В настоящее время реализованы только обязательные секции спецификации RFC 5656: поддержка кривых nistp256, nistp384, nistp521 и методов ECDH и ECDSA.

    Поддерживается использование типа ключей ECDSA для создания сертификатов хоста и пользователя, ECDSA-ключи могут заверяться сертификатами и использоваться в роли CA-сертификатов для подписывания других ключей. Хост-ключи в формате ECDSA теперь являются предпочтительными и генерируются при первом создании ключей или могут быть получены при помощи утилиты ssh-keyscan. ECDH c 256-битным размером параметров кривой является предпочтительным вариантом для согласования ключей, когда ECDH поддерживается клиентом и сервером;

  • Существенно увеличена производительность sftp-клиента при формировании списка директорий. Для оценки параметров директорий теперь используется расширенный вариант функции glob(3) из OpenBSD, поддерживающий кэширование, что позволяет избежать полного перебора директорий на каждый запрос;
  • В сервере и клиенте sftp добавлена поддержка расширения протокола, обеспечивающего возможность работы с жесткими ссылками. По умолчанию команда "ln" теперь создает жесткие ссылки, для создания символических ссылок необходимо использовать опцию "-s" или команду "symlink";
  • В утилите scp появилась поддержка опции "-3", позволяющей организовать копирование файлом между двумя удаленными хостами с промежуточной передачей данных через локальный хост. Без указания опции "-3" передача осуществляется напрямую - с одного удаленного хоста на другой;
  • В программы ssh и sshd добавлена новая опция "IPQoS", позволяющая задать произвольное значение параметров TOS/DSCP/QoS вместо использования зашитого внутрь сочетания задержки и пропускной способности;
  • Изменен метод создания mux-сокетов (организация работы нескольких сеансов через одну сессию). На начальной стадии автоматически создается временный сокет, который привязывается к основному только после успешного выполнения операции listen(), что позволяет клиенту отследить готов ли сокет к обработке запросов. Устаревшие сокеты удаляются автоматически;
  • В файлы конфигуриации ssh и sshd добавлен параметр KexAlgorithms, позволяющий определить какой из методов обмена ключами использовать и в каком порядке;
  • В ssh и sshd обеспечена возможность подключения используемого в scp обработчика ограничения исходящей пропускной способности, что позволяет задействовать данное ограничение пропускной способности и для sftp;
  • Добавлена официальная поддержка порта для Solaris и обеспечена возможность сборки с openssl 1.0.0a.


  1. Главная ссылка к новости (http://lists.mindrot.org/piper...)
  2. OpenNews: Новая версия OpenSSH 5.6
  3. OpenNews: Подготовлен порт OpenSSH под Windows
  4. OpenNews: Корректирующий релиз OpenSSH 5.5
  5. OpenNews: Релиз OpenSSH 5.4
  6. OpenNews: Неподтвержденная информация о наличии критической уязвимости в OpenSSH (дополнено)
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/29358-openssh
Ключевые слова: openssh, ssh, crypt
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (54) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 11:55, 24/01/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Что-то во всех миррорах последняя портабл версия 5.6. Не появилась еще.
     
     
  • 2.2, uldus (ok), 12:05, 24/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    На основном сервере смотрите ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/
     
     
  • 3.5, cmp (ok), 12:34, 24/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Скорость 0,5кб/c круть
     
     
  • 4.9, Аноним (-), 13:25, 24/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    На первом попавшемся русском зеркале уже есть:
    ftp://ftp.opennet.ru/pub/Mirrors/openssh/
     

  • 1.3, инкогнито (?), 12:06, 24/01/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    эллиптика и QOS! это же просто отлично!
     
     
  • 2.6, Аноним (-), 12:40, 24/01/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    инкогнито, поделись, как будешь это использовать?
     
     
  • 3.7, инкогнито (?), 12:57, 24/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Для начала, видимо, придется 5.7 собрать :) Возможно понадобится openssl 1.0+
    Серверные ключи перегенерировать на эллиптические. Это много лучше RSA/DSA, т.к. им для надёжности надо >4096 бит, а это сильно медленно.
    А с помощью QoS выставить TOS=0x08 (Minimal delay), это даст высший приоритет для стандартного планировщика пакетов в линуксе.
    ЗЫ. это теория, 5.7 ещё не собирал
     
     
  • 4.8, Аноним (-), 13:14, 24/01/2011 [^] [^^] [^^^] [ответить]  
  • –8 +/
    А какое отношение опенссш имеет к линуксу?
     
     
  • 5.10, Гордый Аноним (?), 13:29, 24/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >А какое отношение опенссш имеет к линуксу?

    Внезапно:

    openssh-client 1:5.5p1-4ubuntu4 secure shell (SSH) client, for secure access to remote machines
    openssh-server 1:5.5p1-4ubuntu4 secure shell (SSH) server, for secure access from remote machines

    Это даже если ручками не собирать.

     
  • 5.12, non anon (?), 13:40, 24/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > А какое отношение опенссш имеет к линуксу?

    Внезапно, линакс - одна из наиболее используемых никс-лайк систем.
    openssh, тоже внезапно, в большинстве случаев используется по никс-лайк.

    И на каждый сервер с openbsd+openssh, по самым скромным оценкам, приходится over 9000 серверов с linux+openssh.

     
     
  • 6.13, Гордый Аноним (?), 13:45, 24/01/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Внезапно, Торвальдс произносит "линукс" как "линукс".
     
     
  • 7.15, ызусефещк (?), 14:19, 24/01/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Линус произносит Linux как Линукс.
     
  • 5.17, Alen (??), 14:32, 24/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    А с какой целью Вы читаете про сабж?
     
  • 4.11, non anon (?), 13:38, 24/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >А с помощью QoS выставить TOS=0x08 (Minimal delay), это даст высший приоритет для стандартного планировщика пакетов в линуксе.

    По-моему, это и значение TOS и раньше для openssh по дефолту было (кроме sftp, там maximize-throughput).

     
     
  • 5.36, PereresusNeVlezaetBuggy (ok), 05:06, 25/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>А с помощью QoS выставить TOS=0x08 (Minimal delay), это даст высший приоритет для стандартного планировщика пакетов в линуксе.
    > По-моему, это и значение TOS и раньше для openssh по дефолту было
    > (кроме sftp, там maximize-throughput).

    Именно.

     
  • 4.21, Stax (ok), 18:13, 24/01/2011 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Эй, вы поосторожнее с такими заявлениями! Вдруг кто прочтет и не проверив, начнет использовать.
    0x08 это обычно худший класс по латентности, с большими очередями, туда обычно торренты и проч. bulk traffic отправляют, чтобы резать удобнее. Minimal delay это 0x10.
     
     
  • 5.26, инкогнито (?), 19:50, 24/01/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    да, вы правы. перепутал, надо 0x10

    ЗЫ. openssh 5.7p1 собрал, ECDSA ключи проверил — всё работает.

     
  • 4.31, klalafuda (?), 23:21, 24/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Серверные ключи перегенерировать на эллиптические. Это много лучше RSA/DSA, т.к. им для надёжности надо >4096 бит, а это сильно медленно.

    Эээ.. Я конечно сильно извиняюсь, но не равнозначно ли это тому, что ключи сервера во-первых полностью поменяются а во-вторых поменяются таким образом, что, потенциально, не все клиенты их поймут (те, кто кроме как об RSA ничего не слышал)? И что скажут на это клиенты сервера :-? Или он там - клиент - один? Тогда хоть 10к RSA ключ - пофигу..

     
     
  • 5.33, Алексей (??), 02:30, 25/01/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ключи не поменяются, а добавится ещё один новый тип. "Не понимающие" клиенты продолжат работать как и ранее по старым ключам.
     

  • 1.14, Алексей (??), 13:52, 24/01/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ура, наконец-то мы дожили до начала внедрения ECDSA (более стойкий чем RSA/DSA) в open source продукты. Ждём новой версии GnuPG с поддержкой ECDSA.
     
     
  • 2.18, cmp (ok), 17:14, 24/01/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    только ecdsa не совместим со старыми клиентами ((
     
     
  • 3.22, Алексей (??), 19:03, 24/01/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Верно, широкого (повсеместного) применения придётся ещё немного подождать, но уже процесс пошёл. Пройдёт полгодика и у большинства будут новые версии.
     
     
  • 4.25, cmp (ok), 19:40, 24/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Процесс всегда в процессе )), putty интересно, тоже обновлять придется. Признаться, не ожидал, что совместимость сломается.
     
     
  • 5.32, Алексей (??), 02:24, 25/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Стоп-стоп-стоп... Что именно вы подразумеваете под поломкой совместимости в данном случае?
    Новые сервера будут дополнительно генерировать ECDSA host keys (в дополнение к RSA и DSA) и новые версии ssh клиентов смогут при желании сверять отпечатки (fingerprints) именно ECDSA ключей сервера с содержимым локальных файлов known_hosts. Старые же клиенты смогут как и ранее использовать RSA/DSA ключи для идентификации сервера (конечно же при условии что админы сервера специально не удалили RSA/DSA ключи хоста).

    Аналогично и с пользовательскими ssh ключами: держите в authorized_keys как новый (ECDSA), так и старый (RSA/DSA) ключ, и тогда не будет никаких препятствий к подключению старым ssh клиентом по "старому" ключу к новой версии сервера.

     
     
  • 6.37, PereresusNeVlezaetBuggy (ok), 05:08, 25/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    > Новые сервера будут дополнительно генерировать ECDSA host keys (в дополнение к RSA
    > и DSA) и новые версии ssh клиентов смогут при желании сверять
    > отпечатки (fingerprints) именно ECDSA ключей сервера с содержимым локальных файлов known_hosts.
    > Старые же клиенты смогут как и ранее использовать RSA/DSA ключи для
    > идентификации сервера (конечно же при условии что админы сервера специально не
    > удалили RSA/DSA ключи хоста).
    > Аналогично и с пользовательскими ssh ключами: держите в authorized_keys как новый (ECDSA),
    > так и старый (RSA/DSA) ключ, и тогда не будет никаких препятствий
    > к подключению старым ssh клиентом по "старому" ключу к новой версии
    > сервера.

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

     
  • 6.38, cmp (ok), 05:15, 25/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    То, что клиент не обученный ECDSA не способен залогинится с ним, какая ему разница, что зашифровать и отправлять серверу.
     
     
  • 7.40, PereresusNeVlezaetBuggy (ok), 05:18, 25/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > То, что клиент не обученный ECDSA не способен залогинится с ним, какая
    > ему разница, что зашифровать и отправлять серверу.

    Кто вам сказал, что неспособен? Почему вы решили, что сервер обязательно будет поддерживать ТОЛЬКО ECDSA?

    Никакая совместимость не сломалась, срочно вернитесь на землю из своих домыслов. :)

     
     
  • 8.41, cmp (ok), 05:25, 25/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    То есть, то, что мой клиет ругается на ECDSA ключ это мой домысл ... текст свёрнут, показать
     
     
  • 9.42, PereresusNeVlezaetBuggy (ok), 05:58, 25/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, встретил он незнакомый тип ключа, и что в этом смертельного Если у хоста ес... текст свёрнут, показать
     
     
  • 10.43, cmp (ok), 06:28, 25/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Как Вы сами сказали, есть некая аналогия с SSHv1 SSHv2, но там изменен сам прото... текст свёрнут, показать
     
     
  • 11.44, PereresusNeVlezaetBuggy (ok), 06:37, 25/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    И всё же не пойму, в чём криминал того, что и сервер, и клиент должны знать о EC... текст свёрнут, показать
     
     
  • 12.46, cmp (ok), 06:53, 25/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    В том, что придется держать два ключа, то есть, нет смысла в новом, потому как, ... текст свёрнут, показать
     
     
  • 13.47, PereresusNeVlezaetBuggy (ok), 07:18, 25/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так никто и не заставляет использовать только один ключ Что такого страшн... текст свёрнут, показать
     
     
  • 14.48, cmp (ok), 08:17, 25/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Страшного ничего, неудобного - на две кнопки, при входе и на Nцать при обновлен... текст свёрнут, показать
     
     
  • 15.49, PereresusNeVlezaetBuggy (ok), 08:31, 25/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    При входе IdentityFile Specifies a file from which the user s... текст свёрнут, показать
     
     
  • 16.50, cmp (ok), 09:23, 25/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Если раскидать ключи по машинам, иначе use -i option, с указанием на шифрованный... текст свёрнут, показать
     
     
  • 17.51, PereresusNeVlezaetBuggy (ok), 09:29, 25/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Причём, если я правильно помню, первым разделом она считает находящийся в первой... текст свёрнут, показать
     
     
  • 18.52, cmp (ok), 09:36, 25/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Этого к сожалению не знаю, знал, что подвох будет, проверил у подруги на ноуте ... текст свёрнут, показать
     
     
  • 19.53, PereresusNeVlezaetBuggy (ok), 09:41, 25/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Сочувствую Я просто уже сам не помню, почему на загрузочных флешках делаю загру... текст свёрнут, показать
     
  • 11.45, PereresusNeVlezaetBuggy (ok), 06:45, 25/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Прежде всего, клиент ещё и проверяет аутентичность хоста Который, если поддержи... текст свёрнут, показать
     

  • 1.20, Stax (ok), 18:10, 24/01/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Толку от этих эллиптических кривых, если использовать нельзя :( Редхат, федора, центос и тд старательно вырезают их поддержку из openssl, положиться на то, что их можно использовать нельзя, они и с openssh наверняка так же будут делать.
     
     
  • 2.23, Алексей (??), 19:04, 24/01/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Толку от этих эллиптических кривых, если использовать нельзя :( Редхат, федора, центос
    > и тд старательно вырезают их поддержку из openssl, положиться на то,
    > что их можно использовать нельзя, они и с openssh наверняка так
    > же будут делать.

    Можно подробнее (ссылка, причины)? Я просто не в курсе.

     
     
  • 3.28, Stax (ok), 20:20, 24/01/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    редхат:
    $ openssl ecparam -genkey
    openssl:Error: 'ecparam' is an invalid command.
    $ rpm -q openssl.x86_64
    openssl-0.9.8e-12.el5_4.6.x86_64
    $ cat /etc/*release
    Red Hat Enterprise Linux Server release 5.5 (Tikanga)

    14 федора:
    $ openssl ecparam -genkey
    openssl:Error: 'ecparam' is an invalid command.
    $ rpm -q openssl.x86_64
    openssl-1.0.0c-1.fc14.x86_64

    Следствие: программы, делающие #include <openssl/ecdsa.h> и использующие функции (напр. bitcoin) собрать нельзя.

    Багзилла: https://partner-bugzilla.redhat.com/show_bug.cgi?id=612265
    Из других пакетов ECC тоже вырезают, напр. https://bugzilla.redhat.com/show_bug.cgi?id=615372

    Причины наверное здесь http://en.wikipedia.org/wiki/ECC_patents , ну и в рассылках редхата можно почитать детали.

     
     
  • 4.39, PereresusNeVlezaetBuggy (ok), 05:17, 25/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Причины наверное здесь http://en.wikipedia.org/wiki/ECC_patents , ну и в рассылках редхата
    > можно почитать детали.

    Н-дя. Знакомимся с ещё одним патентным троллем, похоже, — после описания по ссылке столкновения Certicom с Sony.

    По крайней мере OpenSSH разрабатывается не в США, так что этот бред к нему не относится. Пользуйтесь ECC на здоровье. :)

     
  • 3.54, Andrey Mitrofanov (?), 09:44, 25/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Можно подробнее (ссылка, причины)?

    http://lwn.net/Articles/424392/#Comments

     
  • 2.24, Crazy Alex (??), 19:19, 24/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, не у всех редхатоподобные. Глянем, чтов дебиане будет.
     
     
  • 3.59, non anon (?), 17:46, 25/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну, не у всех редхатоподобные. Глянем, чтов дебиане будет.

    Учитывая, как они борются с лицензионными и патентыми подставами, можно утверждать: этот трап там тоже выпилят, инфа 100%.

    // В сквизе команда openssl ecparam есть, но она тупо ничего не делает.

     
  • 2.27, инкогнито (?), 19:52, 24/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Редхат, федора, центос и тд старательно вырезают их поддержку из openssl

    хм, порадуемся за убунту?! там поддержка ecc есть, даже в lucid

     
  • 2.29, User294 (ok), 21:51, 24/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Толку от этих эллиптических кривых, если использовать нельзя :( Редхат, федора, центос
    > и тд старательно вырезают их поддержку из openssl,

    А с чем это связано?

     
     
  • 3.30, Stax (ok), 22:51, 24/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Патенты, батенька, патенты. Редхат находится в США, а там софтварные патенты. В общем огребаем тех же проблем, как раньше с .gif, RSA, нынче .mp3, h264 и тд.
     
  • 2.35, Аноним (-), 03:16, 25/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Толку от этих эллиптических кривых, если использовать нельзя :( Редхат, федора, центос

    Дык поэтому Редхат, Федору и Центос нельзя использовать. А эллиптические кривые очень даже можно.

     
     
  • 3.57, non anon (?), 17:40, 25/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >Дык поэтому Редхат, Федору и Центос нельзя использовать.

    Странная у вас религия... ну да ладно.

    >А эллиптические кривые очень даже можно.

    Но при этом отстегивая денежек держателю патента, мы же не бандиты какие-нибудь!

     
     
  • 4.58, PereresusNeVlezaetBuggy (ok), 17:42, 25/01/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > ... мы же не бандиты какие-нибудь!

    «... мы — благородные пираты!» © Весельчак У

     
  • 4.61, Michael Shigorin (ok), 02:23, 26/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>А эллиптические кривые очень даже можно.
    > Но при этом отстегивая денежек держателю патента

    Основание не подскажете?

     

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



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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