Конфигурирование DB2 Universal Database для UNIX для использования OpenSSH

Опции документа Опции документа, требующие включения JavaScript, не отображаются Обсудить Выскажите мнение об этой странице Помогите нам улучшить содержание

Уровень сложности: средний

Лайам Финни, разработчик ПО для DB2 UDB, IBM Toronto Labs

19.08.2009

До выхода IBM® DB2® Universal Database™, Version 8.2.2 (Version 8, FixPack 9) СУБД DB2 UDB для UNIX®-платформ с доступной для использования функциональностью для разбиения данных (Data Partitioning Feature - DPF) неявно зависела от rsh, которая служила оболочкой удаленного доступа при выполнении команд на удаленных узлах DB2. Это ограничение было смягчено путем введения новой переменной регистра DB2, названной DB2RSHCMD. Эта переменная позволяет администратору базы данных задавать полное имя оболочки удаленного доступа, которую DB2 будет использовать. OpenSSH является бесплатной реализацией набора инструментов ssh (secure shell) с открытым исходным кодом и представляет собой защищенную альтернативу комплекту инструментов rsh. В этой статье описано, как настроить OpenSSH 3.8p1 (другие версии ssh могут использовать незначительно отличающийся синтаксис) для ее использования экземпляром DB2 UDB DPF.

Предварительные знания

Для выполнения команд на удаленных узлах в экземплярах DB2 UDB DPF, работающих под управлением ОС UNIX, требуется оболочка удаленного доступа. Например, при начале или завершении выполнения экземпляра DPF (db2start/db2stop) для отправки команды включения/выключения каждому узлу в данном экземпляре (независимо от того, находится ли узел на том же самом или на отдельном компьютере) используется оболочка удаленного доступа. Далее, администратор базы данных может решить выполнить некоторую команду на удаленных узлах в экземпляре DPF, используя при этом утилиты db2_all или rah. Для работы этих утилит также требуется оболочка удаленного доступа. Чтобы в качестве оболочки удаленного доступа для экземпляра DB2 UDB DPF можно было использовать OpenSSH, ее нужно сконфигурировать особым образом. Идентификатор пользователя (учетная запись владельца в дальнейшем), владеющего текущим экземпляром DB2, должен присутствовать на каждом хосте экземпляра, принадлежащего этому владельцу. Это позволит владельцу экземпляра DB2 входить на любой другой компьютер, принадлежащий своему экземпляру DB2 UDB DPF, без ввода дополнительной удостоверяющей информации (например, пароля).

В этой статье описывается способ настройки OpenSSH для централизованной (host-based) аутентификации и для аутентификации, основанной на открытом ключе (public key-based) для операционных систем AIX, Linux™, Solaris и HP-UX. По ходу процесса настройки мы будем полагать, что экземпляр DB2 UDB DPF сконфигурирован для работы на двух различных компьютерах (на каждом компьютере может быть любое количество узлов DB2), называемых machineA и machineB. Мы также предположим, что полные имена наших компьютеров – это machineA.my.domain.com и machineB.my.domain.com, а их IP-адреса будут, в целях упрощения, 1.1.1.1 для machineA, и 1.1.1.2 для machineB. Мы также предположим, что OpenSSH уже установлена и демон-процесс ssh (sshd) настроен таким образом, что начинает свою работу при запуске системы, и что для каждого компьютера уже сгенерированы открытые и закрытые ключи.

В начало

Сравнение централизованной аутентификации с аутентификацией на основе открытого ключа

