1.0 - Что такое OpenSSH и Где Я могу его взять?
- 1.1 - Что такое OpenSSH?
- 1.2 - Почему его надо использовать?
- 1.3 - Какие Операционный системы поддерживаются в OpenSSH?
- 1.4 - Какие соглашения у OpenSSH о copyright(правах), использовании и патентах?
- 1.5 - Где можно получить помощь?
2.0 - Основные Вопросы.
- 2.1 - Почему ssh/scp открывают соединения по низким портам( < 1024). Мой firewall блокирует их.
- 2.2 - Почему ssh клиент setuid root?
- 2.3 - Почему у SSH 2.3 возникают проблемы при взаимодействии с OpenSSH 2.1.1?
- 2.4 - Старые версии коммерческого SSH криптовали "host keys" патентованным алгоритмом IDEA, как быть?
- 2.5 - Что означают предупреждающие сообщения о длинне ключа?
- 2.6 - X11 форвардинг и/или агент не раюотают.
- 2.7 - После апгрейда на OpenSSH 2.5.1 пропала поддержка SSH2.
- 2.8 - sftp/scp слетают при соединении, хотя ssh работает.
3.0 - Вопросы связанные с портабельными версиями OpenSSH.
- 3.1 - Паразитные сообщения от PAM authentication в лог-файлах.
- 3.2 - Пустые пароли не допустимы с PAM authentication.
- 3.3 - ssh(1) очень долго соединяется с Linux/glibc 2.1
- 3.4 - Что означают "Can't locate module net-pf-10" сообщения в логах Linux'а.
- 3.5 - Авторизация через пароль - Password authentication не работает в Slackware 7.0
- 3.6 - Configure или sshd(8) сообщают что отсутствует поддержка RSA.
- 3.7 - Что означают сообщения "scp: command not found".
- 3.8 - Что означают сообщения "Unable to read passphrase".
- 3.9 - Отсутствует файл 'configure' или make завершается неудачно.
- 3.10 - Замирание при выходе из ssh.
OpenSSH это СВОБОДНАЯ версия известного набора сетевого инструментария SSH, количество поклонников и пользователей которого в Internet существенно возросла и продолжает расти. Большинство пользователей таких программ как telnet, rlogin, ftp, и других подобных программ не знают или осознают что эти программы передают по сети пользовательские пароли в нешифрованном виде в отличие от OpenSSH. OpenSSH шифрует весь передаваемый трафик (включая пароли) и эффективно предотвращает подслушивание, похищение.перехват соединений и другие виды сетевых атак.
Пакет OpenSSH включает в себя ssh(1) программу для замены таких средств как rlogin и telnet, программу scp(1) которая заменяет такие средства как rcp(1) и ftp(1). Недавно в OpenSSH были реализованы и добавлены sftp(1) и sftp-server(8) которые реализуют простую передачу файлов.
OpenSSH consists of a number of programs.
OpenSSH это набор программ для обеспечения безопасной работы в сети, ниже приводится список предоставляемых возможностей этого инструментария:
На настоящий момент, почти все коммуникации в компьютерных сетях сделаны без шифрации. И как результат, любой кто имеет доступ к компьютеру подключенномув сеть сможет подслушать практически любые сетевые соединения. Этим методом могут воспользоваться хакеры, любопытные системные администраторы, предприниматели, криминальные элементы, промышленные шпионы или правительственные службы. Некоторые сети и компьютерное оборудование имеют достаточное электромагнитное излучение благодаря которому данные могут быть сняты даже на расстоянии.
Когда вы осуществляет заход на удаленный компьютер в сети, ваш пароль передается в сети открытым текстом. Поэтому любой подслушавший ваш login и пароль в сети, сможет им воспользоваться чтобы сделать любую гнусность которую он пожелает. Большинство подобных инцендентов наблюдалось на тех компьютерах в сети, которые остались без компетентного администрирования и на них были установлены программы прослушивания сети и сбора паролей. Подобные программы свободно доступны в сети Internet или могут быть написаны компетентным программистом за несколько часов.
Существует масса секретной информации, коммерческие тайны, патенты на изобретения, закрытая информация о ценах, информация о подрядчиках и контрактерах, данные клиентов, личные данные, финансовая информация и т.д. и т.п. И в настоящее время, любой кто имеет доступ к сети (любой компьютер в сети) может подслушать все что передается по сети, без каких-либо ограничений доступа.
Многие компании не представляют что информация так легко может быть извлечена при наличии доступа в сеть. Они полагают что их данные в безопасности потому что никому не известно что информация в сети может быть подслушана или потому что количество передаваемых в сети данных слишком велико. Это не безопасная политика.
Несмотря на то что OpenSSH разработан в рамках проекта OpenBSD тем не менее существует масса его портов для других операционных систем. Проект портирования версий OpenSSH возглавляет Damien Miller. Для быстрого обзора портированных версий OpenSSH смотрите: http://www.openssh.com/portable.html. Короткий список других OS's которые поддерживают OpenSSH, приведен ниже.
Список производителей которые включают OpenSSH в свои дистрибутивы можно найти на странице www.openssh.com/users.html.
Разработчики OpenSSH приложили много труда и усилий чтобы сохранить этот проект свободным от каких либо патентов или проблем с copyright. Чтобы реализовать это пришлось наложить ограничения для некоторых опций, а именно, для запатентованных алгоритмов.
OpenSSH не поддерживает запатентованные транспортные алгоритмы. В режиме работы SSH1, поддерживаются опции для 3DES и Blowfish. В режиме работы SSH2, можно использовать лишь алгоритмы 3DES, Blowfish, CAST128, Arcfour и AES. Запатентованный алгоритм IDEA не поддерживается.
OpenSSH обеспечивает поддержку обоих протоколов и SSH1, и SSH2.
С тех пор как истекло время ограничения на использование патента RSA, больше не существует ограничений на использование алгоритма RSA в программных продуктах, включая OpenBSD.
Существует масса мест в Internet где можно получить помощь или консультации, в дополнение к основному вебсайту OpenSSH: http://www.openssh.com, существует много списков рассылки, можете воспользоваться ими. Однако перед тем как задать вопросы в эти списки, предварительно поищити необходимую вам информацию через поиск по архивам этих списков рассылки, чтобы не повторять вопросы на которые уже известен и был дан ответ. Один из списков и архив можно найти по ссылке: theaimsgroup.com.
Более подробную информацию по подписке на OpenSSH и связанные с ним списки рассылок можно найти на странице: www.openssh.com/list.html.
Клиент OpenSSH использует номера портов из нижней части, те < 1024 для rhosts и rhosts-rsa авторизации чтобы сервер в свою очередь разрешил клиенту с указанным именем осуществить вход на сервер. Чтобы избежать этого и работать по высоким портам, вам необходимо добавить следующие строки в конфигурационные ssh_config или ~/.ssh/config файлы.
UsePrivilegedPort no
Или вы можете воспользоваться указанным выше сервисом через командную строку, используя -o опцию ssh(1) команды.
$ ssh -o "UsePrivilegedPort no" host.com
В продолжение предыдущего вопроса, (2.1) OpenSSH должен иметьroot привелегии чтобы открыть нижние порты < 1024 для возможности rhosts и rhosts-rsa авторизации. Вы можете безболезненно удалить setuid bit с исполняемого файла ssh в том случае, если вы не будете использовать этот метод авторизации.
В SSH версий 2.3 и младше имеется недостаток в реализции HMAC. Вместо того, чтобы посылать полный блок данных дайджеста, код этих версий всегда ограничивается 128 битами. При использовании более длинных дайджестов SSH 2.3 несовместим с OpenSSH.
OpenSSH 2.2.0 распознает этот дефект SSH 2.3. Эта ошибка будет исправлена в новых версиях SSH. Избежать эту ситуацию в SSH 2.3 поможет добавление строки в /etc/sshd2_config следующего вида:
Mac hmac-md5
Помимо дефектной (кривой) реализации HMAC, была замечена следующая проблема: OpenSSH не поддерживает функцию рекеинга (rekeying). SSH 2.3 пытается истользовать эту функциональность. В результате вы можете получить зависшую сессию или сообщение об ошибке "Dispatch protocol error: type 20". Для решения этой проблемы либо используйте SSH версии 2.4 и выше, либо добавьте следующую строку в файл конфигурации SSH версии 2.3 sshd_config для отключения рекеинга:
RekeyIntervalSeconds 0
Старые версии SSH использовали патентованный алгоритм для шифрации своих /etc/ssh/ssh_host_key. Эта проблема ясно показывает что sshd(8) не сможет прочитать собственные ключи. Для решения этой проблемы воспользуйтесь ниже приведенной командой для преобразования вашего ssh_host_key с использованием метода 3DES. Примечание: Воспользуйтесь ssh-keygen(1) программой от Коммерческой версии продукта SSH первой версии, *НЕ* от OpenSSH, пример приведен ниже.
# ssh-keygen -u -f /etc/ssh/ssh_host_key
Программа ssh-keygen(1) из коммерческого пакета SSH содержала ошибки при генерации Публичных ключей (RSA или DSA) в которых отсутствовал Most Significant Bit (MSB). Такие ключи представлялись как полноценные, в то время как это на самом деле было не так, те их длина была меньше на один бит.
OpenSSH в таких случаях будет выдавать предупреждение, если встретит такие ключи. Чтобы избавиться от подобных сообщений, отредактируйте ваш файл known_hosts и замените ключи с некорректным размером (обычно "1024") на их реальную длину (обычно "1023"). Следует заметить, что эти ключи менее безопасные и поэтому лучше заменить их создав новые.
Проверьте ваши файлы ssh_config и sshd_config. По умолчанию, в конфигурационных файлах запрещена авторизация и форвардирование соединений X11. Чтобы разрешить использование этих возможностей, поместите указанную ниже строку в конфигурационный файл сервера sshd_config:
X11Forwarding yes
и следующие строки в конфигурационный файл клиента ssh_config:
ForwardAgent yes
ForwardX11 yes
Примечание: Для пользователей системы Linux Mandrake 7.2, Mandrake изменяет значение переменной среды XAUTHORITY в файле /etc/skel/.bashrc, и возможно в стартовых файлах домашней директории пользователей у котоых в качестве SHELL установлен BASH. Поскольку эту переменную устанавливает OpenSSH, закомментируйте строку в /etc/skel/.bashrc как показано ниже и в других подобных настройках тоже:
# export XAUTHORITY=$HOME/.Xauthority
От версии к версии в конфигурационных файлах OpenSSH sshd_config или ssh_config происходят изменения. Будьте внимательны и после замены старой версии на новую всегда проверяйте какие изменения были внесены в конфигурацию новой версии. Например, при переходе с версии OpenSSH 2.3.0 до 2.5.1 вам необходимо добавить следующую строку в файл sshd_config
HostKey /etc/ssh_host_dsa_key
sftp и/или scp могут разрывать соединение в том случае если ваши настройки SHELL (.profile, .bashrc, .chsrc, etc) таковы, что после инициализации среды происходит попытка произвести вывод в не интерактивных сессиях. Этот вывод сбивает работу sftp/scp клиента и приводит к сбою. Проверить настройки собственного shell'а можно выполнив команду:
ssh yourhost /usr/bin/true
Если отработка указанной выше команды производит какой-либо вывод, вам необходимо изменить настройки среды.
Портированные версии OpenSSH могут производить паразитные сообщени в лог-файлы при каждом входе, подобно приведенному ниже:
"authentication failure; (uid=0) -> root for sshd service"
Эти сообщения выдаются потому что OpenSSH сперва пытается определить какой метод авторизации использует пользователь при входе (например empty password). К сожалению PAM регистрирует любые попытки авторизации, включая указанные и записывает их в логи.
Если это раздражает или мешает вам, установите "PermitEmptyPasswords no" в sshd_config. Это оградит вас от подобных сообщений и запретит вход по беспарольным аккаунтам. Эта опция используется по умолчанию в случае конфигурационного файла sshd_config из поставки OpenSSH.
Чтобы разрешить использовать пустые пароли в OpenSSH, собранным с поддержкой PAM вам необходимо добавить флаг nullok в строке соответствующего модуля проверки пароля в конфигурационном файле PAM /etc/pam.d/sshd. Например:
auth required/lib/security/pam_unix.so shadow nodelay nullok
Это необходимо сделать в дополнение к установкам "PermitEmptyPasswords yes" в sshd_config файле.
Существует одно важное замечание по использованию пустых паролей с PAM авторизацией: PAM будет разрешать задавать любые пароли при авторизации через вход с пустым паролем. И это нарушает проверку которую sshd(8) использует для определения что данный аккаунт без пароля и гарантированного доступа пользователю невзирая на значение указанное в PermitEmptyPasswords. Вот почему в целях безопасности не рекомендуется добавлять директиву nullok вашу конфигурацию PAM до тех пор пока у вас не осталось иного варианта как разрешить работу с пустыми паролями.
Версия библиотеки glibc поставляемая с Redhat 6.1 действительно занимает много времени для разрешения "IPv6 или IPv4" адресов из доменных имен. Эту проблему можно обойти использую опцию configure --with-ipv4-default при автоконфигурации OpenSSH перед компиляцией. В это случае OpenSSH будет использовать только IPv4 схему разрешения адресов. (IPv6 метод может быть задан указанием опции -6).
Ядро Linux пытается найти (через modprobe) и подгрузить протокол семейства 10 (IPv6). Либо вручную подгрузите в ядро соответствующий модуль, либо задайте правильный алиас в файле подгружаемых модулей /etc/modules.conf или отключите поддержку IPv6 в /etc/modules.conf.
Иногда в целях дурако-устойчивости файл /etc/modules.conf в Linux может иметь имя /etc/conf.modules.
В Slackware 7.0, OpenSSH необходимо собирать с крипто-библиотекой libcrypt.
LIBS=-lcrypt ./configure [options]
Убедитесь в том что ваши библиотеки OpenSSL были собраны с внутренней поддержкой RSA или DSA или через RSAref. Реализация RSA и DSA включены в OpenSSL и их использование в OpenSSH зависит от того как были собраны библиотеки OpenSSL которые использует OpenSSH.
Программа scp(1) должна находится в директории которая находится в пути/PATH как у клиента, так и сервера. Если вы хотите разместить эту программу в специальной директории, вам необходимо задать ее в опции --with-default-path в соответстии с заданным вами маршрутом программа будет разыскиваться в этом пути на сервере. Эта опция заменяет поиск в пути по умолчанию, поэтому вам необходимо указать все необходимые директории для поиска в пути, включая ту где находится программа scp. Например:
Или просто укажите все необходимые директории в переменной окружения PATH в настройках инициализации вашего SHELL, включая директорию где находится scp.
$ ./configure --with-default-path=/bin:/usr/bin:/usr/local/bin:/path/to/scp
В некоторых операционных системах устройство /dev/tty имеет некорректно установленные права, в результате чего невозможно прочитать пароль с данного устройства, о чем и выдается ошибка:
You have no controlling tty. Cannot read passphrase.
Для решения этой проблемы установите для устройства /dev/tty права 0666 и сообщите об этой ошибке продавцу вашей OS.
Если в вашем дистрибутиве отсутствует файл 'configure' или процесс сборки `make` завершился с сообщениями об ошибках вида "missing separator", вероятно вы загрузили или скачали версию OpenSSH для дистрибутива OpenBSD, а пытаетесь откомпилировать на другой платформе. Пожалуйста прочтите информацию о портированных версиях на странице portable version возьмите необходимый вам дистрибутив OpenSSH в соответствии со ссылками для вашей OS.
Текущая версия OpenSSH может подвисать при выходе. Это встречается когда еще остались активные фоновые процессы. Такое обычно встречается в системах Linux и HP-UX. Наличие этой проблемы можно проверить следующим образом: sleep 20&exit.
Пользователи у которых в качестве SHELL'а установлен bash, для решения этой проблемы могут поместить "shopt -s huponexit" в файл /etc/bashrc или в файл ~/.bashrc. В остальных случаях, читайте руководства по вашему SHELL как разрешить послать сигнал HUP активным процессам при выходе.
www@openbsd.org