Секция 2 из 2 - Предыдущая - Следующая

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

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

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

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

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

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

Если вы используете 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 -> rsync, который специально был написан для работы с ssh и гораздо лучше адаптирован к пропускной ширине канала. Более подробно об rsync смотрите на ftp://samba.anu.edu.au/pub/rsync или ftp://sunsite.auc.dk/pub/unix/rsync.

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

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

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

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

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

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

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

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

Допустим вы находитесь на компьютере называемом "myhost" и хотите произвести ftp соединение с компьютером под именем "ftphost". Тогда на компьютере myhost" необходимо воспользоваться перенаправлением TCP через ssh:

myhost$ ssh -L 1234:ftphost.example.com:21 ssh-server

Теперь в другом окне на компьютере "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.

к переводу:
от себя замечу, очень давно, те старые 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?

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

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

5. Проблемы.

Если вы хотите опубликовать bug report[сообщение об ошибке], отправьте письмо по адресу ssh-bugs@clinet.fi содержащее следующее:

• Номер версии ssh и если отличаются - sshd
• Что вы обнаружили в действиях ssh
• Что ssh выполнил вместо положенного(включая сообщения обо всех ошибках)
• Какую систему вы используете (например, вывод от uname -a), и вывод config.guess.
• В случае проблем при компиляции, содержимое файла config.log (сгенерированного посредством configure)
• Какой компилятор вы использовали и все флаги компиляции
• Вывод произведенный от ssh -v
• Вывод от sshd daemon запущенного в отладочном режиме, как sshd -d

5.1 "ssh otherhost xclient &" не работает!

5.2 Ssh сбоит в Solaris, вылетая с сообщением "Resource temporarily unavailable".

Если вы обнаружили подобные проблемы в Solaris 2.5.1, просто установите более свежую версию ssh - 1.2.14 или еще свежее, это должно решить ваши проблемы.

5.3 Sshd зависает в Solaris 2.5!

Получите и установите патч 103187-02 (for x86, 103188-02) для решения этой проблемы. Данная проблема возможна решена в Solaris 2.5.1.

5.4 Перенаправление X11 не работает в случае выполнения SCO-binary под Linux в режиме iBCS2 эмуляции.

5.5 Ssh не работает или ошибается в случае multi-homed hosts!

5.6 Userid swapping обрывается в AIX!

5.7 ssh-keygen вываливает в core под Alpha OSF!

Отключите всю оптимизацию для ssh-keygen, или используйте gcc. Заметьте что Gcc 2.7.2 имеет проблемы на Alpha и тем не менее.

5.8 ssh-keygen вываливает в core под Solaris или SunOS.

5.9 В Linux, компиляция прерывается с сообщениями об ошибках связанных с библиотекой libc.so.4.

5.10 X authorization иногда терпит крах[иными словами не проходит].

5.11 Ssh требует ввести пароль несмотря на наличие на удаленной машине файла .rhosts!

• "host key" клиента не содержится в файле "known_hosts". Это характерно лишь для FQDN формы, а точнее для канонического имени машины из DNS.
• Клиент host не имеет реверса в DNS. SSH требует наличия как прямой, так и обратной записи, для проверки естественно.
• Когда в DNS отражены не все ip-address принадлежащие multi-homed клиенту, host. Заметим что ssh версии по 1.2.12 имеют ошибки в плане разбора multi-homed hosts.
• Домашняя директория пользователя или файл ~/.rhosts имеют разрешение на запись для "world" или "group".(см. StrictModes опции конфигурации сервера) По русски это будет - "а шо вы хотели".
• На некоторых машин, если домашняя директория монтируется по NFS, желательно чтобы и директория и ~/.rhosts были доступны для "world" на чтение.
• Сам "root" использует ~/.rhosts или ~/.shosts; ну и ему нет дела до /etc/shosts.equiv и /etc/hosts.equiv, так попросите чтобы "root" их посмотрел.
• Неразбериха между RhostsRSAAuthentication и RSAAuthentication.

 

RhostsRSAAuthentication функционально заменяет 'r' утилиты; это требует чтобы программа ssh имела "setuid root", "secret key" в /etc/host_key файле, соответствующий "public key" в /etc/ssh_known_hosts и запись в ~/.[sr]hosts или /etc/[s]hosts.equiv.

RSAAuthentication выполняется на уровне пользователя и требует наличия ~/.ssh/identity со стороны клиента(сгенерированного ssh-keygen) и файла ~/.ssh/authorized_keys со стороны сервера.

5.12 Почему ssh зацикливается с сообщением "Secure connection refused"?

Ssh пытается вернуться к методу "r" команд когда не может соединиться с sshd демоном удаленной машины и в результате пытается запустить старый rsh для использования старого протокола.

Существуют всего два предположения почему это происходит:

• Возможно вы установили ssh как rsh и забыли задать опцию при конфигурировании --with-rsh=PATH и в результате поисков rsh, ssh находит вместо него себя и снова запускает. Просто перекомпилируйте ssh с учетом сказанного.
• Вы переместили старые rsh и rlogin в другую директорию, отличную от оригинального места расположения, но при этом вызов осуществляете корректно, те из того места куда положили. Но при этом не учли что старый исполняемый модуль rsh содержит в своем теле жестко-привязанный путь к rlogin.

 

В этом случае вы можете перенести старые бинарники rsh и rlogin в /usr/old, отпатчить их с запустив Perl скрипт

perl -pi.orig -e 's+/usr/(bin|ucb)/rlogin+/usr/old/rlogin+g ;' /usr/old/rsh

который поправит двоичные модули и положит их в /usr/old/rsh.orig.