Оба типа аутентификации с использованием ssh - централизованная и на основе открытого ключа - являются более безопасными, чем rhost-аутентификация, использующая rsh. При централизованной аутентификации с использованием ssh станции должны установить доверительные отношения, после чего пользователь, использующий свою учетную запись, сможет входить на любые другие сконфигурированные компьютеры, принадлежащие текущему экземпляру DB2. Это может быть удобно в случае, если несколько экземпляров DB2 выполняются на одной и той же группе компьютеров. Негативной стороной этого подхода является то, что при взломе любой учетной записи пользователя на любом доверенном компьютере эта запись оказывается взломана и на всех остальных хостах текущего экземпляра DB2. При помощи этой записи можно будет входить без ввода пароля (с использованием ssh) на любые другие доверенные компьютеры. (Это может стать источником проблемы в случае, если для одного экземпляра DB2 сконфигурировано много пользователей, но лишь очень немногим из них нужно входить без ввода пароля, используя ssh, на другие компьютеры в рамках одного экземпляра DB2 .) При аутентификации на основе открытого ключа только избранный пользователь будет сконфигурирован таким образом, чтобы он мог входить без пароля на другие станции, поэтому в данном случае меньше угроз для безопасности. Также для настройки аутентификации на базе открытого ключа не нужны полномочия пользователя root (на некоторых этапах настройки централизованной аутентификации требуется использовать доступ из-под учетной записи root). Так как для экземпляров DB2 UDB DPF нужно, чтобы домашний каталог владельца этого экземпляра был распределен по всем компьютерам, аутентификация на основе открытого ключа довольно проста. Несмотря на то, что оба этих метода аутентификации более безопасны, чем rhost-аутентификация, использующая rsh, необходимо выбрать метод, который наиболее удовлетворяет выдвигаемым требованиям обеспечения безопасности.

В начало

Методы шифрования, доступные в OpenSSH

OpenSSH поддерживает шифрование по алгоритму DSA (Digital Signature Algorithm) и RSA (Rivest-Shamir-Adleman). В Интернете есть литература, в которой обсуждаются "за" и "против" обоих методов шифрования. Также в Интернете можно найти различные точки зрения на то, какой алгоритм шифрования лучше. В конце концов следует использовать тот алгоритм шифрования, который удовлетворяет требованиям безопасности. Ниже в статье описано, как сконфигурировать OpenSSH с использованием обоих методов шифрования для каждого из следующих способов аутентификации:

• Централизованная аутентификация
• Аутентификация на основе открытого ключа

Вне зависимости от того, какой метод шифрования и аутентификации будет использоваться, убедитесь, что применяется протокол SSH Version 2 (используется по умолчанию в OpenSSH 3.8p1), поскольку он более безопасен, чем Version 1.

В начало

Централизованная аутентификация

Централизованная аутентификация, использующая ssh, позволяет любому пользователю (учетной записи пользователя) с machineA использовать ssh для входа с той же учетной записью на machineB; при этом мы предполагаем, что ssh-клиент на machineA настроен для использования централизованной аутентификации и ssh-сервер на machineB настроен таким образом, что разрешает использование централизованной аутентификации. Чтобы в экземпляре DB2 UDB DPF можно было использовать централизованную аутентификацию, каждый компьютер в этом экземпляре должен иметь правильно настроенный ssh-клиент и ssh-сервер. Мы начнем с конфигурации ssh-сервера и продолжим рассмотрением конфигурации ssh-клиента.

В начало

Конфигурация ssh-сервера при централизованной аутентификации

Конфигурационным файлом ssh-сервера является файл sshd_config; в AIX, Linux и Solaris этот файл находится в каталоге /etc/ssh. В HP-UX sshd_config находится в каталоге /opt/ssh/etc. Чтобы изменить этот файл и применить сделанные изменения к выполняющемуся процессу sshd, необходимы полномочия пользователя root. Откройте в редакторе файл sshd_config, найдите строку HostbasedAuthentication no и обновите файл, как показано ниже:

#   HostbasedAuthentication no
HostbasedAuthentication yes

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

Это изменение файла sshd_config позволит ssh-серверу принимать запросы централизованной аутентифкации от ssh-клиентов. Однако использование централизованной аутентификации разрешено только между двумя доверенными компьютерами. Доверие основано на двух критериях:

1. Компьютер с ssh-сервером должен иметь запись о компьютере-клиенте в файле shosts.equiv. Этот файл находится в каталоге /etc/ssh в AIX и Linux, в каталоге /etc в Solaris и в каталоге /opt/ssh/etc в HP-UX. Если этот файл не существует, его надо создать и убедиться, что он принадлежит администратору, пользователи имеют доступ на чтение/запись в этот файл, а группа/остальные пользователи (group|other) имеют доступ на чтение (режим "644"). Так как каждый компьютер должен быть способен соединяться с любым другим компьютером в экземпляре DB2 UDB DPF, настроим файл shosts.equiv таким образом, чтобы его можно было использовать и на всех остальных компьютерах. Итак, файл shosts.equiv будет выглядеть примерно так:

   
   
   Листинг 2. shosts.equiv
   

   machineA machineA.my.domain.com machineB machineB.my.domain.com

   
   
   

