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.
sshd(8) - Серверная программа для запуска на серверной машине. Эта программа слушает сетевые запросы от удаленных - клиентских машин, и при получении запроса на соединение производит необходимые действия, авторизацию удаленного клиента и в случае ее прохождения запускает требуемую службу для удаленного клиента.
ssh(1) - Это клиентская программа, которая используется для входа на другую машину сети или выполнения команд на удаленном компьютере. slogin это другое имя этой же программы.
scp(1) - Безопасное копирование файлов с одной машины на другую.
ssh-keygen(1) - Используется для создания Публичных Авторизационных ключей (RSA or DSA) как для хостов(компьютеров), так и для пользователе.
ssh-agent(1) - Авторизационный Агент, который используется для хранения личных RSA ключей в памяти, для последующей авторизации с использованием публичных ключей.
ssh-add(1) - Используется для добавления новых личных ключей авторизационному агенту ssh-agent.
OpenSSH это набор программ для обеспечения безопасной работы в сети, ниже приводится список предоставляемых возможностей этого инструментария:
Строгая авторизация. Исправлено большое число дыр в безопасности. (например IP, routing, и DNS spoofing).
Усилена безопасность. Все соединения автоматически и прозрачно шифруются.
Безопасная работа X11 сессий. Программы автоматически устанавливают переменную DISPLAY на удаленном сервере, и перенаправляют любые соединения X11 по защищенным шифрованным каналам.
Произвольные TCP/IP порты могут быть перенаправлены через шифрованные каналы в обоих направлениях (например, для e-cash транзакций).
Нет необходимости переподготовки обычных пользователей.
Никогда не доверять сети. Минимальное доверие соединению с удаленной стороны. Минимальное доверие серверам доменных имен. Чистая RSA авторизация не доверяет ничему кроме личных ключей.
Клиент авторизует сервер по RSA в начале каждого соединения для защиты от трянских коней (routing или DNS spoofing) и man-in-the-middle атак, и сервер в свою очередь авторизует по RSA клиента, до принятия авторизации через .rhosts или /etc/hosts.equiv чтобы в свою очередь защитить себя от атак (DNS, routing, или IP-spoofing).
Распространение публичных ключей хостов может проводиться централизованно администраторами сети или автоматически при установлении с этим хостом первого соединения.
Любой пользователь может создать любое необходимое для своих нужд количество авторизационных ключей RSA.
Программа сервер имеет свой собственный RSA ключ сервера который автоматически изменяется, по умолчанию каждый час.
В дополнение можно использовать авторизационный агент чтобы хранить в памяти RSA авторизационные ключи пользователя лаптопа, нотбука или рабочей станции.
OpenSSH может быть установлен и использован (с некоторыми ограничениями) даже без привилегий суперюзера root.
Конфигурация клиентской части может быть изменена как в соответствующих системных конфигурационных файлах, так и в конфигурационных файлах самих пользователей.
В случае если на удаленном сервере не используется или не работает серверная программа sshd, клиент автоматически попытается перейти на работу через rsh если он поддерживается сервером и при этом будет выдано соответствующее сообщение.
При работе может быть использована компрессия всех данных посредством использования gzip (включая форвардирование соединений X11 и перенаправление TCP/IP портов), причем компрессия может значительно повысить скорость работы, особенно на медленных соединениях/каналах.
Полная замена средств rlogin, rsh, и rcp.
На настоящий момент, почти все коммуникации в компьютерных сетях сделаны без шифрации. И как результат, любой кто имеет доступ к компьютеру подключенномув сеть сможет подслушать практически любые сетевые соединения. Этим методом могут воспользоваться хакеры, любопытные системные администраторы, предприниматели, криминальные элементы, промышленные шпионы или правительственные службы. Некоторые сети и компьютерное оборудование имеют достаточное электромагнитное излучение благодаря которому данные могут быть сняты даже на расстоянии.
Когда вы осуществляет заход на удаленный компьютер в сети, ваш пароль передается в сети открытым текстом. Поэтому любой подслушавший ваш login и пароль в сети, сможет им воспользоваться чтобы сделать любую гнусность которую он пожелает. Большинство подобных инцендентов наблюдалось на тех компьютерах в сети, которые остались без компетентного администрирования и на них были установлены программы прослушивания сети и сбора паролей. Подобные программы свободно доступны в сети Internet или могут быть написаны компетентным программистом за несколько часов.
Существует масса секретной информации, коммерческие тайны, патенты на изобретения, закрытая информация о ценах, информация о подрядчиках и контрактерах, данные клиентов, личные данные, финансовая информация и т.д. и т.п. И в настоящее время, любой кто имеет доступ к сети (любой компьютер в сети) может подслушать все что передается по сети, без каких-либо ограничений доступа.
Многие компании не представляют что информация так легко может быть извлечена при наличии доступа в сеть. Они полагают что их данные в безопасности потому что никому не известно что информация в сети может быть подслушана или потому что количество передаваемых в сети данных слишком велико. Это не безопасная политика.
Несмотря на то что OpenSSH разработан в рамках проекта OpenBSD тем не менее существует масса его портов для других операционных систем. Проект портирования версий OpenSSH возглавляет Damien Miller. Для быстрого обзора портированных версий OpenSSH смотрите: http://freebsd.3dn.ru/portable.html. Короткий список других OS's которые поддерживают OpenSSH, приведен ниже.
Разработчики 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) команды.
В продолжение предыдущего вопроса, (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 для отключения рекеинга:
Старые версии SSH использовали патентованный алгоритм для шифрации своих /etc/ssh/ssh_host_key. Эта проблема ясно показывает что sshd(8) не сможет прочитать собственные ключи. Для решения этой проблемы воспользуйтесь ниже приведенной командой для преобразования вашего ssh_host_key с использованием метода 3DES. Примечание: Воспользуйтесь ssh-keygen(1) программой от Коммерческой версии продукта SSH первой версии, *НЕ* от OpenSSH, пример приведен ниже.
Программа 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 как показано ниже и в других подобных настройках тоже:
От версии к версии в конфигурационных файлах OpenSSH sshd_config или ssh_config происходят изменения. Будьте внимательны и после замены старой версии на новую всегда проверяйте какие изменения были внесены в конфигурацию новой версии. Например, при переходе с версии OpenSSH 2.3.0 до 2.5.1 вам необходимо добавить следующую строку в файл sshd_config
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. Например:
Это необходимо сделать в дополнение к установкам "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.
Убедитесь в том что ваши библиотеки OpenSSL были собраны с внутренней поддержкой RSA или DSA или через RSAref. Реализация RSA и DSA включены в OpenSSL и их использование в OpenSSH зависит от того как были собраны библиотеки OpenSSL которые использует OpenSSH.
Программа scp(1) должна находится в директории которая находится в пути/PATH как у клиента, так и сервера. Если вы хотите разместить эту программу в специальной директории, вам необходимо задать ее в опции --with-default-path в соответстии с заданным вами маршрутом программа будет разыскиваться в этом пути на сервере. Эта опция заменяет поиск в пути по умолчанию, поэтому вам необходимо указать все необходимые директории для поиска в пути, включая ту где находится программа scp. Например:
Или просто укажите все необходимые директории в переменной окружения PATH в настройках инициализации вашего SHELL, включая директорию где находится 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 активным процессам при выходе.