openssh配置_配置UNIX的DB2通用数据库以使用OpenSSH

背景

UNIX上的DB2 UDB DPF实例需要一个远程Shell实用程序才能在实例中的远程节点上执行命令。 例如，在启动或停止DPF实例（ db2start/db2stop ）时，远程shell实用程序用于将启动/关闭命令发送到实例中的每个节点（无论该节点位于同一主机还是单独的主机上） ）。 此外，数据库管理员可以选择使用db2_all或rah实用程序在DPF实例中的远程节点上执行特定命令。 这些实用程序还需要一个远程Shell实用程序。 为了将OpenSSH用作DB2 UDB DPF实例的远程Shell实用程序，必须配置OpenSSH，以便允许实例中每个实例主机上拥有用户ID的实例登录到实例中的每个其他主机（因为实例拥有用户ID），而不会提示您进行任何其他验证（例如，密码或密码短语）。

本文介绍如何为AIX，Linux™，Solaris和HP-UX操作系统的基于主机和基于公钥的身份验证配置OpenSSH。 我们将在下面的设置中假设DB2 UDB DPF实例被配置为在两个不同的主机（每个主机上可以有任意数量的DB2节点）上运行，分别称为machineA和machineB。 我们还将假定这些机器的全限定名称为machineA.my.domain.com和machineB.my.domain.com，为简单起见，它们的IP地址对于machineA分别为1.1.1.1，而对于1.1.1.2对于machineB。 我们还将假定已经安装了OpenSSH，将ssh守护进程（sshd）配置为在系统引导时启动，并且已经为每台计算机生成了公用密钥和专用密钥。

将基于主机的身份验证与基于公钥的身份验证进行比较

使用ssh的基于主机的身份验证和基于公钥的身份验证都比基于rsh rhost的身份验证更安全。 使用基于主机的ssh身份验证，主机必须建立信任关系，然后，将允许配置的主机上的所有用户ID与其他任何配置的主机上的相同用户ID登录。 如果您在同一组主机上运行多个DB2实例，这可能很方便。 不利之处在于，一旦任何受信任的主机上的任何用户ID遭到破坏，所有受信任的主机上的相同用户ID就会受到破坏，因为该用户ID现在无需密码即可登录/ SSH到任何其他受信任的主机。 （如果在包装盒上配置了许多用户，这可能会引起关注，但是其中很少有人需要在不提示输入密码的情况下登录/ ssh到其他主机。）使用基于公钥的身份验证，只有特定用户才能使用用户曾经配置为登录/ ssh到其他主机，而没有提示输入密码，因此安全隐患更少。 另外，您无需具有根权限即可设置基于公共密钥的身份验证（基于主机的身份验证设置中的某些部分需要具有根访问权限）。 由于DB2 UDB DPF实例要求实例所有者的主目录在所有主机之间共享，因此基于公共密钥的身份验证设置非常简单。 尽管这两种身份验证方法都比基于rsh基于rhost的身份验证更安全，但您仍应选择与您的安全要求更加匹配的方法。

OpenSSH中可用的加密方法

OpenSSH支持DSA（数字签名算法）和RSA（Rivest-Shamir-Adleman）加密。 互联网上有文献讨论了两种加密方式的优缺点，您可能会发现不同的观点，哪一种更好。 最后，您应该选择使用符合安全要求的加密形式。 下面的讨论描述了如何使用两种加密方式针对每种认证类型配置OpenSSH：

• 基于主机的身份验证
• 基于公钥的身份验证

但是，无论使用哪种加密和身份验证方法，都请确保使用SSH版本2协议（OpenSSH 3.8p1中的默认协议），因为版本2协议比版本1协议更安全。

基于主机的身份验证

使用ssh的基于主机的身份验证允许来自machineA的任何用户ID使用ssh来登录作为machineB上的同一用户ID，前提是假设machineA上的ssh客户端配置为使用基于主机的身份验证，并且machineB上的ssh服务器配置为基于主机的身份验证。 为了使您的DB2 UDB DPF实例使用基于主机的身份验证，该实例中的每个主机都必须正确配置ssh客户端和ssh服务器。 我们将从ssh服务器配置开始，然后进行ssh客户端配置。

ssh服务器基于主机的配置

