Linux服务器SSH连接不上怎么办？

使用莱卡云Linux服务器时，如果SSH客户端一直等待、提示连接被拒绝，或者输入密码后仍无法登录，可以按照“连接参数、服务状态、监听端口、访问规则、认证日志”的顺序排查。

不同报错对应的故障位置不同。先保存完整错误信息，再进行针对性检查，可以减少反复修改配置带来的影响。

本文中的203.0.113.10为服务器示例IP，198.51.100.25为本地电脑公网出口示例IP，admin为示例用户名。执行命令前，请替换成实际值。

1. 先根据报错判断排查方向

这些提示用于确定方向，不能仅凭一条报错判断具体原因。

例如，连接被拒绝可能是没有程序监听，也可能是防火墙返回了拒绝响应。

2. 在本地电脑检查连接参数

先确认服务器处于运行状态，并核对：

• 当前连接的是正确的公网IP。

• SSH端口是否仍为22。

• 用户名是否与系统镜像和实际账户一致。

• 客户端是否使用了正确的密码或私钥。

• 如果通过域名连接，域名是否解析到了正确地址。

在本地终端执行：

ssh -vvv -o ConnectTimeout=10 -p 22 [email protected]

其中：

• -vvv用于显示详细连接过程。

• ConnectTimeout=10限制连接及初始握手的等待时间。

• -p 22指定SSH端口。

如果使用自定义端口，例如2222，需要相应修改：

ssh -vvv -o ConnectTimeout=10 -p 2222 [email protected]

Windows用户还可以在本地PowerShell检查TCP端口：

Test-NetConnection -ComputerName 203.0.113.10 -Port 22

TcpTestSucceeded : True说明TCP连接测试成功，但不代表SSH认证一定能通过。

Ping测试与SSH端口测试不同。服务器禁止ICMP时，可能无法Ping通，但SSH仍然正常。

3. 在服务器控制台检查SSH服务

如果已经无法通过SSH登录，需要先使用实例支持的VNC、串口或其他控制台连接方式进入系统。

以下命令在服务器内执行。

Ubuntu、Debian常见服务名称为ssh：

sudo systemctl status ssh --no-pager -l

Rocky Linux、AlmaLinux及RHEL系列常见服务名称为sshd：

sudo systemctl status sshd --no-pager -l

也可以提取关键状态：

sudo systemctl show ssh -p LoadState -p ActiveState -p SubState

使用sshd服务名称的系统，将上面的ssh替换为sshd。

常见结果包括：

如果没有找到服务，先确认服务名称和OpenSSH服务端是否已安装。

部分Ubuntu系统使用ssh.socket监听端口，并在收到连接时启动SSH服务。此时，还需要执行：

sudo systemctl status ssh.socket --no-pager -l

ssh.service暂时未运行，而ssh.socket处于监听状态时，不能直接认定SSH已经故障。

如果确认服务应该常驻运行，但当前没有启动，先检查配置：

sudo /usr/sbin/sshd -t
echo $?

没有错误输出且紧接着的退出码为0，表示本次检查通过。

检查通过后，根据实际服务名称选择启动：

sudo systemctl start ssh

或：

sudo systemctl start sshd

4. 检查SSH实际监听的端口和地址

在服务器内执行：

sudo ss -lntp '( sport = :22 )'

如果SSH使用2222端口，应改为：

sudo ss -lntp '( sport = :2222 )'

只查看监听地址和端口，可以去掉-p：

sudo ss -lnt '( sport = :22 )'

重点检查：

查看配置文件解析出的端口和监听地址：

sudo /usr/sbin/sshd -T | grep -E '^(port|listenaddress) '

这里显示的是当前配置文件的解析结果。运行中的服务可能尚未重新加载；使用socket激活时，监听还可能由ssh.socket管理。因此，应以ss显示的实际监听结果为准。

对于socket激活的系统，还可以检查：

sudo systemctl cat ssh.socket
sudo systemctl show ssh.socket -p Listen

云服务器使用公网地址映射时，公网IP不一定直接配置在系统网卡上，设置ListenAddress前应确认本机实际地址。

5. 检查安全组和系统防火墙

如果服务正常、端口也在监听，但本地仍然连接超时，需要检查访问规则。

如果实例提供安全组或平台防火墙功能，应核对：

• 入站协议是否为TCP。

• 目标端口是否为实际SSH端口。

• 允许的来源是否包含当前公网出口IP。

• 规则是否应用到了正确实例。

• 使用IPv6连接时，是否配置了对应的IPv6规则。

本地电脑的公网出口IP可能随网络变化，旧的来源白名单可能已经不适用。

在服务器内，根据实际使用的防火墙工具检查。

使用UFW：

sudo ufw status verbose
sudo ufw status numbered

如果已经确认是缺少允许规则，可以只放行可信来源。例如：

sudo ufw allow proto tcp from 198.51.100.25 to any port 22

执行前，将示例IP和端口替换为实际值。如果存在更早匹配的拒绝规则，还需要检查规则顺序。

使用firewalld：

sudo firewall-cmd --get-active-zones

确定入口网卡或来源地址对应的区域后，再查询该区域：

sudo firewall-cmd --zone=public --list-all

public只是示例，需要替换为实际区域。应在实际生效的区域中添加对应端口和可信来源规则，并确认运行时配置与永久配置一致。

如果服务器由宝塔、安全软件或其他工具管理防火墙，也要检查其拦截记录。修复时调整相关规则即可，避免清空全部防火墙配置。

