/* Задумывался как быстрый тур, что получилось ... :)
черновой текст без правок и переработок, что само собой необходимо... кроме того, пока действительно сюда не включен быстрый тур, ибо еще не готов. Тур содержит конкретные советы по установке, настройке и использованию... */

БЫСТРЫЙ ТУР ПО УСТАНОВКЕ И НАСТРОЙКЕ SSH.

Об авторе

Данный программный продукт был оригинально разработан - Tatu Ylonen<ylo@cs.hut.fi>
в Финляндии. В настоящее время он сопровождается:

/*
(Вероятно, в данном переводе существует достаточное количество неоднозначных по восприятию мест, увы, я не знаю как это будет по-русски и возможно ли это перевести по смыслу как есть..? Я старался как можно проще и читабельнее донести смысл на родном языке. Уверен, что специалисты обратятся к оригиналу, а простым пользователям хочется пожелать не пытаться представлять многие из описанных вещей физически без наличия определенных знаний, ибо некоторые понятия являются как бы виртуальными, да простят меня Кирилл&Мефодий за произведенное мной над Русским языком.)
*/
 

Краткий обзор SSH (Secure Shell)

Основываясь на своем жизненном опыте, позволю некоторое лирическое отступление...
В отличие от сказок, которые мы в детстве слышали от мам, пап, бабушек, дедушек и других родных или близких нам людей, в жизни "ЗЛО" много чаще "побеждает" "ДОБРО", кроме этого, нам порой кажется, что именно "зла" вокруг больше чем добра, но слава богу это не так, просто добрые дела нами чаще воспринимается как обычное явление и потому не оставляет в нашей памяти такого следа как "зло", а жаль...
Не вдаваясь в теорию "единства и борьбы противоположностей", полагаю, что зло-добро, белое-черное, плохие-хорошие, создатели-разрушители это как одно целое, связанное между собой невидимыми нитями и мы постоянно выбираем что есть что и какую позицию нам стоит занять, чтобы решить как действовать... Не могу причислить себя к ярым противникам "хаккеров", но уверен, что от той доброй половины их, а может быть и больше, которая не умеет даже правильно использовать плоды чужих трудов просто необходимо защищаться.

Технологии сети Internet предоставляют доступ к невероятно огромному количеству различных ресурсов всем желающим, независимо от того кто они: добрые или злые, плохие или хорошие...
Увы, но любой желающий может найти специализированные программы или пакет программ, позволяющий установить его на компьютер, включенный в локальную сеть и подслушивать чужие пароли проходящие в незащищенных сетевых средах, а затем использовать их с недобрым умыслом или в корыстных целях...
В альтернативу этому создаются другие программы, комплексы програмных средств, позволяющие шифровать свои сеансы работы, ставить различные заграждения или преграды на пути "хаккеров", один из таких пакетов - SSH (Secure Shell).

SSH (Secure Shell) - это программа, позволяющая входить на другие удаленные компьютеры в сети, выполнять на них команды-программы или переносить данные с одной машины на другую. SSH строго обеспечивает секретность и достоверность передаваемых данных по незащищенным компьютерным каналам и представляет собой альтернативную замену таким известным и привычным средствам как:
"rlogin", "rsh", "rcp", и "rdist".

Возможности:

- Улучшена секретность. Все соединения прозрачно и автоматически шифруются. Для обмена ключей используется метод RSA и традиционный шифр для кодирования сессии (сеанса работы). Следует отметить, что шифрация начинает свою работу до момента аутентикации(проверки подлинности), где ни пароль, ни какие другие данные не передаются по сети в чистом виде.

- Обеспечение безопасности сессий X11. Автоматическая установка DISPLAY на серверной машине и перенаправление любых X11-соединений через безопасные - шифруемые каналы. Автоматически создается поддельная информация Xauthority и отправляется удаленной машине; локальный клиент автоматически проверяет входящие соединения X11 и заменяет подставные данные авторизации на реальные (никогда не передавая удаленной машине реальных данных).

- произвольные TCP/IP порты могут быть перенаправлены через шифруемые каналы в обоих направлениях.

- нет необходимости в переобучении обычных пользователей; все происходит автоматически и старые .rhosts будут работать с жесткой проверкой, если администратор установил на сервере файл ключей хостов - "host key file"

- Никакого доверия сети. Минимальное доверие удаленной стороне, DNS. RSA authentication не доверяет ничему, кроме личных ключей шифровки (privat key).

- Клиент RSA проверяет серверную часть в начале каждого соединения, чтобы избежать различных сетевых атак и узких мест в сети, в свою очередь сервер RSA проверяет клиента перед восприятием данных из .rhosts и /etc/hosts.equiv.

- Распространение "host authentication" ключей может быть выполнено администратором, автоматически, когда происходит первое соединение к машине (ключи, полученые во время первого соединения, будут сохранены и использованы для аутентикации в будущем) или вручную каждым пользователем в своих нуждах. В дальнейшем будут использоваться вместе "host keys", полученные адинистратором и пользователем и дополнять одни других. "Host keys" могут быть получены централизованно или автоматически при установке и настройке SSH и обычно имеют длину 1024 bits.

- Любой пользователь может создать любое количество ключей RSA аутентикации для собственных нужд. Каждый пользователь имеет файл со спиком публичных RSA ключей(public key), для которых испытаны соответствующие личные ключи (private key) и принятые как аутентикационные. Пользовательские ключи аутентикации обычно 1024 bits.

