☰

如何正确检查 SSH 在 Linux 机器上监听的网络接口？

tag-icon • tag-icon linux ssh redhat-enterprise-linux netstat oracle-linux
如何正确检查 SSH 在 Linux 机器上监听的网络接口？

我不是系统工程师或网络专家（我更像是软件开发人员），我有以下问题需要解决。

我正在使用 Oracle Linux 机器（基本上应该基于 RedHat）。

我必须检查 SSH 在该虚拟机上监听哪些网络实例。我使用以下链接作为参考：https://access.redhat.com/solutions/260463

它展示了如何使用这个命令（这是以前的网站示例）：

$ grep sshd netstat
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      0          12412      3522/sshd           off (0.00/0/0)

问题是，如果我尝试在我的计算机上复制相同的命令，我会收到以下错误消息：

[root@zabbix-db ~]# grep sshd netstat
grep: netstat: No such file or directory

为什么？哪里错了？我遗漏了什么？我该如何正确执行此检查？这个错误的确切含义是什么（它指的是不存在的文件，但据我了解，我是在 netstat 输出上 grep，而不是在文件上 grep）

答案1

它说的是不存在的文件，但据我所知，我是在 netstat 输出上查找，而不是在文件上查找

不，您实际上是在 grep 一个名为 的文件netstat。

实际上跑步“netstat”作为命令，将其输出提供给 grep，您需要使用管道：

netstat | grep sshd

请注意，netstat 的默认输出实际上不会显示聆听套接字 - 您需要指定-l( --listening) 以将它们包含在输出中。此外，默认情况下它不会提及程序名称；该列由-p( --processes) 选项添加。最后，如果您想要查看实际的 IP 地址，请添加-n( --numeric) 以禁用“反向 DNS”查找。

netstat --listening --processes --tcp --numeric | grep sshd
netstat -l -p -t -n | grep sshd
netstat -lptn | grep sshd

...仅显示监听的 TCP 套接字及其程序名称，而不显示反向 DNS 查找。

同样的情况也发生在ss很多 Linux 发行版中，它现在作为 netstat 的替代品：¹

ss -lptn | grep sshd

¹ 'netstat' 没有什么特别的问题，但它是“net-tools”包的一部分，而这个包本身缺乏维护，而且它的其他诸如“ifconfig”之类的工具存在严重问题，因此整个软件包通常不再安装。

答案2

grep 命令的一般语法是：

grep target-pattern filename

因此 grep 没有找到名为“netstat”的文件——这并不奇怪，因为它是一个命令。

有几种方法可以实现你想要的；例如，你可以运行网络状态通过一些命令详细说明并通过 grep 发送输出以仅返回“sshd”的匹配项：

netstat -plunt | grep sshd

在我的（Debian）服务器上，结果如下：

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1571/sshd: /usr/sbi
tcp6       0      0 :::22                   :::*                    LISTEN      1571/sshd: /usr/sbi

答案3

我发现以下是一种更简单的方法来确认连接路由，使用 putty 和 ifconfig。

  1. 通过接口从任何其他设备打开 putty 会话进行验证，例如 ssh[电子邮件保护]，一旦会话打开，运行 top。

  2. 通过任何其他接口从任何其他设备打开 putty 会话，例如 ssh[电子邮件保护]，注意第 3 个八位字节中的网络 1 和网络 2 不同。现在通过 ifconfig 使用 192.168.2.250 禁用接口。

  3. 在步骤 1 中的会话中，top 应该冻结，最终 putty 会话将超时。

开发此方法是为了验证一个问题，即特定协议在 10GB 网络上失败，原因不明，而且由于 Windows 有时完全无法追踪 SMB 问题，因此需要 100% Linux 端的东西。假设 ping 有效，ssh 有效，但 SMB 失败……想想看。那么问题就变成了，SMB 是否在进行一些奇怪的路由？因此，需要一种方法来使用 SMB 以外的协议测试 10GB NIC。显然，ping 有效，但那是低级的，所以使用 SSH 来验证问题显然是影响或特定于 SMB 的软件/协议堆栈问题，就我的情况而言。

您可以通过任何定义的端口使用 telnet，以类似的方式进行验证。

通过 TCPDump 或 WireShark 观察上述序列也很有趣，但对于给定协议（在本例中为 ssh）的简单验证检查，这可能做得很深入。

相关内容