ssh服务器配置文件是sshd_config，在AIX，Linux和Solaris的/ etc / ssh中可以找到。 在HP-UX上，可以在/ opt / ssh / etc中找到sshd_config。 要对此文件进行更新并将更新应用于正在运行的sshd进程，您需要成为root用户。 使用您喜欢的编辑器打开sshd_config，搜索# HostbasedAuthentication no ，并如下更新文件：

清单1. sshd_config

#   HostbasedAuthentication no
HostbasedAuthentication yes

您可以根据需要删除原始行，但是，将原始行保留在配置文件中可能会很有用，这样您可以查看原始配置是什么以及对配置所做的修改。

对sshd_config的此更新将允许ssh服务器接受来自ssh客户端的基于主机的身份验证请求。 但是，仅允许在两个受信任的主机之间进行基于主机的身份验证。 此信任基于两个条件：

1. ssh服务器主机必须在shosts.equiv文件中具有客户端主机的条目。 在AIX和Linux上的/ etc / ssh中，在Solaris上的/ etc中以及在HP-UX上的/ opt / ssh / etc中都可以找到此文件。 如果此文件尚不存在，请创建该文件，并确保该文件归root用户所有，并且仅允许用户进行读写访问和组/其他读取访问（模式“ 644”）。 由于每个主机都必须能够与DB2 UDB DPF实例中的其他主机进行通信，因此请设置shosts.equiv文件，以便可以在所有主机上重用它。 因此，您的文件将类似于：

   清单2. shosts.equiv

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

2. ssh服务器系统上的主机必须有权访问ssh客户端主机的公共密钥。 对于基于主机的身份验证，信任机制在ssh_known_hosts文件中查找公用密钥，该文件位于AIX，Linux和Solaris的/ etc / ssh目录中以及HP-UX的/ opt / ssh / etc中。 如果此文件尚不存在，请创建该文件，并确保该文件归root用户所有，并且仅允许用户进行读写访问和组/其他读取访问（模式“ 644”）。 在ssh客户端主机上，在/ etc / ssh目录（或HP-UX上的/ opt / ssh / etc）中查找名为ssh_host_dsa_key.pub的文件以进行DSA加密，或在ssh_host_rsa_key.pub中进行RSA加密，然后打开该文件。 。 用于DSA加密的内容应类似于ssh-dss <key> 。 或ssh-rsa <key>用于RSA加密），其中<key>是主机的公钥，通常是一个很长的字符串。 现在，打开ssh服务器主机的ssh_known_hosts文件，并添加客户端计算机的主机名（所有适用的版本-不合格，完全合格和IP地址，均用逗号分隔），然后添加ssh客户端主机的公共主机密钥的内容。 看起来类似于以下内容：

   清单3.使用DSA加密的ssh_known_hosts

   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.使用RSA加密的ssh_known_hosts

   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.使用DSA加密的ssh_known_hosts

   $ 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.使用RSA加密的ssh_known_hosts

   $ 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会话，只会影响将来的会话。

清单7.确定sshd进程ID（PID）

$ 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

第一个条目告诉我们/ usr / sbin / sshd进程的PID为430084。要通知sshd进程重新读取配置文件，请键入：

清单8.重新启动sshd流程

$ kill -HUP 430084

清单9.在Linux上重新启动sshd进程的替代方法

$ /etc/init.d/sshd restart

这些步骤适用于DB2 UDB DPF实例中的所有主机。 因此，应在每个节点上应用相同的ssh服务器配置。 每个主机应具有sshd_config，shosts.equiv和ssh_known_hosts文件的相同副本。 （请记住在更新配置文件后通知每个主机上的sshd进程重新读取配置文件。）

一旦完成上面的ssh服务器设置，机器A和机器B之间的信任关系就完成了。 允许来自machineA的任何用户ID作为相同的用户ID SSH到machineB（这种基于主机的身份验证形式不允许一台计算机上的用户ID以另一台计算机上的不同用户ID身份登录）。 但是，直到将ssh客户端配置为也使用基于主机的身份验证，基于主机的身份验证才完成。

ssh客户端基于主机的配置

ssh客户端配置文件称为ssh_config（ssh服务器配置文件为sshd_config），可以在AIX，Linux和Solaris上的/ etc / ssh中以及在HP-UX上的/ opt / ssh / etc中找到。 打开ssh_config，查找# HostbasedAuthentication no ，并按如下所示更新文件：

清单10. ssh_config