- Программа сервера имеет свой сервер RSA-ключ, который автоматически создается каждый час (server key). Этот ключ никогда не сохраняется в файле. Обмен сессионными ключами кодируется с использованием "server key" и "server host key". Наличие отдельного "server key" делает невозможным дешифрацию перехватываемого сеанса позже, ибо через час "server key" снова изменится. Временной интервал регенерации "server key" может быть изменен с "1-часа" на иной интервал. Обычная длина "server key" - 768 bits.

- Агент аутентикации, запущенный на локальной станции пользователя, может быть использован для хранения "RSA authentication keys". Ssh автоматически перенаправляет данные на вход "authentication agent" поверх любого соединения и поэтому нет необходимости сохранять "RSA authentication keys" на других машинах сети, кроме локальной-пользовательской. Протоколы аутентикации никогда не обнаруживают ключи, они лишь используются для проверки того, что пользовательский агент имеет определенный ключ.

- Программный продукт может быть установлен даже без "root" привилегий, с определенными функциональными ограничениями, естественно.

- Клиентская часть может быть сконфигурена как с системной стороны, так и с пользовательской, большинство возможностей клиентской части может быть перенастроено под соответствующие нужды.

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

- При использовании сжатия передаваемых данных с помощью gzip(включая перенаправление данных X11 и TCP/IP), вероятно существенное повышение скорости на малоскоростных соединениях.

- Полная замена rlogin, rsh и rcp.
 
 

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

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

Более того, существует возможность "похищения" сетевого соединения, т.е. подразумевается, что вторжение может произойти посреди соединения с изменением проходящих данных в обоих направлениях. Например, это может быть использовано для выполнения "новых" команд в сеансах идентифицированных паролем лишь одинажды.
Следовательно, не существует полноценного метода аутентикации пользователя, при котором сохраняется безопасность работы и несанкционированный доступ к его данным.
Более того, routing spoofing (подложная/ложная/подставная(подстава) маршрутизация) может использоваться для "переноса" почти любого Internet-соединения в место, где данное соединение может быть успешно атаковано.

Методы шифрации-дешифрации и целостной защиты данных просто необходимы для защиты компьютерных сетей и систем. Поэтому SSH использует сложные криптографические алгоритмы для достижения этих целей.

Известно, что один из важных критериев программного продукта - простота в использовании, SSH попытались сделать проще в использовании, чем те ненадежные программные средства, которые он призван заменить.

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

SSH может быть установлен почти на всех Unix платформах и коммерческие версии существуют также под Windows (3.1, 95, NT) и Macintosh.
 
 

Обзор пакета SSH

Коротко об использовании

Основным инструментом пользователя является программа Ssh, которая запускается двумя способами:
 

   ssh host                 (a)
или
   ssh host command         (b)

Способ (a) запускает сеанс, т.е. интерпретатор, на удаленной машине после успешной аутентикации.
Способ (b) производит выполнение команды на удаленной машине, опять же при успешной аутентикации.

При запуске, ssh-клиент связывается с sshd-сервером удаленной машины, проверяет с тем ли он связался с кем хотел, обменивается ключами шифрации, выполняет аутентикацию из .rhosts/.slogin, /etc/hosts.equiv, RSA или правильность введенного пароля. После успешной аутентикации, сервер выделяет псевдо-терминальное устройство ввода-вывода и запускает интерактивный shell или программу пользователя.

Для успешной работы клиент передает удаленной стороне значение переменной среды TERM и все режимы терминала, если же с клиентской стороны установлена переменная среды DISPLAY (X11), сервер создаст псевдо X-server и соответственно установит переменную DISPLAY. Затем любые соединения к псевдо X-серверу будут перенаправлены через секретные/шифрованные каналы и будут отработаны настоящим X-сервером с клиентской стороны. Таким образом, пользователю нет необходимости определять переменную DISPLAY на удаленной машине или запускать x-приложения с переменной "-display". Данный режим может быть отключен в конфигурационном файле или указанием опции "-x" при запуске клиента.

Любые IP порты могут быть перенаправлены через секретные каналы, программа создает порт на одной стороне и, какое бы соединение не пыталось открыть данный порт, оно пройдет через секретный канал, а соединение с другой стороны на данный порт может быть установлено парой host:port, что может настроено в конфигурационном файле, пользователь может потребовать перенаправить любой IP порт, за исключением привилегированных, это прерогатива администратора.

Для чего необходимо перенаправлять соединения X11, как считает автор, здесь просматриваются две цели: избавиться от переменной DISPLAY и обеспечить секретность передачи X11 соединений; самым простым способ достигнуть этого - вероятно перенапраление соединений через security channel, а не модификация всего X Server'а, библиотек и приложений. Как в общем случае происходит перенаправление X11 соединений:
клиент извлекает данные Xauthority(перевода не будет по понятным причинам) для сервера, затем создает произвольные данные авторизации и посылает их серверу, который в свою очередь выделяет номер X11-display и запоминает подложные данные Xauthority для этого X11-display. Любые открываемые X11 соединения, сервер направляет через security channel клиенту, который разбирает первый пакет протокола X11, выделяя реальные данные аутентикации для подложных данных и при совпадении переправляет соединение реальному серверу X11.