6. 密码或密钥认证失败怎么处理？

出现Permission denied时，连接通常已经进入认证阶段，应重点检查账户和认证配置。

首先确认登录用户是否存在：

getent passwd admin

核对用户名、用户家目录，以及账户是否被锁定、过期或禁止交互式登录。

使用密钥登录时，在本地电脑明确指定私钥：

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 \
  -p 22 [email protected]

IdentitiesOnly=yes可以限制使用配置或命令指定的身份，减少SSH代理提交过多无关密钥的问题。

继续核对：

• 本地选择的是私钥文件。

• 对应公钥已安装到目标登录用户的授权文件中。

• AuthorizedKeysFile是否使用了自定义路径。

• 公钥内容是否完整，是否被错误换行。

• 用户家目录、.ssh目录和授权文件的所有者及权限是否正确。

如果使用常见的~/.ssh/authorized_keys路径，在服务器上切换到目标登录用户后，可以检查：

ls -ld ~ ~/.ssh
ls -l ~/.ssh/authorized_keys

确认文件存在、所有者正确后，常见权限设置为：

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

用户家目录也不应允许无关用户写入。修改权限时，应针对实际登录用户操作。

检查认证配置的基础解析结果：

sudo /usr/sbin/sshd -T | grep -E \
'^(pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|authenticationmethods|permitrootlogin|authorizedkeysfile) '

如果配置包含Match条件，还需要结合具体用户和来源地址检查，例如：

sudo /usr/sbin/sshd -T \
  -C user=admin,addr=198.51.100.25

如果还使用了主机名、本地地址或端口匹配条件，应补充相应连接参数。

原本只允许密钥登录的服务器，应修复密钥、权限或认证规则。AuthenticationMethods要求使用的认证方式，也必须在配置中启用。

7. 查询SSH认证和启动日志

在服务器内查看最近10分钟日志：

sudo journalctl -u ssh -u sshd --since "-10min" --no-pager

需要简洁查看消息正文时，可以增加-o cat：

sudo journalctl -u ssh -u sshd --since "-10min" --no-pager -o cat

排查时保留服务器控制台，在本地电脑重新尝试一次连接，再对照同一时间的日志。

常见日志及排查方向：

持续观察日志时，可根据实际服务名称使用：

sudo journalctl -f -u ssh

或：

sudo journalctl -f -u sshd

部分系统还会将认证日志写入/var/log/auth.log或/var/log/secure，具体取决于日志服务配置。

如果已经认证成功，但随后立即断开，还应检查登录Shell、用户启动脚本、磁盘空间及系统资源情况。

8. 修改SSH配置后无法登录怎么恢复？

通过服务器控制台登录，优先检查最近修改过的配置文件。

常见位置包括：

/etc/ssh/sshd_config
/etc/ssh/sshd_config.d/

是否加载配置片段，取决于主配置中的Include设置。

OpenSSH多数配置项采用首先读取到的值，不能假定“在文件末尾再写一遍”就会覆盖前面的设置。还要留意Match条件的作用范围。

先执行：

sudo /usr/sbin/sshd -t

根据错误提示修复具体文件和行号，或恢复已经确认可用的备份。配置检查通过后，再让服务加载修改。

对于正在运行的常驻SSH服务，普通配置修改可以根据服务名称选择：

sudo systemctl reload ssh

或：

sudo systemctl reload sshd

服务未运行时，应在检查通过后使用start。

如果是Ubuntu 24.04默认的socket激活模式，并且修改了监听端口或地址，需要同时处理socket配置。确认控制台可用、配置检查通过后，可以执行：

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket ssh.service

随后重新使用ss确认实际监听结果。存在自定义socket覆盖文件时，还要核对其内容是否符合预期。

在启用了SELinux的RHEL系列系统中，自定义SSH端口还需要检查端口标签：

getenforce
sudo semanage port -l | grep '^ssh_port_t'

如果新端口未被允许，应按系统策略将其配置为SSH允许使用的端口，同时调整防火墙。若端口已属于其他服务类型，应先确认用途。

整个修改过程中保留当前可用会话或控制台，使用另一个窗口验证新连接成功后，再结束原会话。

9. 提示主机密钥变化怎么办？

出现以下提示时：

REMOTE HOST IDENTIFICATION HAS CHANGED

先确认服务器是否重装、重建或更换过主机密钥，以及当前IP是否仍然对应目标实例。

通过可信的服务器控制台查看主机公钥指纹，例如ED25519：

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

应与客户端提示中的相同密钥类型进行比较。

确认变化符合预期、指纹一致后，才在本地电脑移除对应旧记录：

ssh-keygen -R 203.0.113.10

如果使用2222等自定义端口：

ssh-keygen -R '[203.0.113.10]:2222'

随后重新连接，核对并接受正确的新指纹。通过域名连接时，也需要处理对应域名的记录。

10. 恢复后需要检查什么？

从原先连接失败的本地网络重新登录，确认：

• 使用正确的IP、端口和用户名能够建立新连接。

• 密码或密钥认证符合原定要求。

• SSH服务和监听状态正常。

• 防火墙规则已按实际需要保存。

• 日志中没有持续出现新的启动或认证错误。

• 测试过程中添加的多余规则已经整理。

如需提交莱卡云技术支持工单，建议提供故障时间及所在时区、目标IP和端口、完整错误提示、本地公网出口IP，以及服务状态、监听结果和相关日志。

请勿提交私钥或明文密码。调试输出中的敏感路径、账户信息和其他业务数据，可在提交前进行遮盖。