2. Компьютер с с ssh-сервером должен иметь доступ к открытому ключу компьютера с ssh-клиентом. При централизованной аутентификации механизм проверки ищет общие ключи в файле ssh_known_hosts, который находится в каталоге /etc/ssh в AIX, Linux и Solaris и в каталоге /opt/ssh/etc в HP-UX. Если этот файл не существует, его надо создать и убедиться, что владеет им пользователь root, для обычных пользователей доступны только режимы доступа для чтения/записи, а для группы/других пользователей предусмотрен только режим доступа на чтение (режим "644"). Найдите на компьютере с ssh-клиентом в каталоге /etc/ssh (или /opt/ssh/etc для HP-UX) файл ssh_host_dsa_key.pub для DSA-шифрования (ssh_host_rsa_key.pub для RSA-шифрования) и откройте этот файл. Для DSA-шифрования содержимое файла должно быть похожим на ssh-dss <key>, а для RSA-шифрования - на ssh-rsa <key>, где <key> - открытый ключ компьютера, который обычно является очень длинной строкой. Теперь откройте файл ssh_known_hosts на компьютере ssh-сервера и добавьте в него имя клиентского компьютера (все возможные варианты через запятую: короткое имя, полное имя компьютера и IP-адрес), а затем содержимое открытого ключа компьютера с установленным ssh-клиентом. Итоговый файл ssh_known_hosts будет выглядеть следующим образом:

   
   
   Листинг 3. Файл ssh_known_hosts при использовании DSA-шифрования
   

   machineA,machineA.my.domain.com,1.1.1.1 ssh-dss <machineA's public DSA key> machineB,machineB.my.domain.com,1.1.1.2 ssh-dss <machineB's public DSA key>

   
   
   
   
   Листинг 4. Файл ssh_known_hosts для RSA-шифрования
   

   machineA,machineA.my.domain.com,1.1.1.1 ssh-rsa <machineA's public RSA key> machineB,machineB.my.domain.com,1.1.1.2 ssh-rsa <machineB's public RSA key>

   
   

   Добавляя ключи в файл ssh_known_hosts, необходимо следить, чтобы ключ каждого компьютера целиком находился на одной строке.

   Для упрощения этого процесса можно использовать утилиту ssh-keyscan, которая выбирает открытые ключи компьютеров. Вывод этой команды может быть присоединен к файлу ssh_known_hosts, как показано ниже:

   
   
   Листинг 5. Файл ssh_known_hosts с использованием DSA-шифрования
   

   $ cd /etc/ssh # cd /opt/ssh/etc on HP-UX $ ssh-keyscan -t dsa machineA,machineA.my.domain.com,1.1.1.1 >>ssh_known_hosts $ ssh-keyscan -t dsa machineB,machineB.my.domain.com,1.1.1.2 >>ssh_known_hosts

   
   
   
   
   Листинг 6. Файл ssh_known_hosts с использованием RSA-шифрования
   

   $ cd /etc/ssh # cd /opt/ssh/etc on HP-UX $ ssh-keyscan -t rsa machineA,machineA.my.domain.com,1.1.1.1 >>ssh_known_hosts $ ssh-keyscan -t rsa machineB,machineB.my.domain.com,1.1.1.2 >>ssh_known_hosts

   
   

Чтобы начать использовать новую конфигурацию ssh, процесс sshd должен заново обработать файл sshd_config. (Этот файл обрабатывается только при первом запуске демона ssh-сервера.) Для повторной обработки файла sshd_config нужно послать команду SIGHUP процессу sshd (ssh серверный демон-процесс). Это не повлияет на ssh-сессии, в данный момент выполняющиеся на компьютере – только на будущие сессии работы.

$ ps -ef | grep sshd
    root  430084  114790   0 19:25:07      -  0:03 /usr/sbin/sshd
    root 3424508 1147104   0 10:39:29  pts/5  0:00 grep sshd

