☰

编辑

tag-icon • tag-icon networking command-line server ssh 22.04
编辑

我在服务器上运行 Ubuntu 22.04.1 LTS，今天早上我从手机上的 Termius 应用程序 ssh 进入服务器运行update，upgrade然后像往常一样重启两次以安装内核升级。第二次重启后，我无法再通过 ssh 连接。我曾经systemctl start ssh重新启动 ssh 服务器，因为它显然没有重新启动。但是，我仍然无法通过 SSH 连接。我可以说服务器的网络不是问题，因为我在其上运行的所有其他服务（例如网站、pi-hole 和 minecraft 服务器）都运行良好并且可以连接，并且与服务器的 ping 操作也符合预期。ufw我的 ssh 端口是否仍然启用。

使用我的 SSH 配置，我需要密码和 SSH 密钥才能加入，我的直觉告诉我 SSH 密钥是问题所在。我检查了一下，~/.ssh/authorized_keys所有目标设备的密钥仍然存在。自更新以来，我的 Windows 和 iOS SSH 设置都没有改变，但都不起作用。我在 Windows Powershell 中运行以下命令：

 ssh bcoffy@{server.public.ip} -p {server_ssh_port} -i "C:\Users\{path_to_ssh_key}\SSH\id_rsa0" -vvvv

并得到以下结果：

    OpenSSH_for_Windows_8.6p1, LibreSSL 3.4.3
debug3: Failed to open file:C:/Users/{username}/.ssh/config error:2
debug3: Failed to open file:C:/ProgramData/ssh/ssh_config error:2
debug2: resolve_canonicalize: hostname {server_public_port} is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> 'C:\\Users\\{username}/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> 'C:\\Users\\{username}/.ssh/known_hosts2'
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug3: ssh_connect_direct: entering
debug1: Connecting to {server.public.ip} [{server.public.ip}] port {server_ssh_port}.

编辑：现在可以正常工作了，我不知道问题是什么或如何解决，但 SSH 现在可以正常工作了，Netbats 提供的答案中的所有内容肯定都帮助我调试了它。谢谢你的帮助！

答案1

根据错误信息，看起来configWindows 机器上缺少文件（例如此位置C:/Users/{username}/.ssh/config）或缺少读取权限。

有时，当 SSH 版本或服务器端和客户端的安全算法版本不匹配时，就会出现问题。

但是请尝试针对 Ubuntu 服务器进行以下测试。如果所有测试都正常，则问题出在 Windows 端。

SSH 守护进程服务是否正在运行？

sudo systemctl status sshd.service

您必须看到左边缘的一个绿点和状态消息Active: active (running)。

SSH 守护进程服务是否在监听 TCP 端口 22？

sudo netstat -lntp | grep 22

如果netstat没有安装该命令，请安装它：

sudo apt-get update
sudo apt-get install net-tools

正确的 netstat 答案应该是这样的：

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTENING  1702/sshd: /usr/sbi 
tcp6       0      0 :::22                   :::*                    LISTENING  1702/sshd: /usr/sbi

防火墙上是否有允许访问端口 22 的规则？

sudo iptables-save | grep "\--dport 22"

或者第二种可能性是如何找到过滤不太严格的 TCP 22 端口规则：

sudo iptables-save | grep "22"

正确的命令响应示例为：

-A ufw-user-input -p tcp -m tcp --dport 22 -j ACCEPT

Ubuntu 服务器上的本地 SSH 自检

准备：通过命令获取/验证Ubuntu服务器自身的ip地址ip addr。假设检测到的地址为192.168.1.50。

ssh -l your_username 127.0.0.1

进而

ssh -l your_username 192.168.1.50

您应该将您的帐户重新连接至同一台服务器。

该w命令为到同一服务器的每个 SSH 连接显示 1 个额外的行。

w

从另一台 PC 验证与 Ubuntu 服务器的连接

使用另一个网络节点从外部检查情况。用192.168.1.50服务器的真实地址替换。

ping 192.168.1.50

验证 Ubuntu 服务器上的端口 22 从外部是否可见为打开。

telnet 192.168.1.50 22

正确的输出应该是这样的：

Trying 192.168.1.50...
Connected to localhost.
Escape character is '^]'.
SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.1

您可以使用其他命令代替 telnet 通过网络查看端口 22 是否打开。响应如下。

