Ssh (Secure Shell)
Frequently asked questions
[Русская редакция]

1. Общие[сопутствующие]-вопросы.

2. Основы Ssh.

3. Где взять и как установить ssh.

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

5. Проблемы.

6. Разное.

1. Общие[сопутствующие]-вопросы

1.1 Где я могу взять это описание?

Последняя,оригинальная версия[in english] этого документа доступна по адресу http://www.employees.org/~satch/ssh/faq.

Несомненно, интерес представляет домашняя страница SSH http://www.ssh.fi/sshprotocols2.

Этот FAQ был создан на основе оригинального, устаревшего на данный момент FAQ по SSH1 [SSH Protocol-1]: http://www.uni-karlsruhe.de/~ig25/ssh-faq/index.html
(написан Thomas.Koenig@ciw.uni-karlsruhe.de)

1.2 Куда я могу послать вопросы, поправки и тд, по этому документу?

Пожалуйста шлите их сопровождающему этот FAQ, Steve Acheson (satch@employees.org)

2. Основы Ssh.

2.1 Что такое ssh?

Выдержка из README файла:

Ssh (Secure Shell) это программа для входа в другие компьютеры доступные по сети, для выполнения команд или программ на удаленных компьютерах и для передачи файлов с одного компьютера на другой. Она обеспечивает строгую проверку подлинности и безопасности соединений по незащищенным каналам. И используется как замена rlogin, rsh, и rcp.

Дополнительно, ssh обеспечивает безопасность X-овых соединений и безопасное перенаправление иных, необходимых вам TCP соединений.

2.2 Почему желательно использовать ssh?

Традиционные BSD 'r' - команды (rsh, rlogin, rcp) уязвимы для различных видов хакерских атак. Кроме того, если кто-то имеет "привелигерованный"[root] доступ к машинам сети или возможность физического подключения к сетевым коммуникациям, то это позволит собирать весь проходящий траффик, как входной, так и выходной включая пароли, поскольку TCP/IP является "чистым" протоколом (ssh никогда не посылает пароли в чистом виде).

X Window System имеет тоже достаточное количество "узких" мест в плане безопасности. Но с помощью ssh можно создавать безопасные удаленные X-овые сеансы, которые будут также прозрачны для пользователя как и раньше. Сторонний - косвенный эффект использования ssh при запуске удаленных X-овых клиентских приложений это еще большая простота для пользователя.

При этом можно как и прежде использовать настройки в старых файлах .rhosts и /etc/hosts.equiv, ssh прекрасно их понимает. А если удаленная машина не поддерживает ssh, то сработает "обратный механизм" возврата к rsh, который включен в ssh.

2.3 От каких видов атак ssh защищает?

Ssh защищает от:
  • "IP spoofing'а"[ip-подмены], когда удаленный[атакующий] компьютер высылает свои пакеты симулируя якобы они пришли с другого компьютера, с которого разрешен доступ. Ssh защищает от подмены даже в локальной сети, когда кто-то например, решил подменить ваш роутер наружу "собой".
  • "IP source routing"[ip исходный маршрутизатор], когда компьютер может симулировать что IP-пакеты приходят от другого, разрешенного компьютера.
  • "DNS spoofing", когда атакующий фальсифицирует записи "name server'а"
  • Прослушивания нешифрованных паролей и других данных промежуточными компьютерами.
  • Манипуляций над вашими данными людьми управляющими промежуточными компьютерами.
  • Атак основанных на прослушивании "X authentication data" и подлога соединения к X11 серверу.
Другими словами, ssh никогда не доверяет сети; какой-либо "противник" имеющий _определенный_ доступ к сети может лишь _насильно_ разорвать установленное ssh соединение, но никак не расшифровать его, похитить или "обыграть".

Все вышесказанное ВЕРНО лишь при использовании шифрования. Однако Ssh имеет опцию шифрования "none", которая необходима лишь для отладки и ни в коем случае не должна быть использована для обычной работы.

2.4 От каких видов атак ssh не защитит?

Ssh не поможет вам в случае нарушения безопасности вашей машины другими методами. Например, если хакер взломал вашу машину или получил привелигированный-root доступ ИЗНУТРИ, что позволит ему "извратить-перевернуть" и работу ssh тоже.

Если какой-либо недоброжелатель имеет доступ в вашу домашнюю директорию то безопасность так же под вопросом, одной из частых тому причин является, например экспортирование домашней директории по NFS.

2.5 Как он работает?

2.5.1 SSH версия 1.2.x.

