The OpenNET Project / Index page

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

Каталог документации / Раздел "Безопасность" / Оглавление документа

4. Приложения Ssh.

Содержание этой главы

4.1 Можно ли выполнять "backups" поверх ssh?

Да. С тех пор как ssh технологически заменяет rsh, "backup" скрипты должны полностью работать. Если же вы пользуетесь "rdist", читайте ниже.

4.2 Нужно ли отключать криптования для увеличения производительности?

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

На сегодняшний день быстродействие 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.

4.3 Можно ли использовать ssh для работы через firewall?

Даж вы можете использовать перенаправление TCP для этого, те посредством предоставляемых возможностей безопасного перенаправления TCP соединений.

4.4 Можно ли использовать rdist совместно с ssh?

Исходный rdist 6.1.0 не работает с ssh, из-за ошибок имеющихся в нем. Однако начиная с версии rdist 6.1.1 и более поздних разработчики завявляют об уверенной работе с ssh. Rdist доступен:  http://www.magnicomp.com/rdist/

Если вы используете 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.

4.5 Можно ли использовать ssh для безопасного соединения двух подсетей через Internet?

Вы можете запустить PPP через постоянное ssh соединение. Смотрите: http://www.inka.de/~bigred/sw/ssh-ppp-new.txt как рабочее решение. И хорошая идея использования для этого сжатия.

Однако здесь имеются _подводные_ камни связанные с перенаправлением TCP соединений. Потому что ретрансляция может произойти в одно и тоже время как TCP соединения через ssh так и TCP перенаправления через PPP/ssh туннель. Так что в данном случае лучше использовать криптованный IP-туннелинг по UDP, а о возможностях можно прочитать в проекте CIPE: http://www.inka.de/~bigred/devel/cipe.html .

4.6 Можно ли использовать ssh для перенаправления UDP-сервисов, таких как NFS или NIS?

Существует достаточно рабочее решение для RPC-based сервисов, таких как NIS. Которое можно взять с: ftp://ftp.tu-chemnitz.de/pub/Local/informatik/sec_rpc/. NIS практически полностью работоспособен.

В принципе, можно сделать реализацию для NFS, но пока еще не сделано.

Сетевые сервисы, которые полностью реализованы на UDP, такие как DNS, пока еще не реализованы в ssh, однако это принципиально возможно.

4.7 Можно ли перенаправлять SGI GL соединения поверх ssh?

Он совершено не подходит технологически для реализации. GL использует протокол совершенно отличный от X, но по-крайней мере gld может быть заменен.

OpenGL, запускаемый как расширение X-сервера не должен создавать проблем. Вам лишь необходимо установить переменную среды GLFORCEDIRECT=no.

4.8 Можно ли использовать ssh для защиты таких сервисов как FTP или POP?

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

Допустим вы находитесь на компьютере называемом "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 остается подверженной похищению и подмене.

4.9 Можно ли использовать ssh через Socks firewall?

Поддержка Socks 4 и 5 должна работать в ssh1 версии 1.2.16 и более поздних.
Поддержка Socks должна работать в ssh2 версии 2.0.11 и более поздних.

4.10 Поддерживает ли ssh работу с AFS/Kerberos?

В настоящий момент поддержка AFS/Kerberos отсутствует в исходных материалах, но доступны AFS patch[правки] для версии 1.2.x с http://www-personal.umich.edu/~dugsong/ssh-afs-kerberos.html

или другое место:
http://www.ncsa.uiuc.edu/General/CC/ssh/ssh_ncsa_mods.html


Следующая Глава, Предыдущая Глава

Содержание этой главы, Общее Содержание

В начало документа, В начало этой главы


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

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