Первая строка сообщает, что PID процесса /usr/sbin/sshd равняется 430084. Чтобы повторно обработать конфигурационный файл для регистрации sshd-процесса, необходимо ввести команду:

$ kill -HUP 430084

$ /etc/init.d/sshd restart

Эти шаги нужно выполнить на всех компьютерах в экземпляре DB2 UDB DPF. В результате одна и та же конфигурация ssh-сервера будет применена для всех узлов. Каждый компьютер должен иметь одну и ту же копию файлов sshd_config, shosts.equiv, и ssh_known_hosts. (После любого обновления конфигурационного файла не забудьте послать команду на его повторное считывание процессам sshd на каждом компьютере.)

Как только будет закончена настройка ssh-сервера, описанная выше, будут установлены доверительные отношения между machineA and machineB. Любой зарегистрированный пользователь с machineA сможет входить в ssh компьютера machineB под той же учетной записью пользователя (эта форма централизованной аутентификации не позволяет пользователю с одной учетной записью на одном компьютере войти в систему на другом компьютере под другой учетной записью). Однако настройка централизованной аутентификации еще не завершена, поскольку еще не настроен ssh-клиент.

В начало

Конфигурирование ssh-клиента при централизованной аутентификации

Конфигурационный файл ssh-клиента называется ssh_config (серверный конфигурационный файл называется sshd_config) и находится в каталоге /etc/ssh на AIX, Linux и Solaris и в /opt/ssh/etc на HP-UX. Откройте файл ssh_config, найдите строку # HostbasedAuthentication no, после чего обновите файл, как показано ниже:

#   HostbasedAuthentication no
HostbasedAuthentication yes

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

EnableSSHKeysign yes

Последняя строка (EnableSSHKeysign) уведомляет ssh-клиента о том, что для чтения закрытого ключа компьютера он должен использовать отдельную утилиту ssh-keysign. (Закрытые ключи должны принадлежать пользователю root, тогда как рядовой пользователь должен иметь доступ на чтение/запись.) В качестве альтернативного решения можно установить бит suid утилиты ssh, чтобы она исполнялась от имени root, но в целом безопаснее оставить права root только для ssh-keysign, так как ssh права root не нужны. Прежде чем продолжать далее, необходимо убедиться, что ssh-keysign установлена правильно. В ОС AIX файл должен находиться в каталоге /usr/sbin, однако он также может находиться и в каталоге /usr/bin. В последнем случае нужно скопировать файл в каталог /usr/sbin. В Red Hat Linux-системах этот файл (ssh-keysign) должен находиться в каталоге /usr/libexec/openssh/, в системах SUSE файл должен быть в каталоге /usr/lib[64]/ssh/. В Solaris файл ssh-keysign должен находиться в каталоге /usr/libexec. В HP-UX файл должен находиться в /usr/lbin. Также убедитесь, что файл отмечен как исполняемый от имени root:

$ ls -l /usr/sbin/ssh-keysign # use the appropriate path for your platform
  -rws--x--x   1 root     system       285183 Jun 29 2004  ssh-keysign*

Если права доступа и владелец не такие, как показано выше, скорректируйте их (в Solaris и HP-UX файл ssh-keysign должен принадлежать root:bin, а не root:system).

$ cd /usr/sbin  # replace /usr/sbin with the appropriate path for your platform
$ chown root:system ssh-keysign  # chown root:bin ssh-keysign on Solaris and HP-UX
$ chmod 4755 ssh-keysign

Теперь ssh-клиент сконфигурирован надлежащим образом для использования централизованной аутентификации. Далее нужно обновить конфигурацию ssh-клиента на всех остальных компьютерах экземпляра DB2 UDB DPF. Как только это будет сделано, можно переходить к "Конфигурации DB2."

В начало

Аутентифкация с открытым ключом