#   HostbasedAuthentication no
HostbasedAuthentication yes

然后转到文件底部，并添加以下行：

清单11. ssh_config

EnableSSHKeysign yes

最后一行（ EnableSSHKeysign ）通知ssh客户端应使用单独的ssh-keysign实用程序读取主机的私钥。 （私钥应该由root拥有，并且仅应具有用户读/写访问权限。）另一种方法是使ssh实用程序本身成为suid root，但是使用ssh-keysign suid root通常更安全，因为ssh不需要以root用户身份运行。 在继续之前，请验证ssh-keysign已正确安装。 在AIX上，该文件应该在/ usr / sbin中找到，但是它可能已经安装在/ usr / bin下。 如果是这样，请将其复制到/ usr / sbin。 在Red Hat Linux系统上，应该在/ usr / libexec / openssh /中找到该文件，在SUSE Linux系统上，应该在/ usr / lib [64] / ssh /中找到该文件。 在Solaris上，应该在/ usr / libexec中找到它。 在HP-UX上，应该在/ usr / lbin中找到它。 现在，验证它是否已标记为suid-root可执行文件：

清单12.确保ssh-keysign是suid-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上，它应归root：bin而非root：system拥有）。

清单13.修复ssh-keysign的权限

$ 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

现在已将s​​sh客户端配置为允许基于主机的身份验证。 现在，应该在DB2 UDB DPF实例中的所有其余主机上更新ssh客户端配置。 完成此操作后，您可以继续进行“ DB2配置” 。

基于公钥的身份验证

使用基于公共密钥的认证，我们将使单个用户ID（拥有用户ID的DB2 UDB DPF实例）在实例中的每个主机上以相同的用户ID登录，而不会提示您输入密码。 由于DB2 UDB DPF实例所有者的主目录在所有机器上共享（DB2 UDB DPF实例的先决条件），因此可以在一台机器上完成整个设置。 在此示例中，我们将使用machineA。 作为拥有用户标识的DB2 UDB DPF实例登录到machineA。 如果此ID还没有〜/ .ssh目录，请立即创建一个。 确保.ssh目录不允许组或其他写访问。 同时，请确保您的主目录不允许组或其他写访问（ssh将其视为安全隐患，并且如果目录权限不够严格，将不允许基于公共密钥的身份验证）。 在〜/ .ssh目录中，生成一个公钥/私钥对：

清单14.生成密钥对

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

每当提示输入时，请按Enter接受默认值。 （确保没有输入任何密码，否则ssh将挑战每次身份验证尝试，并期望与用户的响应使用相同的密码。但是，DB2不允许远程Shell实用程序提示进行其他验证。）这将生成两个新文件。在〜/ .ssh目录中，id_rsa（私钥）和id_rsa.pub（公钥）用于RSA加密，id_dsa（私钥）和id_dsa.pub（公钥）用于DSA加密。 要使此新密钥对与ssh一起使用，请按照下列步骤操作：

清单15.启用密钥对

$ 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实例中每个主机的公共主机密钥，而不是从彼此之间登录到每个主机。

清单16.收集RSA公共主机密钥

$ 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

清单17.收集DSA公共主机密钥

$ 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用作远程Shell实用程序

现在，您已将ssh配置为使用不提示进行其他验证的身份验证形式，请验证配置是否成功。 第一个测试是检查machineA是否可以使用ssh在machineB上运行简单命令。 作为拥有用户标识的DB2 UDB DPF实例登录到machineA，然后键入：

清单18.简单的ssh配置测试

$ ssh machineB echo hi

如果提示您输入密码，则可能表示您正在使用公用密钥身份验证，并且在生成公用密钥/专用密钥对时指定了密码。 返回公钥认证说明 ，并生成不需要密码的新公钥/私钥对。 如果提示您输入密码或收到任何其他错误，请继续执行“ 故障排除” 。 如果返回命令花费的时间超过一秒或两秒，则可能是网络名称解析配置问题或特定版本的ssh的配置问题。 在任何一种情况下，请在Internet和网络配置文档中搜索可能的原因和解决方案。 否则，现在该通知DB2开始使用ssh执行远程命令。 从在machineA上拥有用户标识的DB2 UDB DPF实例中，输入：

清单19.通知DB2开始使用ssh

$ db2set DB2RSHCMD=/usr/bin/ssh