Если дисплей не имеет Xauthority данных, сервер создаст unix domain socket (без перевода по понятным причинам) в /tmp/.X11-unix и будет использовать socket в качестве display. В данном случае не будет переправлятся аутентикационная информация, но X11 connections будут направляться по secure channel.
Однако рекомендуется использовать Xauthority, иначе X11-display будет незащищен. Заметим, что при использовании XDM автоматически генерируются данные авторизации.
Следовательно, не стоит пользователям, работающим в X11 среде, использовать "xin" или "xstart" и другие подобные скрипты, устанавливающие переменную DISPLAY для запуска X сессии на удаленной машине, ибо в таких случаях соединение не пойдет по секретным каналам.
Рекомендуемый способ запуска SHELL на удаленной машине:

   xterm -e ssh host &

и рекомендуемый способ выполнения X11 приложения на удаленной машине:

   ssh -n host emacs &,

если надо войти с авторизацией password или passphrase(сгенерированного пользователем при запуске ssh-keygen) для удаленной машины:

   ssh -f host emacs

Полное описание комманд и опций читайте в руководстве: ssh(1), sshd(8), scp(1), ssh-keygen(1), ssh-agent(1), ssh-add(1), make-ssh-known-hosts(1).

RSA AUTHENTICATION

основана на шифровании public key (общих ключей). Идея состоит в том, что существуют/создаются два шифр-ключа, один для шифрации, другой для дешифрации. И невозможно извлечь ключ дешифрации из шифра, если за временную шкалу взять человеческую жизнь. Encryption key(шифр ключ) принято называть public key (общий или публичный ключ), потому что он может быть выдан любому и не является секретным. Decryption key(ключ дешифрации) является секретным и принято называть private key(приватным или личным ключом).

RSA аутентикация основана, как упоминалось выше, на невозможности извлечения личного ключа из публичного. Public key хранится на сервере у пользователя в $HOME/.ssh/authorized_keys файле. Private key хранится только на локальной машине пользователя, лаптопе, ноутбуке или другом секретном носителе. И когда пользователь пытается войти в сеанс на удаленной машине, клиент сообщает серверу public key, который он хочет использовать для аутентикации. Сервер определяет допустимый это ключ и если да, генерирует 256 bit произвольный номер, шифрует его публичным ключом и значение отправляет клиенту. Клиент дешифрует это значение своим личным ключом, вычисляет 128-ми bit MD5 checksun от полученных при дешифрации данных и отправляет назад серверу (только checksum'а посылается назад для предотвращения атаки против RSA). Сервер вычисляет контрольную сумму от правильного значения и сравнивает с полученной обратно, и проверка принимается если суммы совпали.

RSA private key может быть защищен в свою очередь passphrase(парольной фразой) Passphrase может быть любой строкой, она обрабатывается MD5 для создания ключа шифрования для 3DES, который используется для шифрации файла личного ключа.

Все описанное, конечно, зависит и от самого алгоритма RSA, который широко стал известен с 1978 и нет такого эффективного и полноценного метода, который бы позволял его дешифрацию. Пока нет еще эффективного метода дешифрации ключа более чем 512 bits, но, тем не менее, производительность и скорость компьютерных систем постоянно растет и ключ длинной 512 bit уже не удовлетворяет принципам надежности. В настоящем и ближайшем будущем ключи 768 и 1024 bits должны удовлетворить требованиям надежности секретности данных.

RHOSTS AUTHENTICATION

Традиционный механизм аутентикации .rhosts и hosts.equiv работает по прозрачным каналам IP, соответственно может быть просто подслушан или подвержен dns или routing spoofing атакам, дополнительно этот метод основывался на целосности клиентской машины. Данные недостатки известны и терпели, и использовали :)
довольно долгое время и по сей момент. :)

Ssh улучшил этот метод и в свою очередь поддерживает и его, потому что пользователи традиционно привыкли к нему (rsh и rlogin), но в дополнение к этому методу Ssh требует, чтобы клиент использовал и RSA аутентикацию.

Серевер обычно имеет список host keys(ключей машин), хранящийся в /etc/ssh_known_host и дополнительно каждый пользователь имеет или может иметь свой список в $HOME/.ssh/known_hosts. Ssh использует dns-server для получения канонического имени клиента, по которому просматривает свою базу на предмет наличия в ней public key этой машины-клиента и затем требует, чтобы клиент испытал этот ключ своим private key. Это предотвращает от IP и routing spoofing атак до тех пор, пока не будет "скомпрометирован" private host key клиента, но остается проблема DNS spoofing и вопрос целостности-надежности клиентской машины на предмет реальный пользователь или хаккер работает под чужим именем.
Поддержку использования традиционных методов .rhosts и /etc/hosts.equiv аутентикации можно включить при компиляции SSH опцией --with-rhosts во время конфигурации, потому как это не рекомендуется и не делается при конфигурации компиляции по-умолчанию. Рекомендуется не использовать rlogin и rsh в целях поддержки секретности и более того закоментировать их запуск в /etc/p;netd.conf.

СПИСКИ РАССЫЛКИ И ИНЫЕ ИСТОЧНИКИ ИНФОРМАЦИИ SSH

Существует список рассылки для SSH - ssh@clinet.fi. Тем, кто хочет на него подписаться, необходимо послать письмо по адресу: majordomo@clinet.fi с одной строкой в теле письма "subscribe ssh".

host> echo subscribe ssh\\n. | mail majordomo@clinet.fi

Можете воспользоваться выше указанной строкой для подписки на maillist, но! прежде посмотрите позволяет ваша команда "echo" использвать C-like style print.
В большинсте Unix systems /usr/bin/echo or /bin/echo отрабатывают так же как и gnu-echo, те как указанная выше строка.

На домашней WWW странице вы найдете полную и исчерпывающую информацию о текущей релизации SSH, списки рассылки и массу сопутствующей информации.