Для более обширной информации, прочтите пожалуйста RFC и файл READMEREADME из дистрибутива SSH.

Все коммуникации шифруются с использованием метода IDEA или любым на выбор из следующих: three-key triple-DES, DES, Blowfish. Для обмена ключей шифрования используется RSA метод, данные обмена уничтожаются каждый час(ключи нигде не сохраняются).Каждая машина имеет свой RSA-ключ который используется для проверки достоверности машины при задействии метода "RSA host authentication". Шифрование используетс для предотвращения "IP-Spoofing"; проверка достоверности публичных ключей против "DNS и Routing Spoofing".

RSA-ключи используются для проверки достоверности компьютеров.

Эта статья также включает описание того как ssh работает:

Смотрите также секцию 3.7 Где можно получить помощь? содержащий различные ссылки на материалы в сети по SSH.

2.5.2 SSH версия 2.x (ssh2).

Предложенное RFC доступно в качестве "Internet Draft" с ftp://ftp.ietf.org/internet-drafts/draft-ietf-secsh-architecture-04.txt.

3. Где взять и как установить ssh.

3.1 Какая последняя версия ssh?

Последние оффициальные реализации на данный момент - 1.2.27(ssh1) и 2.0.13(ssh2).

В настоящий момент Ssh работает на Unix-based платформах. И успешно портирован на все "ведущие" Unix ситемы.

3.2 Могу ли я законно использовать ssh?

Реализацию ssh-1.2.27 для OS Unix можно свободно использовать в некоммерческих целях и нельзя продавать как отдельный продукт или часть большого продукта или проекта, иными словами нельзя использовать SSH для извлечения финансовой выгоды без приобретения сепциальной[отдельной] лицензии. Определение "коммерческое использование" в отношении ssh следует воспринимать как извлечение финансовойвыгоды из чего-либо, как например использование ssh для входа на компьютеры заказчика с целью их удаленного администрирования или например, использование в целях безопасного входа к партнерам, продавцам и тд и тп связанных прямо или косвенно коммерческими интересами.

В ходе переписки между "Data Fellows" и ведущим этого FAQ'а были заданы следующие вопросы и соответственно получены ответы:

===============================================================
Чтобы небыло претезий по переводу, оставлен оригинал:

S:  Steve Acheson, FAQ Maintainer
P: Petri Nyman, F-Secure SSH Product Manager for Data Fellows

S>Can a company use the 1.2.26 release of the SSH software freely for
S>internal support and administration without violating the license
S>agreement?
перевод
S>Может ли компания свободно использовать 1.2.26 реализацию SSH
S>в целях внутренней поддержки и администрирования не нарушая при этом
S>соглашения о лицензировании?

P>You can freely use it for internal support and administration of your own
P>equipment located in your premises.
перевод
P>Вы лично можете свободно использовать для внутренней поддержки и
P>администрирования вашего собственного оборудования находящегося
P>в вашей собственности.

S>Does connecting from one machine to another via SSH to
S>read email, do work, etc, violate this agreement?
перевод
S>Нарушает ли соглашение соединение с одной машины на другу по SSH
S>для чтения почты, выполнения работы и тд и тп?

P>No, unless you provide this ability to a third party or connect to a third
P>party's computer to provide a service.
перевод
P>Нет, в том случае если если вы для использования этих сервисов соединяетесь
P>с компьютерами _третьей_стороны_ или предоставляете сервис _третьей_стороне_.

S>Does connecting from a purchased PC client SSH software to a non-licensed
S>SSH server violate the agreement?
перевод
S>Нарушается ли соглашение если соединение установлено между клиентом
S>SSH имеющим лицензию и нелицензированным SSH сервером?

P>No.
перевод
P>Нет.

S>Does connecting to a remote site, that is not company owned, but company
S>administered, via SSH to do administrative work violate the agreement?
перевод
S>Нарушается ли соглашение если устанавливается соединение с компьютером не принадлежащим
S>компании, но ею администрируется, с целью проведения административных работ.

P>Yes. You need a commercial license for that.
перевод
P>Да. Для таких целей необходимо приобрести лицензию.

===============================================================

Unix версии ssh 2.0.13 могут быть использованы ТОЛЬКО в случае персонального использования или в целях обучения (см. license agreement). В случае коммерческого использования необходимо купить лицензию у Data Fellows.

Более ранние версии ssh имеют менее ограниченную лицензию; читайте об этом в файле COPYING сопровождающем дистрибутив каждой версии.