这将通知DB2在远程DB2节点上执行两个内部DB2命令（例如，使用db2start启动远程DB2节点）时以及在通过db2_all脚本在所有DB2节点上运行命令时使用哪个远程Shell实用程序。 要测试ssh是否已在DB2 UDB DPF实例中的所有主机上正确配置，请尝试一个简单的命令-使用以下命令让每个DB2节点回显响应：

清单20.在每个DB2节点上回声一次

$ db2_all echo hi

如果此命令成功完成而没有提示进行其他验证，则我们准备进行下一个测试。 否则，请跳过“ 疑难解答” 。 上一个测试确保当前的DB2节点可以ssh到其他DB2节点中。 您还希望确保任何DB2节点都可以ssh进入任何其他DB2节点。 因此，现在运行最后一个命令的修改版本：

清单21.请求每个节点在每个其他节点上回声嗨

$ db2_all db2_all echo hi

这次应该有更多的输出线。 只要所有DB2节点都响应而没有提示您进行其他验证，则DB2现在已完全配置为使用ssh作为远程Shell实用程序。 您将需要停止数据库服务器（ db2stop ）并重新启动服务器（ db2start ），此新设置才能在DB2服务器上生效（该设置对db2_all脚本立即生效）。

故障排除

基于主机或基于公共密钥的身份验证无法正常工作的原因可能很多，每个版本的ssh似乎在此处和此处进行了一些小的更改，最终破坏了某些配置。 本节将不会详细介绍如何解决所有ssh配置问题，但可以帮助您入门。 在继续之前，请重新阅读上述所有说明，并确保已遵循配置的每个步骤。 您应该检查以下几点常见问题：

1. 确保所有ssh服务器配置文件都引用服务器的标准名称，如服务器所示。 例如，如果ssh客户端连接来自IP 1.1.1.1，则ssh服务器上的gethostbyname（1.1.1.1）应该能够将其映射到machineA（或machineA.my.domain.com）。 有关更多详细信息，请查阅网络配置文档。

2. 仔细检查权限。 私有主机密钥应由root拥有，并且只能由root可读/写。 公用主机密钥应可由root可读/可写，但仅对于组/其他访问可读。 对于基于公钥的身份验证，用户的私钥应由该用户拥有，该用户可以读取/写入，其他任何人都不能读取。 公用密钥应该是所有者可读/可写的，并且仅对于组/其他访问是可读的。 同样对于基于公共密钥的认证，拥有用户标识的主目录的DB2 UDB DPF实例也不能由组/其他人编写。 〜/ .ssh目录只能由拥有实例的实例ID读取/写入（不允许组/其他访问）。

如果一切都似乎配置正确，那么该是使用一些ssh服务器和ssh客户端跟踪并挖掘跟踪以诊断问题的时候了。 为此，您需要选择两个主机，它们不允许进行所需的身份验证形式（在下面的讨论中，我们假设使用machineA和machineB）。 以root用户身份登录machineA。 在启用了额外调试诊断的指定端口上启动ssh服务器，如下所示。 （在此示例中，我们将使用端口5555；任何可用的用户端口都将起作用）：

清单22.启动一个新的诊断服务器会话

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

然后，以拥有用户标识的DB2 UDB DPF实例的身份登录到machineB，并按如下所示启动ssh客户机：

清单23.开始一个新的诊断客户端会话

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

如果出现提示，请输入密码，此命令将执行到完成。 （作为最后一种使用ssh的方法，系统会提示您输入密码。当提示您输入密码时，所需的身份验证形式已经失败。）现在，可以开始有趣的侦探工作了。 首先打开客户端跟踪（在MachineB上为ssh.trace），并在消息中查找看起来像是故障的东西。 那里有很多信息，因此可能需要一些时间来解密它。 从客户端跟踪，您应该能够确定是ssh客户端还是ssh服务器禁止了所需的身份验证形式。 如果服务器不允许身份验证，请打开ssh服务器跟踪（machineA上的sshd.trace）以查找线索。 当您在跟踪中找到看起来不正确或您不理解的条目时，解密消息的最简单方法是对在跟踪中找到的确切字符串（或字符串的一部分）进行Internet搜索。 可能有人已经遇到了类似的配置问题，希望他们会为您提供所需的解决方案。

---

翻译自: https://www.ibm.com/developerworks/data/library/techarticle/dm-0506finnie/index.html