SSH WWW Home page -> http://www.cs.hut.fi/ssh

Информацию о SSH для Windows, Macintosh, и коммерческой лицензии можете найти на странице -> http://www.datafellows.com/f-secure или отправив письмо по адресу: f-secure-ssh-sales@datafellows.com .

Замеченные ошибки или замечания следует отправлять по адресу:

Содержание:

1. Справочные вопросы

1.1 Где можно найти этот документ?

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

2. Основы Ssh

2.1 Что такое ssh?

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

2.3 От чего ssh способен защитить?

2.4 От чего ssh не может защитить?

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

3. Как и где получить и установить ssh?

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

3.2 Можно ли легально использовать ssh?

3.3 Использование коммерческих версий ssh?

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

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

3.6 Можно ли установить ssh в системе Unix будучи непривилегированным пользователем (non-root)?

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

3.8 Существуют ли версии ssh для систем отличных от Unix?

3.9 Администрирование ssh?

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

4.1 Можно ли запускать backup поверх ssh?

4.2 Нужно ли выключать криптование в некоторых целях?

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

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

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

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

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

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

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

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

5. Проблемы

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

5.2 Ssh прекращает работу с сообщением "Resource temporarily unavailable" для Solaris

5.3 Sshd не работает под Solaris 2.5!

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

5.5 Ssh работает неверно с multi-homed hosts!

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

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

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

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

5.10 X авторизация иногда отрабатывает неверно

5.11 Ssh требует от меня пароль несмотря на .rhosts!

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

5.13 ssh-agent не работает с rxvt!

5.14 X авторизация всегда неверная

5.15 ssh прекращает работать когда форвардирует multiple TCP connections

5.16 Что означает Warning: remote host denied X11 forwarding mean?

5.17 I still see cleartext packages on the net when I run ssh!

5.18 Проблемы с RSAREF, что-то типа too many bits!

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

5.20 Компиляция обрывается под Solaris 2.5!

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

5.22 Соединения ssh форвардируются как "root"!

 
  1. СПРАВОЧНЫЕ ВОПРОСЫ.

1.1 Где найти этот документ?

Единственная и пока последняя версия этого документа доступна по http:... Оригинальный SSH-FAQ можно взять с http://www.uni-karlsruhe.de/~ig25/ssh-faq/ Оригинал регулярно публикуется в USENET конференциях:

   comp.security.misc
   comp.security.unix
   sci.crypt
   comp.answers
   sci.answers
   news.answers
 

Оригинал (с PGP-sign) доступен:

ftp://rtfm.mit.edu/pub/usenet/news.answers/computer-security/ssh-faq
http://www.uni-karlsruhe.de/~ig25/ssh-faq/ssh-faq.faq

Оригинал SGML -> http://www.uni-karlsruhe.de/~ig25/ssh-faq/ssh-faq.sgml
Постскрипт версия -> http://www.uni-karlsruhe.de/~ig25/ssh-faq/ssh-faq.ps.gz.

Кто имеет медленный линк в Германию, может воспользоваться:

http://aleph1.mit.edu/ssh-faq/

Домашняя страница SSH -> http://www.cs.hut.fi/ssh/.

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

По оригиналу FAQ свои замечания и предложения отсылайте автору:

Thomas.Koenig@ciw.uni-karlsruhe.de

 
  2. ОСНОВЫ SSH

2.1 Что такое ssh?

Выдержки из README к SSH:

SSH (Secure Shell) - это программа, позволяющая входить на другие удаленные компьютеры в сети, выполнять на них команды-программы или переносить данные с одной машины на другую. SSH строго обеспечивает секретность и достоверность передаваемых данных по незащищенным компьютерным каналам и представляет собой альтернативную замену таким известным и привычным средствам как: "rlogin", "rsh", "rcp", и "rdist".

Дополнительно ssh обеспечивает безопасность X11 соединений и секретное перенаправление любых TCP соединений.

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

Традиционные BSD 'r' - команды (rsh, rlogin, rcp) уязвимы и могут быть подвержены различному роду атак. Тот кто имеет root доступ к компьютеру в сети или физический доступ к сетевому оборудованию может различными методами получить неавторизованный доступ к чужим системам.

X Window System также имеет ряд уязвимых мест, использование ssh позволяет уменьшить риск и, кроме того, его использование гораздо удобнее для пользователя при запуске X11 приложений.

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

2.3 От чего ssh способен защитить?

Ssh защищает против:
 

• IP spoofing, когда чужая машина посылает свои пакеты, маскируя их под те, которым разрешено работать, ssh может защитить от ложных пакетов не только извне, но и внутри локальной сети.

• IP source routing, когда машина изменяет проходящие через нее пакеты.

• DNS spoofing, когда атакующий подделывает-изменяет записи name-server'а

• Перехват чистых(некриптованых) паролей и других данных при межмашинном обмене

• Атаки, основанные на подслушивании данных аутентикации X11, и создание с использованием чужой аутентикации ложных соединений к серверу X11

Другими словами, ssh НИКОГДА НЕ ДОВЕРЯЕТ СЕТИ; кто-либо сможет оборвать соединение SSH, но не сможет расшифровать или подменить сетевой траффик или похитить соединение.

2.4 От чего ssh не может защитить?

Ssh не сможет вам помочь, если ваша машина была взломана каким-либо иным путем и взломщик, однажды получивший root-права на вашей машине может, ко всему прочему, разрушить ваш ssh.

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

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

