Доступен (http://lists.mindrot.org/pipermail/openssh-unix-announce/201... релиз OpenSSH 5.7 (http://www.openssh.org), открытой реализации клиента и сервера для работы по протоколу SSH версии 1.3, 1.5 и 2.0, и включающей в себя поддержку SFTP.
В новой версии исправлено 18 ошибок и добавлено несколько новшеств:- Реализован режим шифрования по эллиптическим кривым (http://ru.wikipedia.org/wiki/%D0%AD%D0%B... (RFC 5656 (http://tools.ietf.org/html/rfc5656)), который может быть использован для обмена ключами (ECDH) и для хранения ключей хоста/пользователя (ECDSA). По сравнению с ранее поддерживаемыми методами DH и DSA, методы ECDH и ECDSA обеспечивают более высокую производительность, как для идентичных по размеру симметричных ключей, так и для более коротких ключей. В настоящее время реализованы только обязательные секции с...
URL: http://lists.mindrot.org/pipermail/openssh-unix-announce/201...
Новость: http://www.opennet.me/opennews/art.shtml?num=29358
Что-то во всех миррорах последняя портабл версия 5.6. Не появилась еще.
На основном сервере смотрите ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/
Скорость 0,5кб/c круть
На первом попавшемся русском зеркале уже есть:
ftp://ftp.opennet.ru/pub/Mirrors/openssh/
эллиптика и QOS! это же просто отлично!
инкогнито, поделись, как будешь это использовать?
Для начала, видимо, придется 5.7 собрать :) Возможно понадобится openssl 1.0+
Серверные ключи перегенерировать на эллиптические. Это много лучше RSA/DSA, т.к. им для надёжности надо >4096 бит, а это сильно медленно.
А с помощью QoS выставить TOS=0x08 (Minimal delay), это даст высший приоритет для стандартного планировщика пакетов в линуксе.
ЗЫ. это теория, 5.7 ещё не собирал
А какое отношение опенссш имеет к линуксу?
>А какое отношение опенссш имеет к линуксу?Внезапно:
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Это даже если ручками не собирать.
> А какое отношение опенссш имеет к линуксу?Внезапно, линакс - одна из наиболее используемых никс-лайк систем.
openssh, тоже внезапно, в большинстве случаев используется по никс-лайк.И на каждый сервер с openbsd+openssh, по самым скромным оценкам, приходится over 9000 серверов с linux+openssh.
Внезапно, Торвальдс произносит "линукс" как "линукс".
Линус произносит Linux как Линукс.
А с какой целью Вы читаете про сабж?
>А с помощью QoS выставить TOS=0x08 (Minimal delay), это даст высший приоритет для стандартного планировщика пакетов в линуксе.По-моему, это и значение TOS и раньше для openssh по дефолту было (кроме sftp, там maximize-throughput).
>>А с помощью QoS выставить TOS=0x08 (Minimal delay), это даст высший приоритет для стандартного планировщика пакетов в линуксе.
> По-моему, это и значение TOS и раньше для openssh по дефолту было
> (кроме sftp, там maximize-throughput).Именно.
Эй, вы поосторожнее с такими заявлениями! Вдруг кто прочтет и не проверив, начнет использовать.
0x08 это обычно худший класс по латентности, с большими очередями, туда обычно торренты и проч. bulk traffic отправляют, чтобы резать удобнее. Minimal delay это 0x10.
да, вы правы. перепутал, надо 0x10ЗЫ. openssh 5.7p1 собрал, ECDSA ключи проверил — всё работает.
> Серверные ключи перегенерировать на эллиптические. Это много лучше RSA/DSA, т.к. им для надёжности надо >4096 бит, а это сильно медленно.Эээ.. Я конечно сильно извиняюсь, но не равнозначно ли это тому, что ключи сервера во-первых полностью поменяются а во-вторых поменяются таким образом, что, потенциально, не все клиенты их поймут (те, кто кроме как об RSA ничего не слышал)? И что скажут на это клиенты сервера :-? Или он там - клиент - один? Тогда хоть 10к RSA ключ - пофигу..
Ключи не поменяются, а добавится ещё один новый тип. "Не понимающие" клиенты продолжат работать как и ранее по старым ключам.
Ура, наконец-то мы дожили до начала внедрения ECDSA (более стойкий чем RSA/DSA) в open source продукты. Ждём новой версии GnuPG с поддержкой ECDSA.
только ecdsa не совместим со старыми клиентами ((
Верно, широкого (повсеместного) применения придётся ещё немного подождать, но уже процесс пошёл. Пройдёт полгодика и у большинства будут новые версии.
Процесс всегда в процессе )), putty интересно, тоже обновлять придется. Признаться, не ожидал, что совместимость сломается.
Стоп-стоп-стоп... Что именно вы подразумеваете под поломкой совместимости в данном случае?
Новые сервера будут дополнительно генерировать ECDSA host keys (в дополнение к RSA и DSA) и новые версии ssh клиентов смогут при желании сверять отпечатки (fingerprints) именно ECDSA ключей сервера с содержимым локальных файлов known_hosts. Старые же клиенты смогут как и ранее использовать RSA/DSA ключи для идентификации сервера (конечно же при условии что админы сервера специально не удалили RSA/DSA ключи хоста).Аналогично и с пользовательскими ssh ключами: держите в authorized_keys как новый (ECDSA), так и старый (RSA/DSA) ключ, и тогда не будет никаких препятствий к подключению старым ssh клиентом по "старому" ключу к новой версии сервера.
>[оверквотинг удален]
> Новые сервера будут дополнительно генерировать 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 по дефолту плавно отказались.
То, что клиент не обученный ECDSA не способен залогинится с ним, какая ему разница, что зашифровать и отправлять серверу.
> То, что клиент не обученный ECDSA не способен залогинится с ним, какая
> ему разница, что зашифровать и отправлять серверу.Кто вам сказал, что неспособен? Почему вы решили, что сервер обязательно будет поддерживать ТОЛЬКО ECDSA?
Никакая совместимость не сломалась, срочно вернитесь на землю из своих домыслов. :)
> Кто вам сказал, что неспособен? Почему вы решили, что сервер обязательно будет
> поддерживать ТОЛЬКО ECDSA?
> Никакая совместимость не сломалась, срочно вернитесь на землю из своих домыслов. :)То есть, то, что мой клиет ругается на ECDSA ключ это мой домысл?
>> Кто вам сказал, что неспособен? Почему вы решили, что сервер обязательно будет
>> поддерживать ТОЛЬКО ECDSA?
>> Никакая совместимость не сломалась, срочно вернитесь на землю из своих домыслов. :)
> То есть, то, что мой клиет ругается на ECDSA ключ это мой домысл?Ну, встретил он незнакомый тип ключа, и что в этом смертельного? Если у хоста есть DSA-ключ, клиент просто его проверит/заюзает. Я даже специально только что нашёл машину (не мою, у меня там шелл-доступ просто) с OpenSSH 4.5 и зашёл с неё на сервер с ECDSA — всё нормально.
Как Вы сами сказали, есть некая аналогия с SSHv1/SSHv2, но там изменен сам протокол, добавленны новые возможности и тд. А тут всего лишь очередной алгоритм шифрования; клиенту, на мой взгляд, вдоваться в подробности ключа, указуемого мной при аутантификации, нет нужды, знает он алгоритм или нет, сравнение он не производит, значит по необходимости снял защиту парольной фразой, зашифровал сессионным ключом и пусть сервер разбирается что-да-как.Однако не работает. (Именно аутантификация клиента ~5.6 по eсdsa ключу)
Что значит, что: изменение алгоритма ключей не является тривиальной задачей планируемой на этапе разработки протокола. Или, минимум, реализации, то есть привязка к rsa/dsa, а теперь и ecdsa - железобетоннная.
Хотя да, сломали не то слово, был не прав, исправлюсь.
> Однако не работает. (Именно аутантификация клиента ~5.6 по eсdsa ключу)
> Что значит, что: изменение алгоритма ключей не является тривиальной задачей планируемой
> на этапе разработки протокола. Или, минимум, реализации, то есть привязка к
> rsa/dsa, а теперь и ecdsa - железобетоннная.И всё же не пойму, в чём криминал того, что и сервер, и клиент должны знать о ECDSA, чтобы посредством оного разговаривать. :)
> И всё же не пойму, в чём криминал того, что и сервер,
> и клиент должны знать о ECDSA, чтобы посредством оного разговаривать. :)В том, что придется держать два ключа, то есть, нет смысла в новом, потому как, ладно там выпустят оси новые, а встраиваемые (вшиваемые) решения, уже фиг.
>> И всё же не пойму, в чём криминал того, что и сервер,
>> и клиент должны знать о ECDSA, чтобы посредством оного разговаривать. :)
> В том, что придется держать два ключа, то есть, нет смысла в
> новом, потому как, ладно там выпустят оси новые, а встраиваемые (вшиваемые)
> решения, уже фиг.Ну так никто и не заставляет использовать только один ключ. :) Что такого страшного в том, чтобы держать два ключа? Если говорить про встраиваемые решения, то уж коли там заюзан SSH, несколько десятков байт для ещё одного ключа найти, думаю, получится. :) Поддержка ECDSA и та сожрёт больше места, чем этот ключ.
> Ну так никто и не заставляет использовать только один ключ. :) Что
> такого страшного в том, чтобы держать два ключа? Если говорить про
> встраиваемые решения, то уж коли там заюзан SSH, несколько десятков байт
> для ещё одного ключа найти, думаю, получится. :) Поддержка ECDSA и
> та сожрёт больше места, чем этот ключ.Страшного ничего, неудобного - на две кнопки, при входе; и на Nцать при обновлении ключей.
>> Ну так никто и не заставляет использовать только один ключ. :) Что
>> такого страшного в том, чтобы держать два ключа? Если говорить про
>> встраиваемые решения, то уж коли там заюзан SSH, несколько десятков байт
>> для ещё одного ключа найти, думаю, получится. :) Поддержка ECDSA и
>> та сожрёт больше места, чем этот ключ.
> Страшного ничего, неудобного - на две кнопки, при входе; и на Nцать
> при обновлении ключей.При входе?
IdentityFile
Specifies a file from which the user's DSA, ECDSA or DSA
authentication identity is read. The default is ~/.ssh/identity
for protocol version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa and
~/.ssh/id_rsa for protocol version 2.Так что при входе не требуется вообще ничего. А насчёт обновления — если оно производится систематически и на большом количестве хостов, и при этом не автоматизировано... то можно просто отказаться от ECDSA до полного (локального) перехода на поддерживающий его софт, а затем переехать только на него.
Если раскидать ключи по машинам, иначе use -i option, с указанием на шифрованный файл, на шифрованном разделе флешки, лучше перебдеть..Кстате о флэшках, совсем не в тему, но замечательный факт, если на windows7 попытаться отформатировать второй раздел флэшки, она будет отображать процесс и сообщит об успехе, но реально отформатит первый раздел.
> Если раскидать ключи по машинам, иначе use -i option, с указанием на
> шифрованный файл, на шифрованном разделе флешки, лучше перебдеть..
> Кстате о флэшках, совсем не в тему, но замечательный факт, если на
> windows7 попытаться отформатировать второй раздел флэшки, она будет отображать процесс
> и сообщит об успехе, но реально отформатит первый раздел.Причём, если я правильно помню, первым разделом она считает находящийся в первой по счёту записи в MBR, а не первый физически на диске, так?
Этого к сожалению не знаю, знал, что подвох будет, проверил у подруги на ноуте..потом месяц инфу собирал по закоулкам..
> Этого к сожалению не знаю, знал, что подвох будет, проверил у подруги
> на ноуте..потом месяц инфу собирал по закоулкам..Сочувствую. Я просто уже сам не помню, почему на загрузочных флешках делаю загрузочный (с опёнком или ещё чем) раздел последним в MBR, а «виндовый», физически идущий вторым — первым в MBR...
> Как Вы сами сказали, есть некая аналогия с SSHv1/SSHv2, но там изменен
> сам протокол, добавленны новые возможности и тд. А тут всего лишь
> очередной алгоритм шифрования; клиенту, на мой взгляд, вдоваться в подробности ключа,
> указуемого мной при аутантификации, нет нужды, знает он алгоритм или нет,
> сравнение он не производит, значит по необходимости снял защиту парольной фразой,
> зашифровал сессионным ключом и пусть сервер разбирается что-да-как.Прежде всего, клиент ещё и проверяет аутентичность хоста. Который, если поддерживает ECDSA, должен иметь соответствующий ключик. Если он его не имеет, то речи об использовании ECDSA, ессесно, нет. Ну правда, я не пойму, в чём тут проблема?
Толку от этих эллиптических кривых, если использовать нельзя :( Редхат, федора, центос и тд старательно вырезают их поддержку из openssl, положиться на то, что их можно использовать нельзя, они и с openssh наверняка так же будут делать.
> Толку от этих эллиптических кривых, если использовать нельзя :( Редхат, федора, центос
> и тд старательно вырезают их поддержку из openssl, положиться на то,
> что их можно использовать нельзя, они и с openssh наверняка так
> же будут делать.Можно подробнее (ссылка, причины)? Я просто не в курсе.
редхат:
$ 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 , ну и в рассылках редхата можно почитать детали.
> Причины наверное здесь http://en.wikipedia.org/wiki/ECC_patents , ну и в рассылках редхата
> можно почитать детали.Н-дя. Знакомимся с ещё одним патентным троллем, похоже, — после описания по ссылке столкновения Certicom с Sony.
По крайней мере OpenSSH разрабатывается не в США, так что этот бред к нему не относится. Пользуйтесь ECC на здоровье. :)
> Можно подробнее (ссылка, причины)?
Ну, не у всех редхатоподобные. Глянем, чтов дебиане будет.
> Ну, не у всех редхатоподобные. Глянем, чтов дебиане будет.Учитывая, как они борются с лицензионными и патентыми подставами, можно утверждать: этот трап там тоже выпилят, инфа 100%.
// В сквизе команда openssl ecparam есть, но она тупо ничего не делает.
> Редхат, федора, центос и тд старательно вырезают их поддержку из opensslхм, порадуемся за убунту?! там поддержка ecc есть, даже в lucid
> Толку от этих эллиптических кривых, если использовать нельзя :( Редхат, федора, центос
> и тд старательно вырезают их поддержку из openssl,А с чем это связано?
Патенты, батенька, патенты. Редхат находится в США, а там софтварные патенты. В общем огребаем тех же проблем, как раньше с .gif, RSA, нынче .mp3, h264 и тд.
> Толку от этих эллиптических кривых, если использовать нельзя :( Редхат, федора, центосДык поэтому Редхат, Федору и Центос нельзя использовать. А эллиптические кривые очень даже можно.
>Дык поэтому Редхат, Федору и Центос нельзя использовать.Странная у вас религия... ну да ладно.
>А эллиптические кривые очень даже можно.
Но при этом отстегивая денежек держателю патента, мы же не бандиты какие-нибудь!
> ... мы же не бандиты какие-нибудь!«... мы — благородные пираты!» © Весельчак У
>>А эллиптические кривые очень даже можно.
> Но при этом отстегивая денежек держателю патентаОснование не подскажете?