В недрах Суперкомпьютерного центра города Питсбург (США), в рамках проекта HPN-SSH (http://www.psc.edu/networking/projects/hpn-ssh/), код OpenSSH был модифицирован для работы в многопоточном (multi-threading) режиме, что позволило значительно увеличить производительность работы ssh на системах с многоядерными CPU. Например, при сравнении производительности на 8-и ядерном CPU, была обеспечена в двое большая скорость передачи данных.
Классический OpenSSH одновременно может использовать только одно ядро процессора, что является узким местом в оптимизации производительности операций шифрования. Разработчики OpenSSH отрицательно относятся к распараллеливанию криптографических операций, считая что это понижает безопасность.
Целью проекта HPN-SSH (http://www.psc.edu/networking/projects/hpn-ssh/) является создание модификации OpenSSH, обеспечивающей максимально возможную производительность. Ранее проектом были представлены патчи к OpenSSH, устраняющие ряд узких мест в механизме буферизации, как в серверной, так и в клиентской части, что позволило значительно (примерно в 10 раз) увеличить скорость пересылки большого объема данных. Для организации сверхскоростной передачи данных был разработан дополнительный патч, позволяющий передавать данные без шифрования, за исключением стадии аутентификации.URL: http://lwn.net/Articles/269075/
Новость: http://www.opennet.me/opennews/art.shtml?num=14197
Никогда не думал, что современные процессоры затрудняются криптовать данные со скоростью локальных сетей. Разве что гигабит может загрузить - на двухгигагерцовом процессоре получается, что на каждые 32 бита (размер регистра) приходится всего 64 такта...А может, пора делать криптопроцессоры по типу того, как раньше были float-сопроцессоры? Regex-сопроцессоры уже существуют...
А вы по ссылке сходите, там написано.
Дмитрий, а вы посмотрите, что у вас между двумя рядом стоящими компами будет. У меня на 100Мбит/с получается 10-11 Мб/с ftp и 2 Мб/с SCP. Компы оба Athlon x64 3000+ / 3200+, один винда, второй freebsd. Между фряшкой на каком-то Xeon-е и такой было 3 Мб/с, точнее цифры искать лениво, но вроде порядок примерно понятен. Само собой, сами эти цифры достаточны, но при большом кол-ве потоков / другой загрузке на комп - уже может и не хватать....AFAIU, у сантехников есть сопроцессор для выполнения задач шифрования по SSL, значит, актуально :)
Вчера перекачивал с двух рядом стоящий компов по езернету - 10 Мб/s через sftp. Помнится, года 3 назад скорость была горзадо меньше. На одном компе убунта, на другом - дебиан. Частоты 1.8 и 1.7.
> Вчера перекачивал с двух рядом стоящий компов по езернету"Вчера перечитывал "Три поросенка", много думал."
И какая связь с темой обсуждения? :)
Бросьте. Вы не правы. Может быть у Вас в WinSCP стоит дикое шифрование. Без плясок с бубном и прочей лабуды между двумя машинами (если кому-то принципиально: Debian 3.1r7 и Gentoo) штатный scp выдаёт 11МБ/с, когда сеть свободна. А вот WinSCP действительно сильно затупляет процесс, не совсем понятно почему. Поставьте шифрование Blowfish - вроде максимально быстро должно быть. Шифрование не является узким местом, по крайней мере на FastEthernet.
WinScp не нужно дикое шифрование, оно просто само по себе тормознутое :( почему не знаю но разница как мне кажеться 4-5 раз с обычным scp на подобных машинах, подробного изучения не производил, поэтому точно сказать не могу.
Бросил. Я правда не прав. Извините =) Две фряшки гуляют на 10 МБ/с. А WinSCP тормозит с дефолтным шифрованием(там AES). 3DES выдает уже 4.5 Мб/с. Blowfish выдаёт >7 Мб/с, самый шустрый получается. Хотя там еще DES есть, он >9 Мб/с делает, но это уже пахнет несекурной передачей :D
Проверил заодно copssh, сиречь виндовая реализация(билд?) openssh - выдает спокойно 10 Мб/с.
Спасибо за пинок!
>Дмитрий, а вы посмотрите, что у вас между двумя рядом стоящими компами
>будет. У меня на 100Мбит/с получается 10-11 Мб/с ftp и 2
>Мб/с SCP. Компы оба Athlon x64 3000+ / 3200+, один винда,
>второй freebsd. Между фряшкой на каком-то Xeon-е и такой было 3
>Мб/с, точнее цифры искать лениво, но вроде порядок примерно понятен. Само
>собой, сами эти цифры достаточны, но при большом кол-ве потоков /
>другой загрузке на комп - уже может и не хватать....
>
>AFAIU, у сантехников есть сопроцессор для выполнения задач шифрования по SSL, значит,
>актуально :)1) WINSCP хотя и пользуется популярность, но что-то со скоростью у него не то
Возъми FileZilla для Windows - будет тебе скорость 10-12 Mbit/sec2) Между двумя FreeBSD - теже 11 Mbit/sec стабильно
разьве файлзилла умеет SCP?
Аккуратнее, о 10-12 Mbit/s речь не идёт, речь идёт о Mbyte/s. И Filezilla и правда не умеет SCP, но зато умеет SFTP....
Вы таки сильно удивитесь, но криптокарты существуют ОЧЕНЬ давно. С тех пор когда процессоры были большие, но слабые и криптовали слишком медленно.
??? Вы это к чему?? С чего Вы взяли, что я удивлюсь этому факту?? Железный впн и прочие железные шифровалки существовали и существуют и с тем же самым успехом будут продолжать существовать. И для меня это не секрет. Если что-то в моих высказываниях показалось кривым - давайте обсудим.
>Для организации сверхскоростной передачи данных был разработан дополнительный патч, позволяющий передавать данные без шифрования, за исключением стадии аутентификации.Дайте! Вот же оно счастье - рядом!
>Для организации сверхскоростной передачи данных был разработан дополнительный патч,
>позволяющий передавать данные без шифрования, за исключением стадии аутентификации.Это что - шутка, что ли???
Нет - не шутка! Это - офигительная замена FTP. Через честный SFTP - слишком медленно и напряжно для тазика.
>Нет - не шутка! Это - офигительная замена FTP. Через честный SFTP
>- слишком медленно и напряжно для тазика.Или я чего-то не понимаю в данном случае, или... "на этом мысль останавливается" (с)
Потому как лично мне кажется, что главное, ради чего используют ssh - так это ради безопасности и конфиденциальности. А этот патч на мой взгляд делает использование ssh просто бессмысленным.
>>Нет - не шутка! Это - офигительная замена FTP. Через честный SFTP
>>- слишком медленно и напряжно для тазика.
>
>Или я чего-то не понимаю в данном случае, или... "на этом мысль
>останавливается" (с)
>Потому как лично мне кажется, что главное, ради чего используют ssh -
>так это ради безопасности и конфиденциальности.Дык у Вас SCP и SFTP с полным шифрованием никто ведь не отбирает. Юзайте какой хотите из вариантов.
Ну почему же, Ваш логин/пароль защищает. А скачиваемый длинный файл не всегда шифровать нужно. Например, просто качаете большой архив исходников.
А зачем тогда качать его через scp/sftp?
Впрочем, не буду настаивать на своей точки зрения, тем паче, как тут подсказывают товарищи, озабоченным безопасностью оставлен прежний вариант работы, и слава богу.
>А зачем тогда качать его через scp/sftp?Вы стебётесь или не в курсе, что ftp авторизует plain text'ом? Или трудно понять, что допустим, при сливании какой-нить двд не хочется палить/менять_тут_же_на_новый пароль, а авторизация требуется.
А вы не в курсе, что для быстрого скачивания неконфиденциальной информации существует анонимный ftp?Давайте конкретизировать - какие именно данные сливаются и откуда. "Какая-нибудь dvd" обычно с анонимных ftp и качается. А корпоративная документация или БД - обычно с ними работают по защищенному каналу, где секретить нужно не только логин/пароль, но и сами данные в обязательном порядке. То же относится и к какой-либо вашей личной информации. Я говорю за последние варианты. Все остальное можно передавать без шифрования и аутентификации.
Впрочем, как я уже сказал, раз выбор использовать или не использовать этот патч остается за конечным пользователем, то у меня нет больше вопросов.
>Давайте конкретизировать - какие именно данные сливаются и откуда.Давайте. ftp я не люблю и не держу на серверах. А вот забирать всякую хрень вроде музыки, исошников с новыми дистрами мои подопечные периодически изъявляют желание. Вот и приходится им осваивать сцп в тех местах, где нет самбы.
updated:
Хотя конечно в основном всё хранится на файлопомойке самбовской. А дистры раздаются
действительно через ftp (для сетевой загрузки и установки). Но делать анонимный фтп на upload желания никакого нет. Тут scp само то.
>>Давайте конкретизировать - какие именно данные сливаются и откуда.
>Давайте. ftp я не люблю и не держу на серверах. А вот[разводит руками] SCIF, уважаемый, ну здесь уже речь пошла о предпочтениях и религиях...
Ваш вариант вполне себе имеет право на существование, и для вас (и всех, кто разделяет ваши вкусы/убеждения или просто волей обстоятельств находится в аналогичной ситуации) это действительно наилучший выбор. Признаю, что не учел всех аспектов, проявил некоторую узколобость, так сказать. :)
>[разводит руками] SCIF, уважаемый, ну здесь уже речь пошла о предпочтениях и
>религиях...Извиняюсь, что не совсем красиво написал вначале, но далее упоминул основную мысль - я всё-таки желанию, чтобы аплоадом файликов занимались люди имеющие шелл на сервере.
>Извиняюсь, что не совсем красиво написал вначале, но далее упоминул основную мысль
>- я всё-таки желанию, чтобы аплоадом файликов занимались люди имеющие шелл
>на сервере.Ну тут без возражений...
Чесс - слово удивил 8-)
В дополнение - фотки. Они при современных матрицах меньше 2М редко бывают. Я с автошоу влегкую приношу ~300 штук, с пикника ~50.
"Автошовные" - могу выложить в публичный доступ, а "пикник'овские" - НЕТ! Там - я и мои друзья и мы приняли коньяку по банке на нос и нам хорошо .... но Вас это не касается - это только наше "семейное" дело ,) Фотики есть у всех, народ хочет обмениваться. При этом если злой агент моссада Ваня Шенкель все таки захочет этих фоток - он их получит. А вот ты - нет! :)С фтп - постоянно переживаешь - не сломали ли? А уж через фиревалы его пробросить - под силу только АйТИшникам :( эСэСэйЧ - обычно везде ходит (изнутри -> наружу).
Ну понял надеюсь.
еще пример. у нас cvs работает через ssh. так вот сам трафик нафиг не надо шифровать, а авторизация по ключам идет. а файлики бывают не мелкие.
>Ну почему же, Ваш логин/пароль защищает. А скачиваемый длинный файл не всегда
>шифровать нужно. Например, просто качаете большой архив исходников.Или корку приложения на фтп разработчика залить :)
>Ну почему же, Ваш логин/пароль защищает. А скачиваемый длинный файл не всегда шифровать нужно. Например, просто качаете большой архив исходников.Воооот! Сразу видно у кого сервера, а кто проста дома сам-себе админ :)
Защитники метода "шифровать только пароль" так и не привели ситуацию, которая бы наглядно иллюстрировала бы необходимость шифрования не всего подряд. Итак:
У меня есть общедоступный сайт, состоящий из статического HTML (без скриптов). Я заливаю на него свои файлы, залогинившись по имени и паролю. И мне не страшно, если кто-то прочитает заливаемые файлы; зато страшно, что кто-то узнает мой пароль и сам зальёт на мой сайт своё барахло. Шифровать в данном случае надо только пароль входа на сервер.
>Защитники метода "шифровать только пароль" так и не привели ситуацию, которая бы
>наглядно иллюстрировала бы необходимость шифрования не всего подряд.Чем Вам не понравился приведённый мною вариант??
> И мне не страшно, если кто-то прочитает заливаемые файлы; зато страшно, что кто-то узнает > мой пароль и сам зальёт на мой сайт своё барахло.
Не передёргивайте.
> Чем Вам не понравился приведённый мною вариант?Он труднее для понимания, чем вариант с заливкой на сервер.
А еще бывают спутниковые каналы и рыбаки(граббинг).
Не все сидят на оптоволокне, мы вот пользуем спутниковый интернет.
Защита конфиденциальности не на последнем месте.
ssh это не только консоль но еще и портмаппинг через который бывает надо прокачивать весьма изрядный трафик, так что пусть будет выбор, это всегда лучше.
Вопрос к знатокам - а есть ли реализация ssh\sftp сервера на базе библиотеки GnuTLS?