Для более полной информации необходимо прочитать файл README из дистрибутива SSH и соответствующие RFC документы, которые доступны в Internet:

RFC -> ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-ssh-00.txt.

Все коммуникации шифруются используя идею или методы одного из следующих типов шифра: three-key triple-DES, DES, RC4-128, TSS, Blowfish. Обмен ключами происходит методом RSA и данные этих ключах изменяются каждый час, при этом нигде не сохраняются, кроме как в оперативной памяти. Каждая машина имеет тоже RSA ключи, используемые для аутентикации машин, что предотвращает различные сетевые атаки.
3. КАК И ГДЕ ПОЛУЧИТЬ И УСТАНОВИТЬ SSH?

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

Последняя официальная реализация ssh - 1.2.25.

Ssh работает под различными версиями Unix и плюс OS/2. Портирование ssh было успешно осуществлено под все "mainstream" UNIX системы. Существует версии и для MS-Windows, которые являются коммерческим продуктом, однако Cedomir Igaly написал free beta версию, которая может быть получена:

http://public.srce.hr/~cigaly/ssh

или с зеркала

ftp://hotline.pvt.net/pub/win_utils/winsock/ssh/.

Коммерческая версия реализована автором ssh Tatu Yloenen и может быть куплена у Datafellows, там же можно приобрести версию для Mac.

3.2 Можно ли легально использовать ssh?

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

Версия ssh, разработанная Tatu Yloenen's для MS-Windows, является коммерческим продуктом, который требует лицензирования.

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

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

3.3 Использование коммерческих версий ssh?

Ssh свободно доступен практически для все Unix платформ и почти определенно можно сказать, что так будет и впредь.

Tatu Yloenen, автор ssh организовал компанию SSH Communications Security Oy, которая должна обеспечить коммерческую поддержку и лицензионное использование. Эта компания работает совместно с торговой - Data Fellows, которая является торговым представителем по приобретению лицензии. Дополнительная информация может быть найдена:

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

Последняя версия доступна с ftp://ftp.cs.hut.fi/pub/ssh/snapshots/. Ssh также доступен с анонимных ftp серверов:
 

Australia:

ftp://coombs.anu.edu.au/pub/security/tools

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.

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

Получить дистрибутив и затем распаковать его

gzip -c -d ssh-1.2.25.tar.gz | tar xvf -

или использую gnu-tar

gtar zxvf ssh-1.2.25.tar.gz

после чего перейти в директорию ssh-1.2.25, прочитать файл INSTALL, и следовать прочитанной инструкции в дальнейшем.

Общие действия таковы:

- внимательно прочитайте файлы README и INSTALL;
- определите в соответствие с требованиями ваших сетевых администроторов как вам лучше собирать и устанавливать SSH, при этом не забывайте о ваших персональных потребностях и особенностях работы;
- не поленитесь лишний раз посмотреть доступные в конфигурации опции:

configure --help

- снова проверьте, какие методы шифрации используются в конфигурировании по умолчанию и чтобы вы хотели включить: "--with-METHOD" выключить "--without-METHOD", с заменой rsh/rlogin или с совместным использованием и так далее;
- если вы готовы!?

Запускаете:

prompt> ./configure

prompt> make

prompt> make install

Обычно, для удобства работы, в зависимости от используемого SHELL, удобно запускать сборку с переопределением стандартных ввода, вывода и сообщения об ошибках:

CSH/TCSH

prompt> ./configure

prompt> make >& mk.log &

(далее можно заняться другими важными делами, параллельно просматривая log file:

prompt> less mk.log (SHIFT-F, see man less))

...

SH/BASH

prompt> ./configure

prompt> make 2>&1 >mk.log &

...

После успешной компиляции достаточно выполнить

prompt> make install

prompt> make hostinstall (для генерации host keys)

При необходимоти проверьте и отредактируйте следующие файлы:

/etc/sshd_config    (файл конфигурации сервера)
/etc/ssh_config     (файл конфигурации клиента - настройки по умолчанию для пользователей)
Если ваша машина будет использоваться как ssh-server, то, вероятно, имеет смысл создать или скопировать с другого надежного ssh-server'а в вашей сети файла:
      /etc/ssh_known_hosts,
в котором находятся public host keys известных в вашей сети машин, использующих SSH или можете оставить записи только нужных вам машин.

   Этот файл можно создать вручную или воспользоваться perl-script'ом:

make-ssh-known-hosts - для детального использования этой программы читайте

Если вы хотите иметь наиболее полную базу, вероятно следует запустить данный скрипт в такой день и час, когда возможно наибольшее число работающих в вашей сети компьютеров.
Для постоянного обновления базы host keys, вероятно можно запускать этот скрипт через cron (на мой взгляд черезмерное увлечение этим чревато).
С запуском данного скрипта возможна ситуация, когда вас атакуют многочисленные телефонные звонки и сетевые talk's. Это бдительные администраторы других серверов заметили соединения ssh к своим серверам и проявили беспокойство. Надеюсь вы знаете, что ответить на их вопросы!
Если вам нужно вставить ваш host key в базу другого сервера, вы можете договориться об этом с администратором такого сервера, дабы не лихорадить сеть запуском make-ssh-known-hosts и сделать это вручную.

3.6 Можно ли установить ssh в системе Unix будучи непривилегированным пользователем (non-root)?

Вы можете скомпилировать SSH под своим account'ом и в дальнейшем использовать программы ssh/scp для работы с удаленными системами, на которых запущен сервер sshd.