В некоторых странах, особенно Франции, России, Ираке и Пакистане, вовсе запрещено использование шифрования без особого на то разрешения.

Если находитесь в USA, то должны осозновать что любая попытка экспортировать ssh за пределы штатов будет рассматриваться как уголовно-наказуемая, сюда же относится и попытка размещения на ftp серверах находящихся за пределами USA, не взирая на то что сам SSH был написан за пределами USA и с использованием лишь свободно доступных материалов. Для получения более полной информации обращайтесь в ведомство "Defence Trade Controls".

Алгоритмы RSA и IDEA, которые используются в ssh, имею самостоятельные патентные права в разных странах, включая US. Вместо них можно воспользоваться библиотекой RSAREF, однако законность использования в некомерческих целях ssh в US в таком случае, может восприниматься двояко. Вам может понадобиться приобретение лицензии для коммерческого использования IDEA; однако ssh будет прекрасно работать будучи сконфигурирован и без него.

Для более подробной информации читайте файл COPYING из дистрибутива ssh.

3.3 Что можно сказать о коммерческом использовании ssh?

Некомерческое использование версии ssh 1.2.x было совершенно свободно в Unix среде и почти определенно останется таковым в будущем.

Использование версии ssh 2.x было существенно ограничено.

Tatu Ylonen, автор ssh, организовал компанию "SSH Communications Security Oy" которая обеспечивает коммерческую поддержку и лицензирование ssh. Эта компания работает совместно с "Data Fellows", которая занимается продажей ssh лицензий. Более полную информацию можно найти на http://www.datafellows.com/ и http://www.ssh.fi/.

3.4 Где можно взять ssh?

Центральный адрес распространения ssh ftp://ftp.cs.hut.fi/pub/ssh/.

Официальная версия имеет PGP-подпись с ключом ID 

DCB9AE01 1995/04/24 Ssh distribution key <ylo@cs.hut.fi>
Key fingerprint =  C8 90 C8 5A 08 F0 F5 FD  61 AF E6 FF CF D4 29 D9
Ssh также доступен через анонимный доступ по ftp со следующих адресов:
Australia:
ftp://coombs.anu.edu.au/pub/security/ssh
Chile:
ftp://ftp.inf.utfsm.cl/pub/security/ssh
Finland:
ftp://ftp.funet.fi/pub/unix/security/login/ssh
Germany:
ftp://ftp.cert.dfn.de/pub/tools/net/ssh
Hungary:
ftp://ftp.kfki.hu/pub/packages/security/ssh
Ireland:
ftp://odyssey.ucc.ie/pub/ssh
Poland:
ftp://ftp.agh.edu.pl/pub/security/ssh
Portugal:
ftp://ftp.ci.uminho.pt/pub/security/ssh
Russia:
ftp://ftp.kiae.su/unix/crypto
Slovenia:
ftp://ftp.arnes.si/security/ssh
United Kingdom:
ftp://ftp.exweb.com/pub/security/ssh
United States:
ftp://ftp.net.ohio-state.edu/pub/security/ssh
United States:
ftp://ftp.gw.com/pub/unix/ssh
На некоторых из зеркал _центрального_архива_, могут отсутствовать некоторые из snapshots[экспериментальные] версий ssh.

3.5 Как установить ssh?

Возьмите файл дистрибутива с ближайшего к вам зеркала, затем распакуйте его 
gzip -c -d ssh-1.2.27.tar.gz | tar xvf -
после чего перейдите в директорию ssh-1.2.27, прочитайте файл INSTALL, и следуя рекомендациям установите SSH.

3.6 Может ли установить ssh "непривелигированный" пользователь в OS Unix?

Если вы запустили сервер - sshd, как пользователь отличный от root, вы получите доступ - login только для того пользователя от которого был запущен сам sshd.

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

Вы можете запустить sshd из под своего account'а применив опцию -p для использования ssh на непривелигерованном порту (>1024), чтобы иметь возможность соединения с других машин по заданному порту ssh -p. Данный метод, как было замечено выше, позволяет производить соединения только под тем пользователем, под которым был запущен собственно sshd, и как правило демон не перестартует после перезагрузки машины.

Вы сами должны решать какой метод использовать в зависимости от ситуации.

3.7 Где можно получить помощь?

Для начала полностью прочитайте этот документ :-) и то что доступно на основной странице ssh http://www.ssh.fi/sshprotocols2/.

Для пользователей очнь полезно будет введение на http://www.tac.nyc.ny.us/~kim/ssh/.