netcat nc：

nc -4zv 192.168.1.50 22

回复：

Connection to 192.168.1.50 22 port [tcp/ssh] succeeded!

nmap

sudo nmap -sT -p 22 192.168.1.50

回复：

Starting Nmap 7.80 ( https://nmap.org ) at 2023-01-13 21:27 CET
Nmap scan report for localhost (192.168.1.50)
Host is up (0.000067s latency).

PORT   STATE SERVICE
22/tcp open  ssh

Nmap done: 1 IP address (1 host up) scanned in 0.02 seconds

编辑

响应防弹科菲评论

至于 SSH 密钥，我假设您知道自己在做什么。服务器密钥必须始终存在并正确设置，否则远程或本地 SSH 连接都无法正常工作。

从您的所有描述来看，这似乎是服务器上本地防火墙的问题，除非两台计算机之间还有另一个防火墙。例如，规则顺序不正确（拒绝规则在接受规则之上）或使用错误的配置文件（公共/办公室/家庭）就足以使允许 SSH 的规则无效。

有一个简单的测试可以验证 SSH 流量是否被服务器上的本地防火墙阻止。关闭防火墙一段时间。

sudo ufw disable

然后使用从另一台计算机进行测试，nc看看 SSH 端口的可用性是否发生了变化。

编辑2

我不确定我是否理解正确。即使直接在服务器上，也无法使用nmapand检测端口是否打开nc。同时，该netstat命令显示端口处于活动状态并正在监听。对吗？

我推荐这个程序：

使用 netstat 找出哪个应用程序正在监听 SSH 端口。语句的最后一列包含进程号。在适用于您的 SSH TCP 端口的行中搜索数字。

sudo netstat -lntp

使用前面列表中检测到的进程号（例如 5678）来确定它属于哪个应用程序。

ps -ef | grep 5678

输出示例：

root        1167       1  0 09:33 ?        00:00:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups

查明是否真的是您的 SSH 守护程序在监听您的 SSH 端口。验证当您停止 SSH 守护程序服务时，SSH 端口号是否已从打开端口列表中消失。

sudo systemctl status sshd.service
sudo systemctl stop   sshd.service
sudo systemctl status sshd.service
sudo netstat -lntp

现在直接在 Ubuntu 服务器上使用另一个应用程序进行测试（例如nc），可以打开用于 SSH 的端口，并且可以通过网络从另一台计算机看到它。在我的示例中，Netcat 在 Ubuntu 第一个终端窗口中开始监听 TCP 端口 22。

nc -k -l 22 > /dev/null

!!! 请记住，nc必须使用 -k 参数启动监听器，或者每次测试后重新启动监听器 !!!

在同一台 Ubuntu 服务器上打开第二个终端并检查端口是否打开：

sudo nestat -lntp
nc -4zv localhost 22

从另一个网络节点远程测试端口。使用上面描述的一些命令（telnet、nmap、nc）。

如果现在该端口在本地和网络远程被视为开放，则可能只有一种解释，即 SSH 守护程序出现故障。重新安装 SSH 守护程序。

编辑3

我设计的测试旨在帮助确定问题出在 SSH 守护程序应用程序上还是其他地方。关键在于回答这个问题：当有不同于 SSH 守护程序的监听应用程序代替守护程序时，从另一台计算机来看 SSH TCP 端口是否可见为打开状态？如果答案是否定的，则意味着端口在某处被阻止，并且与 SSH 守护程序无关。您需要找出是什么阻止了与 SSH 端口的连接。请尝试在另一个完全空闲且尚未使用的端口上使用 nc 监听应用程序重复测试。

nc -k -l 777 > /dev/null

关闭 UFW 并连续尝试几次，看看端口是否在本地可见，然后从 LAN 上的其他设备查看。请使用多个设备从 LAN、另一台 PC 或智能手机测试端口，然后使用 Net Analyzer 应用程序进行测试。

如果该端口在 LAN 中可用（开放），则停止监听nc并使用已证实的 SSH 守护程序端口号。取消注释#Port 22文件中的行/etc/ssh/sshd_config，输入新的端口号（而不是 22），然后重新启动 sshd 服务。

使用netstat和验证nc新的 SSH 端口是否对内部和外部访问开放。

相关内容