При использовании аутентификации с открытым ключом мы определяем всего одного пользователя (владельца экземпляра DB2 UDB DPF), который может входить под своей учетной записью на любой компьютер экземпляра без необходимости ввода пароля. Так как домашний каталог владельца экземпляра DB2 UDB DPF распространен по всем компьютерам (необходимое условие для экземпляра DB2 UDB DPF), можно полностью выполнить установку с одного компьютера. В этом примере мы будем использовать machineA. Войдите в систему на machineA под учетной записью владельца экземпляра DB2 UDB DPF. Если для данного пользователя еще не существует каталога ~/.ssh, нужно его создать. Проверьте, чтобы группа или другие пользователи не могли осуществлять запись в каталог .ssh. Также проверьте, чтобы группа или другие пользователи не могли осуществлять запись в домашний каталог используемой учетной записи (ssh видит в этом потенциальную опасность и не позволит использовать аутентификацию на базе открытого ключа, если права на доступ к каталогу недостаточно строги). Из вашего каталога ~/.ssh создайте пару открытый/закрытый ключ:

$ ssh-keygen -t rsa   # ssh-keygen -t dsa for DSA encryption

Всякий раз при появлении запроса на ввод нажимайте Enter для ввода значения по умолчанию. (Не вводите идентификационную фразу, иначе ssh будет при каждой попытке пользователя пройти аутентификацию требовать ее в качестве пароля – а DB2 не позволяет утилитам удаленного доступа запрашивать дополнительную проверку.) Эти действия создадут два новых файла в каталоге ~/.ssh: id_rsa (частный ключ) и id_rsa.pub (общий ключ) для RSA-шифрования, или id_dsa (частный ключ) и id_dsa.pub (общий ключ) для DSA-шифрования. Чтобы использовать эту новую пару ключей с ssh, нужно выполнить следующие шаги:

$ mv id_rsa identity                 # use id_dsa for DSA key pair
$ chmod 600 identity
$ cat id_rsa.pub >> authorized_keys  # use id_dsa.pub for DSA key pair
$ chmod 644 authorized_keys
$ rm id_rsa.pub                      # rm id_dsa.pub for DSA key pair

Настройка ssh-сервера не требуется, поскольку по умолчанию ssh, прежде чем использовать парольную аутентификацию, попытается использовать аутентификацию на основе открытого ключа. Поскольку между компьютерами не было сформировано доверительных отношений, в первый раз при входе через ssh на новый компьютер будет выведено сообщение о том, что подлинность указанного компьютера не может быть установлена, а затем будет выведено предложение продолжить работу. Это дополнительная функция безопасности ssh, позволяющая проверить, что ssh-соединение осуществляется с надлежащим компьютером (возможна ситуация, когда ваше ssh-соединение в попытке нарушить систему безопасности будут злонамеренно перенаправлено на другой компьютеру – атака путем "внедрения"). Вместо того чтобы формировать доверительные отношения, заходя на все компьютеры по очереди, можно использовать более легкий путь – утилиту ssh-keyscan для сбора открытых ключей каждого компьютера в экземпляре DB2 DPF.

$ ssh-keyscan -t rsa machineA,machineA.my.domain.com,1.1.1.1 >>~/.ssh/known_hosts
$ ssh-keyscan -t rsa machineB,machineB.my.domain.com,1.1.1.2 >>~/.ssh/known_hosts

$ ssh-keyscan -t dsa machineA,machineA.my.domain.com,1.1.1.1 >>~/.ssh/known_hosts
$ ssh-keyscan -t dsa machineB,machineB.my.domain.com,1.1.1.2 >>~/.ssh/known_hosts

Теперь настройка ssh-аутентификации на базе общего ключа завершена и можно переходить к конфигурированию DB2.

В начало

Конфигурирование DB2 для использования ssh в качестве оболочки удаленного доступа

Теперь, когда мы настроили ssh на использование одного из видов аутентификации, не требующего дополнительного подтверждения (пароля), надо проверить, что полученная конфигурация работает. Сначала проверим, может ли machineA через ssh выполнить простую команду на machineB. Войдите в machineA под учетной записью владельца текущего экземпляра DB2 UDB DPF и введите:

$ ssh machineB echo hi