Автор этого опуса тоже имеет несколько статей об SSH опубликованных в Sunworld журнале.

Введение в SSH, достижения, и тд и тп:

Конфигурирование, установка, и тд и тп:


Если эти ресурсы не помогут, вы можете послать вопрос в группу новостей Usenet comp.security.ssh или отправить свой вопрос в список рассылки пользователей ssh ssh@clinet.fi Для подписки отошлите письмо на majordomo@clinet.fi c

subscribe ssh

в теле письма.

Перед подпиской вы можете поискать ответ на ваш вопрос в архиве на

3.8 Существуют ли версии ssh для Non-Unix операционных систем?

последнее обновление: 1999-07-11

ниже список ssh клиентов и серверов.

  1. каждая строка содержит ссылку на клиента.
  2. список упорядочен по os.
  3. основные распространители не вкючены.
  4. спасибо всем кто прислал дополнения/изменения.

win32

cygnus win32 ( http://sourceware.cygnus.com/cygwin/ )

beos

wince

palm pilot

java

os2

macintosh

openvms

Порт для OS/2 можно взять с ftp://ftp.cs.hut.fi/pub/ssh/os2//">ftp://ftp.cs.hut.fi/pub/ssh/os2/.

Существует список рассылки для версии OS/2. Для подписки отправьте письмо на majordomo@clinet.fi с 

subscribe ssh-os2
в теле сообщения.  

3.9 Что можно сказать об администрировании ssh?

Основной проблемой администрирования ssh является управление "host keys"[ключами машин]. Чтобы разрешить клиенту доступ на удаленную машину с использованием проверки на подлинность через "RSA host key", серверу необходимо знать публичные ключи клиентов.

Их можно собирать автоматически, каждую ночь, используя имеющийся в дистрибутиве скрипт написанный на Perl'е make-ssh-known-hosts.pl или с помощью быстрой утилиты ssh-keyscan, доступной с ftp://cag.lcs.mit.edu/pub/dm/ или ftp://ftp.cs.hut.fi/ssh/contrib/.

Thomas Konig написал скрипт разбирающий и анализирующий вывод вышеуказанных утилит, проверяя наличие новых ключей, сообщая о тех host'ах которые сменили свои ключи (дабы предотвратить атаки) и в завершение создавая новый файл ключей. Этот скрипт доступен с http://www.uni-karlsruhe.de/~ig25/ssh-faq/comp-host-list.

На основе этих утилит вы можете написать свои для постоянной проверки public keys. Когда на новых машинах заработает ssh или произойдет изменение ключей на уже работающих, возможно вы захотите высылать уведомления или связаться с хозяевами этих машин напрямую чтобы предупредить возможные атаки хакеров.

3.10 Что известно о других версиях UnixSSH Servers?

Существует список рассылки посвященный дискуссии развития GPL'd SSH сервера и клиента.

http://www.net.lut.ac.uk/psst/

Существенное что из этого родилось это lsh, полностью соответствующий IETF (закрытый на сколько это возможно) sec-sh (SSHv2) клиент сервер.

Попробуйте найти lsh здесь:  http://www.lysator.liu.se/~nisse/archive/

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

5. Проблемы.

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

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

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

Нет, этого не может быть. Используйте вместо этого "ssh -f otherhost xclient", или "ssh -n otherhost xclient &" для совместимости с rsh.

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

Что касается Solaris 2.4, это ошибки ядра. Получите и установите patch 101945-37 для предотвращения этой ошибки в дальнейшем. Заметьте, что в более ранних версиях 101945-36, кажется предотвращает эту ошибку.

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

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

Это проблемы кода разделяемой библиотеки Solaris, точнее отдельных функций nameserver'а.

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

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

Для решения этой проблемы установите hostname в полной FQDN форме: hostname=name.domain. В некоторых дистрибутивах Linux в качестве hostname устанавливается только локальное имя машины.

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

Проверьте возвращает ли gethostbyname() список возможных ip-address или только один адрес.(такое возможно например в случае, NIS/NIS+, когда в конфигурации системы задан поиск где первым стоит просмотр /etc/hosts в котором указан лишь один из возможных ip-addresses).

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

Это ошибка в AIX 3.2.5, о ней сообщено в APAR IX38941, и выпущены исправления U435001, U427862, U426915, и несколько других. Для детального ознакомления свяжитесь с вашим представительством IBM.

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

В случае Alpha OSF/1 1.3.2, это ошибка родного компилятора при использовании с максимальной оптимизацией.

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

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

Это ошибка gcc gcc 2.7.0, производящего неверный код при компиляции без оптимизации. Используйте "-O" или "-O -g" опции для gcc или замените старый gcc на gcc 2.7.2 или более свежий.

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

Это некорректно сконфигурированная OS Linux; сделайте следующее "cd /usr/lib; ln -s libc.sa libg.sa" из под "root" экаунта чтобы исправить.

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

Это обнаруженная ошибка в HP-UX 9 xauth, SR 5003209619. Патч PHSS_5568 должен решить эту проблему.

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.

Для плохо понимающих, в последнем варианте учитывается что путь в бинарнике имеет конкретную длинну, те чревато заменять например /usr/bin/rlogin на /usr/local/old/rlogin.

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

"Очень умный rxvt" закрывает все файловые дескрипторы при запуске, включая и тот который использовал ssh-agent. ;-) Используйте xterm вместо rxvt или поищите в архиве http://www.cs.hut.fi/ssh/ssh-archive/ ссылку на правку в rxvt сделанную Timo Rinne.

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