Если вы не хотите, чтобы при входе на удаленную систему вам требовалось вводить пароль, то необходимо сгенерировать private key в домашней директории, используя команду:

и после успешной генерации, положить ваш public key в файл ->

Кроме того, вы можете запустить сервер sshd, но не как привилегированный пользователь, используя опцию "-p", соответственно со стороны клиента используйте ту же опцию "-p" для запуска ssh. При таком запуске будут использовать непривилегированные адреса портов для соединения > 1024. И не забудьте, что после перезапуска сервера, вам опять необходимо будет запустить sshd.

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

Прежде всего, внимательно прочитайте данное справочное руководство или оригинальные источники:

ssh home page, at http://www.cs.hut.fi/ssh/
http://www.tac.nyc.ny.us/~kim/ssh/ (удачное руководство для пользователей)

Если вы нигде не нашли ответы на интересующие вас вопросы, попробуйте написать письмо в конференцию Usenet - comp.security.ssh или на адрес: ssh@clinet.fi или подписаться на список рассылки majordomo@clinet.fi со следующей строкой в теле письма: subscribe ssh

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

http://www.cs.hut.fi/ssh/ssh-archive.

3.8 Существуют ли версии ssh для систем отличных от Unix?

Heikki Suonsivu (hsu@clinet.fi) и Michael Henits (moi@dio.com) каждый предлагают по US$ 100 вознаграждения за первую стабильную версию ssh, свободно распространяемую для MS-Windows либо MacOS.

Уже существует, так сказать, предварительная версия для MS-Windows, реализованная Cedomir Igaly. К сожалению, она не позволяет использовать большое количество возможностей SSH, как, например, в Unix. Вы можете попытаться поискать эту версию с помощью archie: ssh-1-2-.zip.