Если в ходе этой проверки был запрошен пароль – значит, скорее всего, у вас используется аутентификация на основе открытого ключа и при создании пары открытого/закрытого ключей вы указали пароль. Изучите инструкции по настройке аутентификации на основе общего ключа и создайте новую пару открытый/закрытый ключ без пароля. Если после этих действий снова запрашивается пароль или возникли какие-то другие ошибки, обратитесь к разделу "Устранение неисправностей". Если команде требуется для возврата результатов больше одной-двух секунд, возможно, есть проблемы с разрешением имен в сети или проблемы с конфигурацией конкретной версии ssh. В обоих случаях поищите в Интернете и в документации по конфигурации локальной сети возможные причины проблем и их решение. Если же все прошло без ошибок, настало время известить DB2 о начале использования ssh для выполнения удаленных команд. Из-под учетной записи владельца текущего экземпляра DB2 UDB DPF на machineA введите:

$ db2set DB2RSHCMD=/usr/bin/ssh

Эта команда уведомляет DB2 о том, какую оболочку удаленного доступа использовать при выполнении внутренних команд DB2 на удаленных DB2-узлах (например, запуск удаленного DB2-узла командой db2start) и при выполнении посредством сценария db2_all команд на всех узлах DB2. Чтобы проверить, правильно ли сконфигурирована ssh на всех хостах экземпляра DB2 UDB DPF, можно попробовать следующую простую команду – получение эха от DB2 -узла:

$ db2_all echo hi

Если эта команда успешно завершит свою работу и не потребуется дополнительного ввода пароля, можно переходить к следующей проверке. В противном случае изучите раздел "$Устранение неисправностей." Последняя проверка подтведила, что текущий узел DB2 может подключиться при помощи ssh к другому узлу DB2. Также мы хотим убедиться, что любой DB2-узел может с использованием ssh подключиться к любому другому DB2-узлу. Выполним модифицированную версию последней команды:

$ db2_all db2_all echo hi

Результатом выполнения этой команды будет множество строчек. Если все DB2-узлы ответили без запроса дополнительной проверки, настройка DB2 для использования ssh в качестве оболочки удаленного доступа завершена. Теперь необходимо остановить сервер базы данных (db2stop) и перезапустить его (db2start), чтобы эти новые настройки подействовали на сервер DB2 (сделанные изменения немедленно повлияют на сценарий db2_all).

В начало

Устранение неисправностей

Централизованная (или на основе открытого ключа) аутентификация может некорректно работать по многим причинам – каждая версия ssh содержит какие-нибудь небольшие изменения, что приводит к сбою настроек. Этот раздел не содержит всесторонние подробности того, как выявлять все неисправности с конфигурацией ssh, но даст основу для самостоятельных изысканий. Прежде чем продолжить читать этот раздел, следует перечитать все инструкции, приведенные выше, и убедиться, что каждый шаг настройки был выполнен должным образом. Есть несколько общих моментов, которые надо проверить:

1. Убедитесь, что все конфигурационные файлы ssh-сервера обращаются к каноническому имени клиента, которое доступно для сервера. Например, если подключение ssh-клиента приходит с IP 1.1.1.1, метод gethostbyname(1.1.1.1) ssh-сервера сопоставит этот IP-адрес с machineA (или machineA.my.domain.com). Для получения более исчерпывающих подробностей обратитесь за справкой к документации по конфигурации сети.

2. Внимательно проверьте права доступа. Закрытые ключи должны принадлежать пользователю root, причем только root может читать/записывать эти ключи. Кроме того, пользователь root имеет права на чтение/запись открытых ключей, тогда как группа/остальные пользователи имеют к этим файлам только доступ на чтение. При аутентификации на основе открытого ключа, закрытый ключ пользователя должен принадлежать пользователю, права чтения/записи в него должен иметь тот же пользователь, кто-либо другой не имеет права читать закрытый ключ пользователя. Права на чтение/запись открытого ключа должны принадлежать только его владельцу, тогда как группа/остальные пользователи имеют доступ только на чтение этого ключа. Также, в случае аутентификации на основе открытого ключа, группа/другие пользователи не должны иметь прав записи в домашний каталог владельца текущего экземпляра DB2 UDB DPF. Каталог ~/.ssh должен быть доступен только для чтения/записи из под учетного доступа владельца текущего экземпляра DB2 UDB DPF (не разрешено никакого доступа для группы/остальных пользователей).

