![[OpenSSH]](../images/smalltitle.gif){kind=small}
1.0 Что такое OpenSSH?
- 1.1 – Что такое OpenSSH и где я могу скачать её?
- 1.2 – Почему стоит использовать именно её?
- 1.3 - Какие операционные системы поддерживаются?
- 1.4 - Что на счет copyrights, лицензий и патентов?
- 1.5 - Где я могу получить поддержку?
- 1.6 - Я нашел ошибку. Где и как я могу сообщить о ней?
2.0 - Общие вопросы
- 2.1 - Почему ssh/scp используют низкие номера портов? Мой фаервол блокирует их.
- 2.2 - Почему для ssh-клиента установлен setuid root?
- 2.3 - Почему SSH 2.3 и OpenSSH 2.1.1 вместе работают некорректно?
- 2.4 - Почему я получаю сообщение об ошибке "dispatch protocol error: type 20"?
- 2.5 - Старая версия коммерческой SSH шифрует host-ключи при помощи IDEA.
- 2.6 - Что означают эти предупреждения о длине ключа?
- 2.7 - X11 и/или агент-переадресации не работают.
- 2.8 - После обновления OpenSSH не работает поддержка SSH2.
- 2.9 - sftp/scp не устанавливают соединение, хотя ssh работает нормально.
- 2.10 - Будет ли добавлена [foo] в scp?
- 2.11 - Как использовать перенаправление портов (port forwarding)?
- 2.12 - Мое SSH-соединение зависает или обрывается после N минут бездействия.
- 2.13 - Как я могу использовать scp для копирования файлов, в имени которых есть двоеточие?
- 2.14 - Почему OpenSSH показывает свою версию клиенту?
3.0 - Вопросы по поводу портированной версии OpenSSH
- 3.1 - Стрaнные сообщения в лог-файлах по поводу PAM-аутентификации.
- 3.2 - Не допускается использование пустых паролей при PAM-аутентификации.
- 3.3 - ssh(1) нужно много времени, чтобы подключиться или войти в систему.
- 3.4 - Сообщение "Can't locate module net-pf-10" в лог-файлах Linux.
- 3.5 - Не работает аутентификация при использовании пароля (например, на Slackware 7.0 или Red Hat 6.x)
- 3.6 - Configure или sshd(8) жалуются на отсутствие поддержки RSA или DSA.
- 3.7 - Ошибка "scp: command not found".
- 3.8 - Passphrase не может быть прочитана.
- 3.9 - Нет 'configure' или поломан "make"
- 3.10 - ssh зависает при выходе
- 3.11 - Почему происходит зависание ssh при выходе?
- 3.12 - X11 forwarding перестал работать после обновления OpenSSH до версии 3.1.
- 3.13 - После обновления перестали работать некоторые X11 программы.
- 3.14 - После добавления открытого ключа (public key) в authorized_keys авторизация все равно не работает.
- 3.15 - Версии OpenSSH и поведение PAM (Pluggable Authentication Modules)
- 3.16 - Почему "w" или "who" на AIX 5.x не показывает пользователей, вошедьших в систему через ssh?
Проект OpenSSH включает в себя ssh(1), которая заменяет rlogin и telnet, и scp(1), которая заменяет rcp(1) и ftp(1). В OpenSSH также добавленны sftp(1) и sftp-server(8), которые обеспечивают простую передачу файлов. Это основано на secsh-filexfer IETF проекте.
OpenSSH состоит из следующих программ:
Самая последняя версия OpenSSH включена в текущий дистрибутив OpenBSD (устанавливается как часть базовой системы).
Сегодня большинство других операционных систем включают некоторые версии OpenSSH, так что большинство пользователей могут сразу же ее использовать. Однако, иногда включаются довольно старые версии, которые могут не поддерживать последние функции OpenSSH. В этом случае вы можете установить текущую версию в используемой вами операционной системе, даже если последняя версия не поддерживается дистрибьютером. Вы также можете использовать OpenSSH во встроенных приложениях.
Пользователи других операционных систем должны загрузить и собрать (compile and install) мультиплатформенную портированную версию с наших зеркал.
OpenSSH это набор инструментов для обеспечения безопасных сетевых подключений. Вот список поддерживаемых возможностей:
В настоящее время почти все системы связи в компьютерных сетях не шифруются. Как следствие, любой, кто имеет доступ к компьютеру, подключенному к сети, может подключиться к любому каналу связи. Это делают хакеры, любопытные администраторы, работодатели, преступники, шпионы (промышленный шпионаж), а также правительство. В следствии электромагнитного излучения, данные из некоторых каналов связи могут быть перехваченны даже на расстоянии.
Когда вы входите в систему (логинитесь), пароль передается по сети в виде обычного текста. Таким образом, любой "слушатель" может использовать ваш аккаунт (учетную запись), чтобы делать, что захочет. Это происходит постоянно по всему миру. Крэкеры запускают программы на рабочих станциях без ведома их владельцев, просто прослушивают сеть и собирают пароли. Программ для этого полным-полно в интернете, или они могут быть написанны компетентным программистом в течение нескольких часов
Компании имеют коммерческие тайны, патентные заявки, информацию о ценах, данные о клиентах, данные о персонале, финансовую информацию и т.д. В настоящее время любой человек с доступом к сети (с любого компьютера в сети) может слушать все, что происходит в интернет.
Многие компании не знают, что информация может быть так легко вытянута из сети. Они верят, что их данные надежно защищены, поскольку никто не знает, что они передают конфиденциальную информацию, или просто потому, что так много другой информации передается через сеть. Это не самый лучший подход к политики информационной безопасности.
Несмотря на то, что OpenSSH разрабатыватеся главным образом на OpenBSD, существует много портов и для других ОС. Проект портированной версии OpenSSH возглавляет Damien Miller. Загляните на страницу http://www.openssh.com/portable.html для знакомства с этой версией OpenSSH. В список поддерживаемых ОС входят:
Список дистрибьютеров, которые включают OpenSSH в свои системы, вы можете найти на этой странице.
Разработчики стараются сохранить OpenSSH без какихо-либо патентых или авторских проблем. Чтобы оставаться свободной для всех, поддержка некоторых функций не может быть включена в OpenSSH (например, поддержка запатентованных алгоритмов шифрования).
OpenSSH не поддерживает никаких патентованных алгоритмов транспортного уровня. При использовании SSH1 доступны только 3DES и Blowfish. При использовании SSH2 вы можете использовать только 3DES, Blowfish, CAST128, ArcFour и AES. Запатентованный алгоритм IDEA естественно не поддерживается.
OpenSSH обеспечивает поддержку протоколов SSH1 и SSH2.
С тех пор как патент на RSA истек, нет никаких ограничений на использование RSA-алгоритма, включая OpenBSD.
Есть много мест, где можно получить помощь. В дополнение к основному сайту OpenSSH, существует множество списков рассылки. Прежде чем слать письма с вопросами, поищите пожалуйста ответ в архиве рассылки. Существует большая вероятность того, что этот вопрос уже обсуждался, и ответ на него давно уже найден. Письма из рассылки находится в архиве, а чтобы поиск по нему был еще проще, существует система marc.info.
Для получения дополнительной информации о списках рассылки проекта OpenSSH, загляните на эту страницу.
Информацию об отправке багрепортов (сообщений об ошибках) вы можете найти на старнице Как сообщить об ошибке в OpenSSH.
Если вы хотите сообщить об ошибке так или иначе связанной с безопасностью, свяжитесь с разработчиками через рассылку openssh@openssh.com.
Клиент OpenSSH использует низкие номера портов для rhosts- и rhosts-rsa-аутентификации, поскольку сервер "доверяет" имени пользователя, предоставленным клиентом. Чтобы обойти это, вы можете добавить в ssh_config- или ~/.ssh/config-файлы эту строку:
UsePrivilegedPort no
Или вы можете использовать параметр -o во время запуска ssh(1) из консоли:
$ ssh -o "UsePrivilegedPort no" host.com
Как мы только что сказали в вопросе 2.1, чтобы иметь возможность использовать низкие номера портов для rhosts-аутентификации, OpenSSH необходимы права root. Использование привилегированных портов (с низкими номерами) также требуется для rhosts-rsa-аутентификации в более старых версиях SSH.
Кроме того, для rhosts-rsa-аутентификации (в первой версии протокола)
и hostbased-аутентификации (во второй версии), SSH-клиенту необходим
доступ к секретному ключу (private host key) для проверки подлинности
клиентской машины на сервере. Для этого OpenSSH (версии 3,3 и более ранние)
нужен установленный setuid root для файла ssh.
В принципе, если вы не собираетесь использовать эти методы аутентификации,
вы можете убрать его.
Начиная с OpenSSH версии 3.3, для файла ssh setuid-бит
не установлен по умолчанию. Связанно это с тем, что
ssh-keysign, который используется для доступа к приватному ключу
(private hosts keys), и ssh не используют привилегированных портов (портов
с низкими номерами) по умолчанию. Если вы хотите использовать
привилегированный порт, вы должны вручную установить setuid-бит для
ssh.
SSH версии 2.3 (и более ранние) имеет проблему с реализацией HMAC. Их код не поставляет полный блок данных из digest, а вместо этого всегда предоставляет 128 бит. Если же используются более длинные digests, то это приводит к конфликтам SSH 2.3 и OpenSSH.
OpenSSH 2.2.0 видит, что SSH 2.3 имеет эту проблему. В последних версиях SSH эта ошибка исправлена. Если же вы по той или иной причине используете SSH 2.3, то просто добавьте в /etc/sshd2_config эту строчку:
Mac hmac-md5
Были замечены проблемы взаимодействия, и причиной тому является отсутствие поддержки "session rekeying" в старых версиях OpenSSH. Однако коммерческие реализации SSH 2.3 договорились по поводу поведения работы этой функции, что и приводит таперь либо к потери связи, либо к ошибке Dispatch protocol error: type 20 . Чтобы решить эту проблему, обновитесь до последней версии OpenSSH, или отключите поддержку "session rekeying", добавив следующие строки в конфиг файлы (ssh2_config или sshd2_config) вашего SSH 2.3:
RekeyIntervalSeconds 0
Старые версии SSH использовали запатентованный алгоритм для шифрования /etc/ssh/ssh_host_key. Это привело к проблеме, которая заключатеся в том, что sshd(8) не может прочитать хост-ключ (host key). Чтобы решить эту проблему, воспользуйтесь командой, которая сконвертирует ваши ssh_host_key с целью использования 3DES. ПРИМЕЧАНИЕ: Используйте ssh-keygen(1) из коммерческой SSH-реализации, а *НЕ* из OpenSSH, как в примере ниже.
# ssh-keygen -u -f /etc/ssh/ssh_host_key
Коммерческая ssh-keygen(1) содержала ошибку, из-за которой он время от времени генерировал ключи для аутентификации (RSA или DSA), которые не устанавливали (unset) по умолчанию Most Significant Bit (MSB). Такие ключи рекламировались как ключи во всю длину (full-length), но на самом деле они были в 2 раза короче.
OpenSSH будет выводить предупреждения при обнаружении таких ключей. Чтобы избавить себя от этих сообщений, отредактируйте свой known_hosts и замените неправильную длину ключа (обычно это 1024) на правильную (1023).
Проверьте ваши ssh_config и sshd_config. Файлы конфигурации по умолчанию отключают агента аутентификации и X11-перенаправление (X11 forwarding). Чтобы включить ее, добавьте следующее в sshd_config:
X11Forwarding yes
а эти строки добавьте в ssh_config:
ForwardAgent yes
ForwardX11 yes
Для X11-перенаправления требуется рабочий бинарник xauth(1). В OpenBSD он входит в набор файлов xbase, но, вероятно, в других системах нужен будет другой пакет. Для портированной версии OpenSSH xauth долен быть либо найден во время установки/конфигурации или указан с помощью XauthLocation в sshd_config(5) и ssh_config(5).
По поводу агентов: есть два разных и несовместимых агента, ускоряющих механизмы работы протокола SSH2. OpenSSH всегда использовал расширение оригинальных запросов SSH1-агента, однако некоторые коммерческие продукты используют другой, закрытый (non-free) протокол перенаправления. Это значит, что агент перенаправления не может быть использован между OpenSSH и этими продуктами.
ПРИМЕЧАНИЕ: Для пользователей Linux Mandrake 7.2: Mandrake менят переменную XAUTHORITY из файла /etc/skel/.bashrc и таким образом домашний каталог любого Bash-пользователя в системе. Эта переменная меняет поведение OpenSSH и для любой из вышеперечисленных вариантов, если вы хотите получить рабочую систему, раскомментируйте строку:
# export XAUTHORITY=$HOME/.Xauthority
Файлы конфигурации sshd_config или ssh_config могут меняться от версии к версии. Вы всегда должны проверять эти файлы при обновлении OpenSSH. После 2.3.0 версии OpenSSH вам нужно добавить следующие строки в ваш sshd_config:
HostKey /etc/ssh_host_dsa_key
HostKey /etc/ssh_host_rsa_key
Используя sftp и/или scp связь может оборваться, если у вас есть shell-конфиг (.profile, .bashrc, .chsrc etc.), который показывает вывод и не интерактивных shell-сеансов (non-interactive sessions). Этот вывод и является причиной проблемы. Проверить настройки вашего shell можно этой командой:
ssh yourhost /usr/bin/true
Если эта команда что-то выводит, вы должны изменить настройки вашей shell-оболочки.
Короткий ответ: нет.
Длинный ответ: scp не стандартизирован. В спецификации указывается, что именно "делает rcp". Так как команда используется на обоих концах соединения, то добавление новых функций или опций является риском нарушения совместимости с другими реализациями.
Практически вся функциональность, которую мы хотели реализовать, уже добавленна в sftp. Протокол, на основе которого создается реализация, стандартизован, поэтому изменение в реализации может отразиться и на совместимости клиента с сервером.
Если удаленный сервер работает под управлением sshd(8), то вы можете построить 'туннель' через ssh. Например, это неплохая идея использовать туннель для небезопасных POP или SMTP соединений (даже если программное обеспечение не поддерживает работу с зашифрованными каналами связи). Туннелирование использует перенаправление портов, чтобы создать соединение между клиентом и сервером. Клиентское программное обеспечение должно иметь возможность использовать нестандартный порт для подключения.
Идея состоит в следующем: пользователь подключается к удаленному компьютеру (через ssh) и указывает порт, который должен быть использован на клиентской машине для переадресации подключения к серверу. После этого, на клиентской машине можно запустить сервис, соединение с которым должно быть зашифровано (например, Fetchmail, IRC), указав тот же локальный порт. Соединение, настроенное таким образом, будет ничем иным как туннелем через ssh. По умолчанию, соединение будут обслуживать запросы только от этого пользователя.
Самые важные опции для настройки туннелирования являются -L и -R, которые позволяют пользователю создать соединение; -D, которая позволяет использовать динамическое перенаправление портов; -g, которая позволяет другим хостам использовать это соединение/порт; -F, которая запускает ssh в фоновом режиме после авторизации. Для получения более подробной информации ознакомьтесь с man-страницей ssh(1).
Это пример туннелирования IRC-сеанса связи от клиента с адесом 127.0.0.1 (localhost) с удаленным сервером "server.example.com":
ssh -f -L 1234:server.example.com:6667 server.example.com sleep 10
irc -c '#users' -p 1234 pinky 127.0.0.1
Соединение, созданное в этом примере, является туннелем подключения к IRC-серверу "server.example.com", каналу "#users", используя ник "pinky". Локальный порт, используемый в данном примере, - 1234. Не имеет значение какой именно порт используется, если этот порт больше 1023 (не забывайте, что только root может создавать соединения используя для этого привилегированные порты), и он не конфликтует с любым другим портом, который уже используется. Соединение будет передано на порт 6667 на удаленном сервере, так как это стандартный порт для IRC.
Команда "sleep 10" используется для задержки перед созданием/установкой туннеля. Дело в том, что если в течении определенного времени никаких соединений созданно не будут, то ssh будет закрыт (ssh will exit). Если требуется больше времени (более длинная задержка), значение, передаваемое sleep(1), можно увеличить. Для более подробной информации о функциях, доступных в вашем shell, смотрите ksh(1) и csh(1).
ssh также имеет опцию -N, которую удобно использовать для переадресации портов: если -N не указано, то нет необходимости указывать удаленные команды ("sleep 10" в нашем примере). Однако, использование этой опции заставляет ssh ждать (в отличие от выхода после того, как удаленная команда будет завершена), и пользователь должен позаботиться, чтобы вручную завершить (kill(1)) процесс впоследствии.
Как правило, причиной тому может являться пакетный фильтр PF или NAT-устройство, которые "timing out" ваше TCP-соединение из-за неактивности. Вы можете включить ClientAliveInterval в sshd_config (на стороне сервера), или ServerAliveInterval в ssh_config (клиентская сторона) (последний доступен в OpenSSH версии 3.8 и более новых).
Включение того или иного варианта и настройка интервала меньше, чем время, необходимое для тайм-аута сеанса, гарантирует, что связь не оборвется по этой причине.
$ scp ./source:file sshserver:
OpenSSH, как и большинство реализаций SSH, показывает при подключении клиенту свое название и версию, например:
SSH-2.0-OpenSSH_3.9
Эта информация используется клиентом и сервером с целью установки соединения, использующего совместимые протоколы, т.е. чтобы избежать различий в реализации, багов или просто отсутствующих возможностей. Эта функция проверки протоколов нужна для проверки совместимости версий, потому что старые версии, не поддерживающие многие возможности, реализованные в последних версиях, все еще широко используются.
Портированная версия OpenSSH будет генерировать ложные сообщения о неудачной попытке аутентификации при каждом входе, похожие на:
"authentication failure; (uid=0) -> root for sshd service"
Они создаются по причине того, что OpenSSH сначала пытается определить, должен ли пользователь аутентифицироваться для входа в систему (например, пустой пароль). К сожалению PAM любит регистрировать все события, связанные с аутентификацией, и это сообщение не является исключением.
Если это вас раздражают эти сообщения, или их просто слишком много, установите "PermitEmptyPasswords no" в sshd_config. Это отключит регистрацию ошибок по поводу входа в систему, если пароль не установлен. Это значение установленно по умолчанию, если вы используете прилагаемый файл sshd_config.
Чтобы разрешить использование пустых паролей при PAM-аутентификации необходимо добавить флаг "nullok" в конец "password checking module" в файл /etc/pam.d/sshd. Например:
auth required/lib/security/pam_unix.so shadow nodelay nullok
Это должно быть сделано в дополнение к установке "PermitEmptyPasswords yes" в файле sshd_config.
Существует одно предостережение по поводу использования пустых паролей PAM-аутентификации: будет разрешен любой пароль для аутентификации той или иной учетной записи с пустым паролем. Это сломает проверку, которую использует sshd(8), чтобы определить, установлен ли для этого аккаунта пароль вообще, независимо от политики, определенной с помощью PermitEmptyPasswords. По этой причине, рекомендуется не добавлять nullok-директиву в ваш конфигурационный файл, если вы не хотите использовать пустые пароли.
Большие задержки (более 10 секунд), как правило, вызваны проблемами с разрешением имен:
nslookup, чтобы
проверить это, узнав имя машины на другом конце соединения и её IP-адрес.
Вы можете отключить значительную часть поиска (на стороне сервера), задав
UseDNS no в sshd_config.Задержки менее 10 секунд могут иметь другие причины.
ssh, которая
заключалась в том, что загружалось больше модулей, чем было нужно
(в купе с вышеуказанной проблемой это приводило к еще большему
затормаживанию работы). Обновление клиента до версии 3.8 или выше должно
решить эту проблему.ssh-rand-helper программ, ответсвенных за создание
энтропии, висит. Это можно проверить, запустив её в debug-режиме:
Причина всех важных/значительных задержек в работе должны быть определены и устранены, или соответствующие команды должны быть удалены из ssh_prng_cmds.
/usr/local/libexec/ssh-rand-helper -vvv
time ssh localhost true, при использовании
1024-битного RSA-ключа. OpenSSH и OpenSSL были собраны при помощи gcc 3.3.x.
| CPU | Время (SSHv1)[1] | Время (SSHv2) |
|---|---|---|
| 170MHz SPARC/sun4m | 0.74 сек | 1.25 сек |
| 236MHz HPPA/8200[2] | 0.44 сек | 0.79 сек |
| 375MHz PowerPC/604e | 0.38 сек | 0.51 сек |
| 933MHz VIA Ezra | 0.34 сек | 0.44 сек |
| 2.1GHz Athlon 2600+ | 0.14 сек | 0.22 сек |
Ядро Linux пытается подключить (при помощи modprobe) модуль, для семейства протоколов 10 (IPv6). Либо загрузите соответствующий модуль ядра, добавив адрес к модулю в файл /etc/modules.conf, или отключите IPv6 в /etc/modules.conf.
По непонятным причинам файл /etc/modules.conf может называться /etc/conf.modules.
Если пароль правильный, но войти в систему все равно не получается, скорее всего дело в том, что система настроена на использование MD5-типа паролей, но crypt(3)-функция, используемая sshd, не понимает их.
Информация о таких учетных записях в файлах /etc/passwd или /etc/shadow будет начинаться с $1$. Если сбой аутентификации (проверки подлинности пароля) просходит для новых учетных записей, или для которых недавно был изменен пароль, но при этом старые учетные записи будут работать по-прежднему (пользователи по-прежднему могут входить в систему без проблем), то это (использование MD5-типа паролей) скорее всего и является причиной проблемы.
Основной причиной являются некоторые версии OpenSSL, которые используют crypt(3)-функции, которые не понимают MD5-пароли. Можно попоробовать настроить OpenSSH, но не всегда эти попытки являются успешными.
Итак, есть несколько вариантов решений:
Включение поддержки MD5-паролей в процессе сборки sshd.
Тут не должно возникнуть никаких проблем, даже если вы используете оба типа шифрования: sshd будет выбрать правильный алгоритм для каждой учетной записи автоматически.
./configure --with-md5-passwords [Optionen]
Если ваша система имеет отдельную libcrypt-библиотеку (какую имеет, к примеру, седьмая версия Slackware), то вы можете вручную добавить -lcrypt к LIBS-списку, что приведет к её использованию вместо OpenSSL:
LIBS=-lcrypt ./configure [Optionen]
Если ваша платформа поддерживает PAM, то вы можете настроить sshd использовать его (см. раздел 3.15). Это значит, что демон не будет проверять пароли сам, а будет перекладывать эту работу на настроенные PAM-модули.
Убедитесь, что ваша OpenSSL-библиотека была собрана с поддержкой RSA или DSA (внутренне или при помощи RSAREF).
scp(1) должена быть в стандартном PATH-пути по умолчанию на клиенте и сервере. Возможно, вам придется использовать опцию --with-default-path для поиска пути на сервере. Эта опция перезаписывает PATH, который используется по умолчанию, поэтому вам нужно указать все текущие каталоги на вашем пути, как и где вы установили scp. Например:
$ ./configure --with-default-path=/bin:/usr/bin:/usr/local/bin:/path/to/scp
Обратите внимание, что конфигурация администратора сервера будет иметь более высокий приоритет, чем изменения при помощи опции --with-default-path. Это будет включать в себя PATH в /etc/profile, PATH в /etc/environment в AIX, или (для 3.7p1 и выше) установка PATH или SUPATH в /etc/default/login в Solaris или Reliant Unix.
В некоторых ОС устанавлен неправильный режим для /dev/tty, в результате чего чтение паролей происходит неправильно, и мы получаем следующую ошибку:
You have no controlling tty. Cannot read passphrase.
Решением этой проблемы будет перенастройка /dev/tty в режим 0666, а также написание отчета об ошибке дистрибьютеру вашей ОС.
Если в архиве, который вы скачали, нет 'configure'-файла, или "make" при попытке сборки выдает ошибку "missing seperator", вы, вероятней всего, скачали OpenSSH версию для OpenBSD и пытается скомпилировать её на другой платформе. Пожалуйста, загляните на страницу портированной версии.
OpenSSH может зависнуть при выходе. Это может произойти, когда запущен активный процесс в фоновом режиме. Это, как известно, происходит в Linux и HP-UX. Проблема может быть проверена, выполнив следующие действия:
Попробуйте использовать вместо этого:
$ sleep 20 & exit
$ sleep 20 < /dev/null > /dev/null 2>&1 &
Решением этой проблемы для bash-пользователей будет добавление "shopt -s huponexit" в /etc/bashrc или ~/.bashrc. В противном случае, обратитесь к man-странице вашей shell-оболочки, чтобы выяснить как включить отправку HUP-сигнала для активации запущенных процессов. См. bug #52, где описываются некоторые другие обходные пути.
При запускке
ssh должен зависнуть, потому что он ожидает некоторую информацию от запущенного процесса. Другими словами, ssh зависает:
$ ssh host command
command не ожидает никаких
других опций (not need more input).
command не будет больше
ничего выводить (not produce more output).
command не завершится, потому что sshd нужно знать
значение (exit status), которое вернет command ssh.
Вообще, X11-клиенты, использующие X11 R6, должны работать с настройками по умолчанию. Некоторые производители, включая HP, используют X11-клиены с R6- и R5-библиотеками, поэтому некоторые клиенты будут работать, а некоторые нет. Это также касается и HP-UX 11.X.
Как указано в информации к релизу 3.8,
ssh теперь использует "untrusted X11 cookies" по умолчанию.
Его предыдущее поведение может быть восстановлено путем установки опции
ForwardX11Trusted yes в файле sshd_config.
Возможные ошибки, связанные с этим:
BadWindow (invalid Window parameter)
BadAccess (attempt to access private resource denied)
X Error of failed request: BadAtom (invalid Atom parameter)
Major opcode of failed request: 20 (X_GetProperty)
Обычно это связано с правами доступа к файлам в $HOME, $HOME/.ssh или $HOME/.ssh/authorized_keys, которые более "доступные", чем sshd позволяет по умолчанию.
В этом случае, это может быть решено при помощи выполнения следующих команд на сервере.
$ chmod go-w $HOME $HOME/.ssh
$ chmod 600 $HOME/.ssh/authorized_keys
$ chown `whoami` $HOME/.ssh/authorized_keys
Если это невозможно по той или иной причине, то альтернативым методом будет добавление StrictModes no в файл sshd_config, однако к этому методу прибегать не рекомендуется.
Для полноценного использования PAM, эта опция должна быть использована во время сборки. Поведение во время выполнения, при сборке с PAM, варьируется в зависимости от версии портированных OpenSSH, а в более поздних версиях она также должна быть включена установкой опции UsePAM как yes в файле sshd_config.
./configure --with-pam [Optionen]
Поведение соответствующих вариантов аутентификации PAM (при включении её поддержки во время сборки) кратко показано в следующей таблице.
| Версия | UsePAM | PasswordAuthentication | ChallengeResponseAuthentication |
|---|---|---|---|
| <=3.6.1p2 | Не поддерживается | Используется PAM | Используется PAM, если включена PAMAuthenticationViaKbdInt |
| 3.7p1 - 3.7.1p1 | По умолчанию - yes | Не используется PAM | Используется PAM, если включена UsePAM |
| 3.7.1p2 - 3.8.1p1 | По умолчанию - no | Не используется PAM [1] | Используется PAM, если включена UsePAM |
| 3.9p1 | По умолчанию - no | Используется PAM, если включена UsePAM | Используется PAM, если включена UsePAM |
[1] Некоторые дистрибьютеры, такие как например RedHat/Fedora, перенесли PasswordAuthentication из версии 3.9p1 в свой 3.8x пакет. Если вы используете пакет, предоставленный тем или иным дистрибьютером, ознакомьтесь с документацией касательно используемых им опций по умолчанию.
Портированная версия OpenSSH все еще имеет проблемы с некоторыми PAM-модулями, однако мы надеемся, что в будущем ситуация улучшится. На момент 3.9p1-релиза известными проблемами являются:
www@openbsd.org