☰

为什么 TCP 包装器会停止为 sshd 工作？

tag-icon • tag-icon centos ssh
为什么 TCP 包装器会停止为 sshd 工作？

在几台 CentOS 5 服务器上，sshd 似乎已“解包”——以前我使用 TCP 包装器和 hosts.allow/hosts.deny 来控制访问，但现在这些都不用了。如果我执行

$ldd /usr/sbin/sshd | grep libwrap 
$

它什么都不输出，而在 TCP 包装器仍在工作的服务器上，我看到

libwrap.so.0 => /lib64/libwrap.so.0 (0x00002b2fbcb81000)

有人知道这可能是什么原因造成的，或者如何纠正吗？

更新 按照要求：

$ rpm -qV openssh-server
S.5....T  c /etc/pam.d/sshd
S.?....T  c /etc/ssh/sshd_config
S.5.....    /usr/sbin/sshd

ldd /usr/sbin/sshd 的输出是：

    libpam.so.0 => /lib64/libpam.so.0 (0x00002af906b89000)
    libcrypto.so.6 => /lib64/libcrypto.so.6 (0x00002af906d94000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00002af9070e5000)
    libutil.so.1 => /lib64/libutil.so.1 (0x00002af9072ea000)
    libz.so.1 => /lib64/libz.so.1 (0x00002af9074ed000)
    libnsl.so.1 => /lib64/libnsl.so.1 (0x00002af907701000)
    libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002af90791a000)
    libresolv.so.2 => /lib64/libresolv.so.2 (0x00002af907b52000)
    libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00002af907d67000)
    libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002af907f96000)
    libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00002af90822b000)
    libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002af908450000)
    libc.so.6 => /lib64/libc.so.6 (0x00002af908653000)
    libaudit.so.0 => /lib64/libaudit.so.0 (0x00002af9089ac000)
    /lib64/ld-linux-x86-64.so.2 (0x00002af90696b000)
    libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00002af908bc4000)
    libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00002af908dcd000)
    libselinux.so.1 => /lib64/libselinux.so.1 (0x00002af908fcf000)
    libsepol.so.1 => /lib64/libsepol.so.1 (0x00002af9091e8000)

$ rpm -qa|grep openssh-server

openssh-server-4.3p2-82.el5

$ sudo /usr/sbin/sshd -p 22222 -d -d

debug2: load_server_config: filename /etc/ssh/sshd_config
debug2: load_server_config: done config len = 655
debug2: parse_server_config: config /etc/ssh/sshd_config len 655
debug1: sshd version OpenSSH_4.3, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: private host key: #0 type 0 RSA1
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-p'
debug1: rexec_argv[2]='22222'
debug1: rexec_argv[3]='-d'
debug1: rexec_argv[4]='-d'
Set /proc/self/oom_adj from 0 to -17
debug2: fd 3 setting O_NONBLOCK
debug1: Bind to port 22222 on ::.
Server listening on :: port 22222.

答案1

目前，有证据表明你的文件sshd已被重新编译。根据输出，MD5 校验和和文件大小都是错误的rpm -qV。

sshd似乎不如 openssh 那样有用，它能告诉您它正在运行什么版本以及何时编译，但是 的输出rpm -qa|grep openssh-server和前十行左右/usr/sbin/sshd -p 22222 -d -d（您可以将任何未使用的端口替换为 22222，该命令将需要特权，并且您可以在启动后使用它来终止它^C- 这只是我们想要的版本号）在这里最有帮助。

编辑：看起来您的 sshd 更像是非发行版。我刚刚做了同样的测试（sshd -p 22222 -d -d在装有原版的 C5.10 盒子上sshd），我得到了一行

debug1: sshd version OpenSSH_4.3p2

虽然你有

debug1: sshd version OpenSSH_4.3, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008

目前，我看不出有任何理由认为您正在运行原版sshd，这可以解释为什么它不遵守 TCP 包装器。除其他事项外，这可能会使您面临针对该sshd版本的大量攻击的风险，这些攻击已在发行版中得到修补。您可以通过删除并重新安装 RPM 并检查 TCP 包装器兼容性是否已恢复来获得明确的答案openssh-server。您可能需要在控制台上安全地执行此操作。

答案2

根据 rpm -qV 输出，您的 sshd 二进制文件已被修改，但修改时间戳被设置回其原始值。

通常，发生这种情况是因为您的计算机已被黑客入侵，并且攻击者拥有 root 访问权限。这也可以解释您的 sshd 二进制文件功能异常。

请注意，当您登录时，您的 ssh 服务器几乎肯定会将您的密码发送给黑客，因此现在所有密码都已被泄露。

答案3

它是用适当的标题（configure --with-libwrap[=path]）编译的 - 所以它使用它。

我记得这是有意的行为——就像描述的那样http://www.akadia.com/services/ssh_tcp_wrapper.html。

相关内容