На сегодняшний день быстродействие CPUs[процессоров] таково, что снижение производительности[на шифрации-дешифрации] если оно и есть? возможно заметить лишь на скоростях локального Ethernet или более быстрых сетей.
Тем не менее вы можете использовать метод шифрации "blowfish" вместо IDEA, который работает по умолчанию, для увеличения производительности, достаточно задать опцию -c blowfish.
Оцените приведенные ниже результаты измерений скорости передачи для разных методов шифрации между двумя компьютерами P5/90 и 486/100, оба под управлением OS Linux, файлы передавались с использованием "scp" по сильно загруженному Ethernet.
Была выбрана модель t=a+x/b; где a - _пусковое_ время, b - установленная
скорость передачи. Также был использован коэффициент 68.3% confidence intervals
для данных, как определено по алгоритму Levenberg-Marquardt примененному в версии pre-3.6 gnuplot.
Encryption a[s] da[s] b[kB/s] db[kB/s]
none 2.37 0.37 386.1 5.8
rc4 1.96 0.27 318.2 2.9
tss 2.33 0.37 298.5 3.5
des 2.07 0.19 218.8 1.0
idea 2.25 0.45 169.6 1.3
3des 1.92 0.11 118.2 0.2
При передаче через сильно нагруженный Ethernet, использование rc4 метода шифрации вместе со сжатем будет действительно значительно быстрее чем использование rcp.
Если вы используете rdist, то не забудьте при его компиляции задать ему путь к ssh. Дополнительно можно можно использовать опцию -P, чтобы rdist использовал ssh вместо rsh.
Если вы используете проверку пароля, в версиях rdist с 6.1.2 по 6.1.5, вам
необходимо применить приведенный ниже patch[правка]:
--- src/rshrcmd.c.orig Tue Jun 11 16:51:21 1996
+++ src/rshrcmd.c Tue Jun 11 16:52:05 1996
@@ -63,7 +63,7 @@
/* child. we use sp[1] to be stdin/stdout, and close
sp[0]. */
(void) close(sp[0]);
- if (dup2(sp[1], 0) < 0 || dup2(0,1) < 0 || dup2(0, 2) < 0) {
+ if (dup2(sp[1], 0) < 0 || dup2(0,1) < 0) {
error("dup2 failed: %s.", SYSERR);
_exit(255);
}
<p>
Данную правку необходимо применить если при работе rdist вы получаете сообщение
"Warning: Denied agent forwarding because the other end has too old version." данная ошибка возникает при соединение ssh-клиента 1.2.27 или более
позднего со старыми версиями ssh-сервера.
Другой путь использовать в качестве замены rdist -> rsync, который специально был написан для работы с ssh и гораздо лучше адаптирован к пропускной ширине канала. Более подробно об rsync смотрите на ftp://samba.anu.edu.au/pub/rsync или ftp://sunsite.auc.dk/pub/unix/rsync.
Однако здесь имеются _подводные_ камни связанные с перенаправлением TCP соединений. Потому что ретрансляция может произойти в одно и тоже время как TCP соединения через ssh так и TCP перенаправления через PPP/ssh туннель. Так что в данном случае лучше использовать криптованный IP-туннелинг по UDP, а о возможностях можно прочитать в проекте CIPE: http://www.inka.de/~bigred/devel/cipe.html .
В принципе, можно сделать реализацию для NFS, но пока еще не сделано.
Сетевые сервисы, которые полностью реализованы на UDP, такие как DNS, пока еще не реализованы в ssh, однако это принципиально возможно.
OpenGL, запускаемый как расширение X-сервера не должен создавать проблем. Вам лишь необходимо установить переменную среды GLFORCEDIRECT=no.
Допустим вы находитесь на компьютере называемом "myhost" и хотите произвести
ftp соединение с компьютером под именем "ftphost". Тогда на компьютере myhost"
необходимо воспользоваться перенаправлением TCP через ssh:
myhost$ ssh -L 1234:ftphost.example.com:21 ssh-server
Выполнив эту команду вы войде на компьютер "ftphost", а порт "myhost":1234
будет перенапрвлен с использованием ширования на "ftphost":21.
[от себя добавлю что теперь это окно у вас как бы в холостом режиме, но вы можете в нем поработать... ;-)]
Теперь в другом окне на компьютере "myhost", можете запускать клиента ftp следующим образом:
myhost$ ftp localhost 1234
220 ftphost FTP server (Foonix 08/15) ready.
Name: (myhost:yourname):
331 Password required for yourname
Password:
230 User yourname logged in.
Это работает в том случае если удаленный ftp daemon[сервер] позволяет выполнять
PORT команды с указанием адреса host'а отличным от того с которого
поступают команды[типа proxy] и если ftp-client тоже использует PORT.
Это работает для "vanilla" Unix ftp клиентов и серверов, но может не работать
для продвинутых FTPD-серверов, таких как wu-ftpd.
к переводу:
от себя замечу, очень давно, те старые wu-ftpd у меня без проблем работали в пассивном
режиме, а вся проблема упиралась в клиентскую часть, замечено на Convex-OS/SPP-UX[якобы HP]/HP-UX/OSF1.
Решение простое, "man ftp" и если вы нашли там возможность использования пассивного режима PASV, например команда proxy, возможно вам повезло, еще проще - да
поставьте вы какой-либо из продвинутых ftp-клиентов их сейчас масса.
Для определения с какой стороны обрезается, не поддерживается пассивный режим возьмите заведомо работающие клиент или сервер и посмотрите диагностику.
Для POP, Stephane Bortzmeyer (bortzmeyer@pasteur.fr) написал скрипт который защищает передачу пароля и данных используя ssh. Он не требует изменений существующих POP клент-сервера и доступен с ftp://ftp.internatif.org/ pub/unix/gwpop/ .
Другие сетевые сервисы можно также обезопасить подобным образом. Однако стоит отметить что передача нешифрованных _данных_ ftp остается подверженной похищению и подмене.
или другое место:
http://www.ncsa.uiuc.edu/General/CC/ssh/ssh_ncsa_mods.html
Следующая Глава, Предыдущая Глава
Содержание этой главы, Общее Содержание
В начало документа, В начало этой главы