Это происходит по той причине что программа "xauth" НЕ БЫЛА найдена во время конфигурации. Поправьте path, переконфигурируйте и перекомпилируйте ssh.

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

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

Это известные скоростные проблемы в ssh протоколе до версии 1.2.13.

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

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

Либо с удаленной стороны запрещено перенаправление X11 (ForwardX11 No в config файле) или при сборке не были найдены X11 библиотеки или команда xauth.

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

Это очень замечательно что вы следите за telnet, rlogin или X session на той машине где вы запустили ssh. Однако вы уверены что это действительно пакеты ssh? (к примеру проверьте номера их портов; sshd слушает 22-ой порт по умолчанию).

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

Это ограничения библиотеки RSAREF. Вы должны установить "host key" не больше чем 896, максимально возможное значение приветствуется.

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

В некоторых операционных системах имеются ошибки в подпрограмме ассемблера gmp. Попробуйте 
make distclean
configure --disable-asm
для компиляции.

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

Перед запуском "configure" установите переменную среды CPP в "cc -E -Xs".

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

Эта проблема была обнаружена разными людьми на разных платформах SunOS 4, Solaris 2, Linux, and HP-UX 9 and 10, с версиями ssh 1.2.16 и 1.2.17. Она происходит с scp когда передается больщое количество данных через ssh stdin или при перенаправлении через X большого количества графических данных (например MPEG movie).

Попробуйте применить следующие правки к 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(&amp;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"-а!

Когда клиент соединяется, sshd фокует[запускает особым образом] дочерний процесс для управления протоколом, запущенный _дочерний_ процесс в свою очередь запускает еще одного потомка для выполнения пользовательского shell или команд. Проблема в том что вызов setuid() корректно запускает только второго потомка, а первый вынужден оставаться запущенным как root.

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

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

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

James Barlow  управляет хранилищем правок для 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 возрастает просто фантастически! ]

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

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

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

Спецификация протоколов ssh свободно доступна. Нет никаких ограничений если кто-то захочет реализовать новый продукт совместимый с ssh и распространяемый на иных условиях.

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

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

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

Существуют и другие надежные средства шифрации и проверки подлинности удостоверения доступа извне. Возможно у вас появиться интерес попробовать их тоже.

6.5 Заслуги.

Безусловно, основная заслуга принадлежит Tatu Ylonen и как автору и в том что он сделал этот продукт публично доступным! Автор благодарит его как за предоставленную документацию, так и за коррекцию этого документа.

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

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

Новые публикации
Linux Advanced Routing & Traffic Control HOWTO
Установка и настройка OpenVPN в CentOS
Установка Livestreet с нуля (Debian): nginx + mysql + php-fpm + apc + ...
Торрент клиенты под Linux
Допиливаем до ума FreeBSD или первые шаги после установки
Убийственная коллекция CSS Reset - стилей (сброса стилей браузеров, стоящих по умолчанию)
Популярные статьи
Установка и настройка эмулятора Windows - wine
ALT Linux 2.3 Compact
OpenOffice Руководство пользователя
The Linux Gamers' HOWTO
Параметры конфигурации Apache
Иерархия каталогов и файловых систем в Linux
Осваиваем Nagios
Использование GNOME
Руководство по настройке пакета веб-почты SquirrelMail
Использование KDE
Конфигурация Samba сервера
Отладка с помощью GDB
Наш баннер
Вы можете установить наш баннер на своем сайте или блоге, скопировав этот код:
RSS новости