Ключевые слова:ssh, security, crypt, (найти похожие документы)
From: Андрей Лаврентьев <lavr@unix1.jinr.ru>
Original: http://unix1.jinr.ru/~lavr/Subject: Быстрый тур по установке и настройке SSH.
Автор: Андрей Лаврентьев (lavr@unix1.jinr.ru), http://unix1.jinr.ru/~lavr/
/* Задумывался как быстрый тур, что получилось ... :)
черновой текст без правок и переработок, что само собой необходимо...
кроме того, пока действительно сюда не включен быстрый тур ибо еще не
готов. Тур содержит конкретные советы по установке, настройке и
использованию...
*/
Быстрый тур по установке
и настройке SSH.
Содержание:
1. Краткий обзор SSH (Secure Shell).
2. Установка пакета SSH в системах Unix.
3. Настройки пользователя со стороны клиентской части.
4. Настройки SSH для использования в среде X11 посредством
запуска Windows через "startx"
5. Создание списка "публичных ключей" для компьютеров-машин-серверов
из локального или требуемого домена.
6. Возможные проблемы.
1. Краткий обзор SSH (Secure Shell).
Основываясь на своем жизненном опыте, позволю некоторое лирическое
отступление...
В отличие от сказок, которые мы в детстве слышали от мам, пап, бабушек
дедушек и других родных или близких нам людей, в жизни "ЗЛО" много чаще
"побеждает" "ДОБРО", кроме этого нам порой кажется что именно "зла" вокруг
больше чем добра, но слава богу это не так, просто добрые дела нами чаще
воспринимается как обычное явление и потому не оставляет в нашей памяти
такого следа как "зло", а жаль...
Не вдаваясь в теорию "единства и борьбы противоположностей", полагаю, что
зло-добро, белое-черное, плохие-хорошие, создатели-разрушители это как одно
целое, связанное между собой невидимыми нитями и мы постоянно выбираем
что есть что и какую позицию нам стоит занять чтобы решить как действовать...
Не могу причислить себя как ярым противникам "хаккеров", но уверен что
от той доброй половины их, а может быть и больше, которая не умеет даже
правильно использовать плоды чужих трудов просто необходимо защищаться.
Технологии сети Internet предоставляют доступ к невероятно огромному
количеству различных ресурсов всем желающим независимо от того кто они,
добрые или злые, плохие или хорошие...
Увы, но любой желающий может найти специализированные программы или пакет
программ позволяющий установить его на компьютер, включенный в локальную сеть,
и подслушивать чужие пароли проходящие в незащищенных сетевых средах, а затем
использовать их с недобрым умыслом или в корыстных целях...
В альтернативу этому создаются другие программы, комплексы програмных средств
позволяющие шифровать свои сеансы работы, ставить различные заграждения или
преграды на пути "хаккеров", один из таких пакетов - SSH (Secure Shell).
SSH (Secure Shell) - это программа позволяющая входить на другие удаленные
компьютеры в сети, выполнять на них команды-программы или переносить данные
с одной машины на другую. SSH строго обеспечивает секретность и достоверность
передаваемых данных по незащищенным компьютерным каналам и представляет собой
альтернативную замену таким известным и привычным средствам как:
"rlogin", "rsh", "rcp", и "rdist".
Возможности:
~~~~~~~~~~~~
- жесткая проверка и достоверность, исключение большинства различных "узких"
(ненадежных) сетевых мест (IP, routing, and DNS spoofing). Использование
новых методов проверки: .rhosts совместно с RSA based host authentication
и чистый метод проверки RSA.
- Улучшена секретность. Все соединения прозрачно и автоматически шифруются.
Для обмена ключей используется метод 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.
Почему имеет смысл использовать SSH.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Большинство всех коммуникаций в компьютерных сетях работают без шифрации
передаваемых по ним данных, как следствие, любой кто имеет доступ к какой-
либо машине подсоединенной к сети, получает возможность прослушивать данные
коммуникации.
Вероятно это было сделано хаккерами, любопытными администраторами, пользова-
телями, криминальными структурами, промышленными шпионами или правительствен-
ными структурами. Некоторое сетевое оборудование производит достаточное электро
магнитное излучение необходимое для дистанционного перехвата данных.
Когда вы осуществляете вход на копьютер, ваш пароль проходит в сети обычным
текстом, таким образом любой кто его подслушал, может затем воспользоваться им
в любых целях. Большинство таких инцидентов, насчитываемых в мировой практике
связано с компьютерами у которых нет реальных владельцев, в результате чего
они чаще всего являются теми узкими местами где обычно заущены программы под-
слушивающие сеть и коллекционирующие чужие пароли. Программы для данных целей
вполне доступны в сети Inernet или могут быть написаны компетентными програм-
мистами за несколько часов.
Более того, существует возможность "похищения" сетевого соединения, т.е.
подразумевается что вторжение может произойти посреди соединения с изменением
проходящих данных в обоих направлениях. Например, это может быть использовано
для выполнения "новых" команд в сеансах идентифицированных паролем лишь
одинажды.
Следовательно не существует полноценного метода аутентикации пользователя при
котором сохраняется безопасность работы и несанкционированный доступ к его
данным.
Более того, routing spoofing (подложная/ложная/подставная(подстава) маршрутиза-
ция) может использоваться для "переноса" почти любого Internet-соединения в
место где данное соединение может быть успешно атаковано.
Методы шифрации-дешифрации и целостной защиты данных просто необходимы для
для защиты компьютерных сетей и систем. Поэтому SSH использует сложные крипто-
графические алгоритмы для достижения этих целей.
Известно, что один из важных критериев программного продукта - простота
в использовании, SSH попытались сделать проще в использовании чем те ненадежные
программные средства которые он призван заменить.
В настоящее время SSH уже получил самое широкое признание. В настоящее время
SSH используется приблизительно в 50-и странах и вероятно в десятках тысяч
организаций. Он используется как в университетах, научных институтах, лабора-
ториях, так и в банках, больших корпорациях, как в небольших компаниях малого
бизнеса, так и частными лицами.
SSH может быть установлен почти на всех Unix платформах и коммерческие версии
существуют также под Windows (3.1, 95, NT) и Macintosh.
Обзор пакета SSH
Данный программный продукт состоит из следующих программ:
sshd Сервер-программа(демон) запускаемая на сервере. Прослушивает
соединения от клиентских машин и при установлении связи производит
аутентикацию и начинает обслуживание клиента.
ssh Программа клиент используемая для входа на удаленную машину или
выполнения команд на другой машине.
Другое имя этой программы - "slogin".
scp Секретное копирование файлов с одной машины на другую.
ssh-keygen Используется для создания RSA ключей машины и пользователя.
(host keys and user authentication keys).
ssh-agent Программа аутентикации(достоверности-соответствия). Она может
быть использована для хранения в памяти ключей для аутентикации.
ssh-add Используется для регистрации новых ключей с агентом.
make-ssh-known-hosts
Используется для создания базы ключей машин (host keys) -
/etc/ssh_known_hosts.
Коротко об испльзовании
Основным инструментом пользователя является программа 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/inetd.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 .
Замеченные ошибки или замечания следует отправлять по адресу:
ssh-bugs@cs.hut.fi
ОБ АВТОРЕ
Данный программный продукт был оригинально разработан - Tatu Ylonen
<ylo@cs.hut.fi> в Финляндии. В настоящее время он сопровождается:
SSH Communications Security - http://www.ssh.fi/
и
Data Fellows - http://www.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"!
6. Разное
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-faqhttp://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
По оригиналу FAQ свои замечания и предложения отсылайте автору:
Thomas.Koenig@ciw.uni-karlsruhe.de
По оригиналу 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 защищает против:
o IP spoofing, когда чужая машина посылает свои пакеты маскирую их под те
которым разрешено работать, ssh может защитить от ложных паеьов не только
извне, но и внутри локальной сети.
o IP source routing, когда машина изменяет проходящие через нее пакеты.
o DNS spoofing, когда атакующий подделывает-изменяет записи name-server'а
o Перехват чистых(некриптованых) паролей и других данных при межмашинном
обмене
o Атаки основанные на подслушивании данных аутентикации 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, которая
является торговым представителем по приобретению лицензии. Дополнительная
информация может быть найдена:
http://www.europe.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
Последняя версия доступна с 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 - для детального использования этой программы читайте
руководство - man.
Если вы хотите иметь наиболее полную базу, вероятно следует запустить данный
скрипт в такой день и час, когда возможно наибольшее число работающих в вашей
сети компьютеров.
Для постоянного обновления базы 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 в домашней директории исполь-
зую команду:
prompt> ssh-keygen (далее ввести passphrase)
и после успешной генерации, положить ваш public key в файл ->
$HOME/.ssh/authorized_keys
Кроме того вы можете запустить сервер 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", который
можно взять с
ftp://cag.lcs.mit.edu/pub/dm/
или
ftp://ftp.cs.hut.fi/ssh/contrib/
В свою очередь Thomas Koenig написал скрипт который использует выходные
данные этих утилит для поиска новых ключей, выдачи сообщений о тех host'ах
которые изменили свои ключи и наконец окончательной генерации новой базы
host keys. Этот скрипт доступен на
http://www.uni-karlsruhe.de/~ig25/ssh-faq/comp-host-list
Этими утилитами можно воспользоваться для создания у себя регулярного механиз
ма проверки и поиска новых ключей. Все больше появляется администраторов
которые заботятся о безопасности обслуживаемых ими систем, соответственно и
машин на которых установлен 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>
Его также следует применить при получении следующего сообщения об ошибке:
"Warning: Denied agent forwarding because the other end has too old version."
(встречается когда ваш клиент 1.2.17 и позже, а соединяется с более старой
версией сервера).
Другой путь, использовать вместо "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
Тем не менее, такая технология может иметь ряд проблем связанных с forwarding
TCP соединений, потому что и TCP соединение поверх которого запущен ssh и
TCP соединение перенаправленное поверх PPP/ssh tunnel могут быть одновременно
ретранслированы. В этом случае лучше использовать криптованный IP tunneling
по UDP. Возможные применения можно посмотреть:
http://www.inka.de/~bigred/devel/cipe.html
4.6 Можно ли использовать ssh для перенаправления UDP-based сервисов, таких
как NIS и NFS?
Существует готовое решение на базе RPC-служб, например для NIS, которое можно
взять с:
ftp://ftp.tu-chemnitz.de/pub/Local/informatik/sec_rpc/
В принципе можно адаптировать и для 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
полностью отразив следующую информацию:
o Номера весий ssh и sshd (если различаются)
o Что ssh должен был выполнить
o Что ssh проделал вместо ожидаемого (включая все сообщения об ошибках)
o Какую систему вы используете (например вывод от "uname -a") и вывод от
config.guess.
o При проблемах компиляции - содержимое файла config.log (сгенерированного
посредством configure)
o Какой компилятор и флаги вы использовали
o Вывод от ssh -v
o Вывод от sshd демон-процесса запущенного в отладочном режиме sshd -d
Пожалуйста, прежде чем отсылать сообщения о возникших у вас ошибках, попробуй-
те установить и использовать последний snapshot:
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!
Возможно несколько случаев когда это происходит:
o host key клиента не содержится в файле known_hosts. Не забывайте что ssh
работает с каноническими доменными именами, понятно почему, старайтесь
использовать fqdn имена машин.
o машина-клиент не имеет реверса в DNS. Заметьте что ssh должен иметь возмож-
ность как прямой, так обратной проверки DNS.
o multi-homed client или host не зарегистрировал все свои IP addresses в DNS.
А версия ssh 1.2.12 имеет ошибку в разрешении multi-homed hosts.
o домашняя директория пользователя или файл ~/.rhosts с атрибутом записи для
группы или остального мира - что в корне неверно.
o На некоторых машинах с домашними директориями по NFS, домашняя директория
и ~/.rhosts должны иметь атрибут доступа на чтение всем остальным.
o root account использует ~/.rhosts или ~/.shosts, а /etc/shosts.equiv и
/etc/hosts.equiv игнорируются для root.
Как мне кажется ни один опытный системный администратор не станет использо-
вать root-account для входа по rsh/ssh, а только с console, для получения
root-привелегий вполне можно воспользоваться командой "su".
o путаница между 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 со стороны клиента и соответствующего public key в файле
~/.ssh/authorized_keys со стороны сервера.
5.12 Почему ssh циклится с сообщением "Secure connection refused'?
Это проблемы конфигурации.
Ssh пытается вернуться к "r" командам когда не может соединиться с демон
процессом sshd удаленной машины. Это означает выполнение вашего старого
rsh и использование старых протоколов.
Возможны две ситуации при которых это встречается:
o Возможно вы установили ssh как rsh и забыли указать опцию --with-rsh=PATH
при конфигурации. В таком случае когда ssh пытается найти "rsh" и не может
этого сделать, он запускает самого себя. Для решения этой проблемы пере-
компилируйте ssh и установите заново.
o Вы переместили старые rsh и rlogin в директорию отличную от той из которой
они обычно вызывались. Старый rsh имел жестко прописанный путь для вызова
rlogin и соответственно при вызове exec происходит ошибка и зацикливание.
В этом случае можно поступить следующим образом, переписать старые rsh и
rlogin в директорию /usr/old и поправить старый rsh используя следующий
Perl script:
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.
Это было сообщено как ошибка, однако неизвестно, будет ли исправлено в
следующих версиях.
6. Разное
/* В стадии обдумывания */