Если все вроде бы сконфигурировано правильно, то надо провести трассировку ssh-сервера и ssh-клиента и изучить собранные данные для обнаружения проблемы. Чтобы сделать это, необходимо отобрать два компьютера, которые не реализуют желаемый тип аутентификации (мы имеем ввиду machineA и machineB, которых рассматривали выше). Войдите в machineA используя учетную запись root. Запустите ssh-сервер в дополнительном режиме проведения диагностики на заданном порту, как показано далее. (В этом примере мы будем использовать порт 5555; можно использовать любой доступный для использования пользователем порт):

$ /usr/sbin/sshd -d -d -d -p 5555 2>&1 | tee sshd.trace # /opt/ssh/sbin/sshd on HP-UX

Затем необходимо загрузиться в machineB под учетной записью владельца текущего экземпляра DB2 UDB DPF, и запустить следующим образом ssh-клиент:

$ ssh -v -v -v -p 5555 machineA echo hi 2>&1 | tee ssh.trace

При необходимости попросят ввести свой пароль, после чего команда завершит свое выполнение. (Запрос пароля является последним рубежом обороны ssh. К моменту запроса на ввод пароля желаемый тип аутентификации уже отказал в работе.) Теперь можно начать поиск причины проблемы. В первую очередь необходимо открыть трассировочный файл клиента (ssh.trace на machineB) и просмотреть его на предмет сообщений о каком-либо событии, которое выглядело ошибкой. В этом файле может оказаться много информации, поэтому на ее понимание, возможно, уйдет некоторое время. Из трассировочного файла клиента нужно определить кто - ssh-клиент или ssh-сервер - не дает использовать желаемый тип аутентификации. Если сервер не позволяет использовать желаемый тип аутентификации, нужно открыть трассировочный файл ssh-сервера (sshd.trace на machineA) и искать причины происходящего в нем. Если в трассировочном файле обнаружатся сообщения, которые выглядят неправильными или непонятными, простейший способом понять смысл этих сообщений выполнить поиск в Интернете по строке целиком (или части строки), которая была найдена в трассировочном файле. Есть возможность, что кто-либо уже сталкивался с подобной конфигурационной проблемой и нашел нужное решение.

Ресурсы

• Примите участие в обсуждении материала на форуме.
  
  
• Configure DB2 Universal Database for UNIX to use OpenSSH (EN): оригинал статьи.
  
  
• Узнайте больше о проекте OpenSSH.(EN)
  
  
• Чтобы узнать больше о DB2, посетите раздел developerWorks, посвященный DB2. В данном разделе находятся техническая документация, пошаговые руководства, образовательные ресурсы, ресурсы для загрузки, информация о продуктах и другое.
  
  
• Safari bookstore: сайт магазина книг по ИТ.(EN)
  
  
• Ознакомьтесь с инструментами для разработки ПО и связующим ПО от DB2®, Lotus®, Rational®, Tivoli® и WebSphere®. Можно бесплатно загрузить ознакомительные версии продуктов или Linux или Windows® версию Software Evaluation Kit от developerWorks.(EN)
  
  
• Раздел developerWorks AIX and UNIX содержит сотни информативных статей для читателей начальной, средней и высокой квалификации.
  
  
• Блоги developerWorks.(EN)
  
  
• Команда IBM developerWorks проводит по всему миру сотни бесплатных технических консультаций.(EN)
  

Об авторе

		Лайам Финни (Liam Finnie) работает разработчиком программного обеспечения в департаменте DB2 UDB Operating System Services, где он помогает разрабатывать и обслуживать абстрактный уровень API-интерфейсов операционной системы. Его специализация – управление памятью, как DB2 UDB распределяет и управляет частной и общей памятью на всех поддерживаемых операционных системах.

Выскажите мнение об этой странице

Пожалуйста, найдите минутку и заполните форму, чтобы повысить уровень сервиса. Помогла ли данная информация достичь Вашей цели? Да Нет Не знаю   Пожалуйста, напишите комментарий, чтобы мы могли улучшить данную страницу:   Насколько полезна эта информация? (1 = Бесполезна, 5 = Очень полезна) 1 2 3 4 5

Поделиться этой статьей: забобрить сохранить в memori

В начало