И теперь осталось переконфигурировать ssh с --with-rsh=/usr/old/rsh.

5.13 ssh-agent не работает с эмулятором терминала rxvt!

5.14 X authorization ВСЕГДА завершается неудачно.

Это также могло произойти при сборке ssh с --with-libwrap и необходимая sshdfwd-X11: строка отсутствует в файле /etc/hosts.allow те в файле не указан host с которого разрешено заходить.

5.15 ssh зависает когда перенаправляет много TCP соединений.

Некоторые изменения были сделаны в протоколе версии 1.2.14 чтобы избежать этого, но проблема межде версией 1.2.14 и более ранними осталась. Установите более свежие версии ssh, желательно последние и с обоих сторон.

5.16 Что означает сообщение, "Warning: remote host denied X11 forwarding"?

5.17 Я продолжаю наблюдать чистые[некриптованные] пакеты в сети хотя работаю под ssh!

5.18 Возникают проблемы с RSAREF, иногда используется очень много бит!

5.19 Компиляция завершается с сообщениями об ошибках от ассемблера.

make distclean
configure --disable-asm

5.20 Ssh не компилируется под Solaris 2.5!

5.21 Ssh неожиданно сбрасывает соединения!

Попробуйте применить следующие правки к 1.2.16 or 1.2.17 for a fix. Это исправлено в 1.2.18 и позже.

--- serverloop.c.orig   Tue Jan 21 14:38:25 1997
+++ serverloop.c.       Tue Jan 21 14:37:54 1997
@@ -405,7 +405,7 @@
                  buffer_len(&stdin_buffer));
       if (len <= 0)
        {
-         if (errno != EWOULDBLOCK)
+         if ((errno != EWOULDBLOCK) &amp;&amp; (errno != EAGAIN))
            {
              if (fdin == fdout)
                shutdown(fdin, 1); /* We will no longer send. */

5.22 Ssh соединения перенаправляются от "root"-а!

Среди других потенциальных проблем, такая как перенаправление соединений через -Lx:host:port будет выполнять соединение "host:port" от "root uid", с того моммента как first дочерний процесс стартует. А это означает что когда заданный компьютер попытается идентифицировать от какого пользователя идет запрос, он получит что от "root", вместо реального пользовательского uid.

Это ситуация продолжает оставаться известной как "ошибка", и неизвестно будет ли данная технологическая проблема исправлена в следующих реализациях.
 

5.23 Где можно найти правки[patches] для ssh?

http://www.ncsa.uiuc.edu/General/CC/ssh/patch_repository/

Его комментарии:

"Я выложил правки сделанные нами, плюс которые были _постированы_ в конференции и несколько мне неизвестных. Имеется страница с описание этих правок, но если у кого то имееются дополнительные сведения дайте мне знать. Большинство правок относится к версии 1.2.x, но я с успехом использовал многие для 2.0.x."

6. Разное.

6.1 Какие ошибки "безопасности" известны и в каких версиях ssh?

• Все версии ssh по 1.2.12 имели серьезный недостаток в безопасности который позволял локальному пользователю получить доступ к секретному ключу компьютера - "host key". Это было исправлено во всех последующих версиях начиная с 1.2.13.

• Если вы используете 1.2.13 на Alpha OSF 1.3 или SCO в C2 режиме, локальные пользователи могут получить "root" доступ. Исправить это можно с помощью patch ftp://ftp.cs.hut.fi/pub/ssh/ssh-osf1-c2-setluid.patch или заменой на версию 1.2.14 или более позднюю.

• Версии ssh по 1.2.17 имели проблемы с обработкой подлинности проверки агента на некоторых машинах. Есть шанс(a race condition/кто обгонит :) который мог позволить злоумышленнику украсть чужие credential[удостоверения]. Это исправлено и в 1.2.17 и соответственно в следующих версиях.

• Метод шифрования "arcfour" в некоторых ситуациях делал ssh протокол очень чувствительным, это касалось первых версий "1", однако впоследствии он был отключен начиная с версии 1.2.18.

• В версиях до 1.2.23 использовался CRC32 метод компенсации атак, который в свою очередь позволял возможность выполнения случайных команд. Для более подробного ознакомления смотрите http://www.core-sdi.com/ssh.

6.2 Насколько широкое распространение получило использование ssh?

Как и в отношении любого свободно распространяемого продукта, сложно сделать прогноз предполагаемого количества использующих ssh. Уместнее будет оценка того что более 1000 институтов в 40 странах используют ssh, а данная оценка основана на

• количестве людей из списка рассылки ssh, около 600 из 40 разных стран и нескольких сотен доменов
• Каждую неделю к домашней www-странице ssh производят доступ с 5000 различных машин, многие из которых являются в свою очередь web-кешами и адреса машин с которых приходят запросы меняются каждую неделю.

6.3 Вам не нравятся коммерческие аспекты в ssh...

Ssh проложил курс в стандарты интернет и это подразумевает что нужны новые, вторичные, независимые разработки его применения.

Вы должны осозновать что методы шифрации RSA,IDEA запатентованы и необходимо получить соответствующие разрешения для написания второй реализации.

6.4nbsp;Средства альтернативные SSH.

• srp: http://srp.stanford.edu/srp/
• stunnel: http://mike.daewoo.com.pl/computer/stunnel/
• ssleay-related: http://www.psy.uq.edu.au:8080/~ftp/Crypto/

6.5 Заслуги.

Спасибо Thomas.Koenig написавшему оригинальный FAQ еще по версии SSH1.

Спасибо "списку-рассылки" ssh за предоставленные вопросы и ответы отраженные в данном документе.

Секция 2 из 2 - Предыдущая - Следующая

© faqs.org.ru