/* у меня нет возможности попробовать различные реализации SSH под MS-Windows - просто нет PC с Windows, и нет Mac/
Ниже указан адрес, по которому можно найти версию ssh от Cedomir Igaly:

http://fox.doc.ic.ac.uk/~ci2/ssh/

Существует две версии ssh, написанных Cedomir Igaly - 32-bit (rev. 2.94) (uploaded on June 23, 1998 at 16:01 GMT; size is 136153 bytes) и 16-bit (rev. 2.94) (uploaded on June 23, 1998 at 16:00 GMT; size is 145532 bytes). Как пишет автор, 32-bit версия проверена им и работаета как под Windows 95, так и под NT, 16-bit версия не оттестирована, но автор использовал ее в работе под Windows95. Работа под MS Windows3.xx просто не проверялась. Эти версии ssh используют криптографическую библиотеку Peter Gutmann - crypt32.dll, можно использовать эту библиотеку начиная с версии 1.1, но для работы с DES необходимо воспользоваться правкой Cedomir'а - patch или использовать бета версию этой библиотеки 2.1, она должна работать.

Коммерческую версиую Tatu Yloenen, автора оригинального ssh, можно найти на

   http://www.europe.datafellows.com/f-secure/fssh-reg.htm

Bernt.Budde@udac.uu.se работает над портированием ssh под Mac.

Под VMS должен работать порт Mark Martinec (Mark.Martinec@nsc.ijs.si).

Порт под OS/2 можно взять на ftp://ftp.cs.hut.fi/pub/ssh/os2/ Кроме этого существует список рассылки для версии под OS/2. Подписаться можно, послав письмо по адресу majordomo@clinet.fi со строкой в теле: subscribe ssh-os2.

3.9 Администрирование ssh?

Одна из основных задач администрирования SSH - это управление host keys. Чтобы позволить клиенту соединиться с удаленной машиной, используя RSA host аутентикацию, сервер должен знать public key клиентов.

Автор оригинального FAQ по SSH предлагает собирать host key каждую ночь, используя perl-script make-ssh-known-hosts (распространяемый вместе с дистрибутивом) или использовать более быструю процедуру "ssh-keyscan", который можно взять с

В свою очередь, Thomas Koenig написал скрипт, который использует выходные данные этих утилит для поиска новых ключей, выдачи сообщений о тех host'ах, которые изменили свои ключи и, наконец, окончательной генерации новой базы host keys. Этот скрипт доступен на

Этими утилитами можно воспользоваться для создания у себя регулярного механизма проверки и поиска новых ключей. Все больше появляется администраторов, которые заботятся о безопасности обслуживаемых ими систем, соответственно, и машин, на которых установлен SSH, а значит и новых ключей, кроме того, некоторые администраторы берут за правило менять вдобавок и ключи(в принципе это лишнее) - данные программы и ваш опыт помогут следить вам за безопасностью ваших систем и контактировать с другими, изменившими свои host key, чтобы выяснить, а не является ли это изменение атакой хаккеров.

Со своей стороны хочу заметить, что во многих подсетях компьютеры часто выключаются, особенно это касается workstation с MS-Windows система и, на мой взгляд, удобнее запускать perl-script make-ssh-known-hosts не ночью, когда работают лишь основные сервера, а в момент наиболее интенсивной работы, м.б. в понедельник, среду и пятницу, однако, это зависимо и каждый администратор вправе выбрать наиболее подходящую ему схему.

Предполагается, что fingerprint схема (подобно PGP fingerprint) будет делать это быстрее, вероятно, она будет реализована в следующих версиях.

4. SSH ПРИЛОЖЕНИЯ

4.1 Можно ли запускать backup поверх ssh?

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

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

Нет, наоборот, шифрование должно всегда быть включено в целях безопасности и секретности.
Сегодняшние процессоры - CPU достаточно быстры, так что потери производительности могут быть несколько заметны на локальном Ethernet или технологически более быстрых соединениях. Однако при сильнозагруженных сетях Ethernet, ssh может быть также и существенно выгоден за счет передачи сжатых данных.

Кроме этого, вы можете сменить алгоритм шифрации, опция "-c blowfish", используя тем самым более быстрый Blowfish вместо IDEA по-умолчанию.

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

Да, используя для этого TCP forwarding.

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

Rdist 6.1.0 не работает совместно с ssh из-за соответствующих ошибок в нем. Но версия 6.1.1 и позже должны работать с ssh.
Если вы будете использовать rdist вместе с ssh, не забудьте при компиляции добавить путь к ssh, дополнительно можете указать опцию -P для использования rdist - ssh, вместо rsh.

Если вы исспользуете аутентикацию пароля в rdist 6.1.2 или 6.1.3, вам необходимо добавить следующий 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" м.б. найдена на:

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

Вы можете использовать PPP поверх регулярного ssh соединения. Готовое рабочее решение можно найти на:

Тем не менее, такая технология может иметь ряд проблем связанных с forwarding TCP соединений, потому что и TCP соединение, поверх которого запущен ssh, и TCP соединение, перенаправленное поверх PPP/ssh tunnel, могут быть одновременно ретранслированы. В этом случае лучше использовать криптованный IP tunneling по UDP. Возможные применения можно посмотреть:

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

Существует готовое решение на базе RPC-служб, например для NIS, которое можно взять с:

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

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

Нет, потому что GL использует совершенно отличный от X протокол.

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

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

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

Предположим, вы работаете на машине с именем "myhost" и хотите произвести ftp соединение с машиной "ftphost".

myhost$ ssh -L 1234:ftphost.do.main:21 ftphost

Таким образом вы войдете на машину "ftphost" и перенаправите соединение 1234 c "myhost" на "ftphost". Затем в другом окне выполняете:

myhost$ ftp mymachine 1234
220 ftphost FTP server (Foonix 08/15) ready.
Name: (myhost:yourname):
331 Password required for yourname
Password:
230 User yourname logged in.
 

Это работает лишь в том случае, если ftp-clien и ftp-daemon позволяют работать и перенаправлять порты разных машин. Данной операцией можно пользоваться при работе с vanilla UNIX ftp client и ftpd servers, но это может не работать с расширенными ftpds, такими как WU-FTPD.
Я опробовал данный способ со стандартными ftp-clients и ftp-daemon под разными Linux/FreeBSD/SunOS/Solaris/OSF1 и все работало до тех пор, пока мне не понадобилось установить WU-FTP.

Для серверов, которые не работают в таком режиме можно попробовать использовать ftp клиент в пассивном режиме и тогда ftp server должен принять PASV. Проверено, работает с WU-FTPD; на некоторых системах, например Solaris, имеет смысл установить ftp клиент поддерживающий passive-mode.

Для POP, Stephane Bortzmeyer (bortzmeyer@pasteur.fr) написал скрипт, который защищает передачу почты (mail) и паролей (password), используя ssh. При этом не требуется изменений в существующих POP серверах и клиентах и доступно с

   ftp://ftp.pasteur.fr/pub/Network/gwpop/

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

Да, Socks 5 должен работать с ssh версии 1.2.16 и более свежими.

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

В настоящий момент эта часть кода не включена в дистрибутив, однако существует правка доступная на

   http://www-personal.umich.edu/~dugsong/ssh-afs-kerberos.html,

которая должна вам помочь.

5. ПРОБЛЕМЫ

Если вы не найдете решение вашей проблемы среди нижеперечисленных, можете отослать сообщение о найденой вами ошибке по адресу ssh-bugs@clinet.fi, полностью отразив следующую информацию:
 

• Номера весий ssh и sshd (если различаются)

• Что ssh должен был выполнить

• Что ssh проделал вместо ожидаемого (включая все сообщения об ошибках)

• Какую систему вы используете (например вывод от "uname -a") и вывод от config.guess.

• При проблемах компиляции - содержимое файла config.log (сгенерированного посредством configure)

• Какой компилятор и флаги вы использовали

• Вывод от ssh -v

• Вывод от sshd демон-процесса, запущенного в отладочном режиме sshd -d

   ftp://ftp.cs.hut.fi/pub/ssh/snapshots/

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

Нет, не работает. Используйте "ssh -f otherhost xclient" вместо этого, или "ssh -n otherhost xclient &", если вы хотите, чтобы скрипт был совместим с rsh.

5.2 Ssh прекращает работу с сообщением "Resource temporarily unavailable" для Solaris

Ядро Solaris 2.4 имеет ошибку. Используйте Sun-patches или, как советует Sun Microsystems Inc., лучше Recommende cluster patches для исправления ошибок в системе Solaris. Для работы ssh в Solaris 2.4 patches: 101945-36 и 101945-37.

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

5.3 Sshd не работает под Solaris 2.5!

Это связано с ошибками в shared-разделяемых библиотеках Solaris, которые приводят к падению sshd при работе с некоторыми функциями name server.

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

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

Чтобы устранить эту проблему задайте hostname в форме FQDN (fully qualified domain name). Некоторые реализации Linux устанавливают в качестве hostname только первую часть из FQDN.

5.5 Ssh работает неверно с multi-homed hosts!

Проверьте, полный ли список возможных IP addresses возвращает gethostbyname() Например, на вашей системе resolver может искать в порядке начиная с файла hosts, а там, например, указан лишь один IP address.

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 это происходит при применении родного компилятора с использованием максимальной оптимизации.
Отключите все оптимизации или используйте для компиляции gcc. Известно что с Gcc 2.7.2 на Alpha не все в порядке, но тем не менее.

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

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

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

Это некорректно сконфигурирована Linux система, выполните следующее:

"cd /usr/lib; ln -s libc.sa libg.sa" под root-account и пересоберите заново.

5.10 X авторизация иногда отрабатывает неверно

Это замеченные ошибки в HP-UX 9 xauth, SR 5003209619. Примените patch PHSS_5568.

Если вы заметили похожие ошибки на других платформах, сообщите о деталях на ssh-bugs@clinet.fi.

5.11 Ssh требует от меня пароль несмотря на .rhosts!

Возможно несколько случаев когда это происходит:
 

• host key клиента не содержится в файле known_hosts. Не забывайте, что ssh работает с каноническими доменными именами, понятно почему, старайтесь использовать fqdn имена машин.

• машина-клиент не имеет реверса в DNS. Заметьте, что ssh должен иметь возможность как прямой, так обратной проверки DNS.

• multi-homed client или host не зарегистрировал все свои IP addresses в DNS. А версия ssh 1.2.12 имеет ошибку в разрешении multi-homed hosts.

• домашняя директория пользователя или файл ~/.rhosts с атрибутом записи для группы или остального мира,  что в корне неверно.

• На некоторых машинах с домашними директориями по NFS, домашняя директория и ~/.rhosts должны иметь атрибут доступа на чтение всем остальным.

• root account использует ~/.rhosts или ~/.shosts, а /etc/shosts.equiv и /etc/hosts.equiv игнорируются для root.

Как мне кажется, ни один опытный системный администратор не станет использовать root-account для входа по rsh/ssh, а только с console, для получения root-привелегий вполне можно воспользоваться командой "su".

• путаница между RhostsRSAAuthentication и RSAAuthentication.

RSAAuthentication основана на аутентикации пользователя и требует файла ~/.ssh/identity со стороны клиента и соответствующего public key в файле ~/.ssh/authorized_keys со стороны сервера.

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

Это проблемы конфигурации.

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

Возможны две ситуации, при которых это встречается:
 

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

• Вы переместили старые rsh и rlogin в директорию отличную от той, из которой они обычно вызывались. Старый rsh имел жестко прописанный путь для вызова rlogin и соответственно при вызове exec происходит ошибка и зацикливание.

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

который сгенерирует новую версию rsh и сохранит старую как rsh.orig. Теперь вы можете переконфигурировать заново ssh с опцией

--with-rsh=/usr/old/rsh

5.13 ssh-agent не работает с rxvt!

Rxvt, когда запускается - закрывает все файловые дескрипторы, включая и тот, который использует ssh-agent :). Используйте xterm или поищите патчи в архивах списка рассылки

   http://www.cs.hut.fi/ssh/ssh-archive/

Timo Rinne's rxvt patch

5.14 X авторизация всегда неверная

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

5.15 ssh прекращает работать когда форвардирует multiple TCP connections

Это было связано с ошибками в реализации ssh протокола до версий 1.2.13, поправлено в 1.2.14, но тем не менее с обеих сторон должна быть версия ssh не ниже, желательно выше, чем 1.2.14.
При возникновении таких ошибок рекомендуется установить на всех сторонах версию ssh 1.2.14 и выше.

5.16 Что означает Warning: remote host denied X11 forwarding mean?

Возможно следующее: либо удаленная сторона запрещает X11 forwarding (ForwardX11 No in the config file), либо xauth или X11 библтотеки не были найдены при компиляции сервера.

5.17 Я все еще вижу чистые текстовые пакеты в сети, после запуска ssh!

Вполне вероятно, что вы можете увидеть сессии telnet, rlogin или X session на той машине, на которой вы запустили ssh. Проверить действительно ли работает sshd можно посмотрев, какие пакеты проходят по 22 порту, именно этот порт слушает sshd.

5.18 Проблемы с RSAREF, что-то типа too many bits!

Это ограничения библиотеки RSAREF. Вы должны установить host key 896 bits.

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

В некоторых системах имеются ошибки в gmp assembler подпрограммах. Попробуйте следующее:

make distclean
configure --disable-asm

для компиляции.

5.20 Компиляция обрывается под Solaris 2.5!

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

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

Эта проблема была обнаружена при работе ssh версий 1.2.16 и 1.2.17 в следующих OS: SunOS 4, Solaris 2, Linux, и HP-UX 9/10. Она возникала при использовании scp, когда передавалось огромное количество данных через стандартный ввод ssh или при форвардировании X соединений, которые получали огромных размеров графические данные, например, mpeg movie.

Для предотвращения этих ошибок примените следующий патч к ssh 1.2.16/17 или установите более свежую версию ssh, начиная с 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) && (errno != EAGAIN))
      {
        if (fdin == fdout)
          shutdown(fdin, 1); /* We will no longer send. */

5.22 Соединения ssh форвардируются как "root"!

Когда клиент соединяется, sshd порождает дочерний процесс, который разбирает протокол и, в свою очередь, порождает второй процесс для пользовательских команд интерпретатора. И проблема в том, что только второй процесс может быть корректно использован с setuid(), а первый так и остается с root userid.

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

Это было сообщено как ошибка, однако неизвестно, будет ли исправлено в следующих версиях.