注: 本文为安丫科技刘峰的原创，请尊重知识产权，转发请注明出处，不接受任何抄袭、演绎和未经注明出处的转载。
Linux 远程登录（SSH）几乎是所有运维人员的“第一关”。
但你是否遇到过这样的情况：
能 ping 通，就是连不上？
服务跑得好好的，客户端却提示“连接被拒绝”？
密码输入正确，却反复被打回？
用户没问题，登录后却直接断开？
这些场景其实都很常见。
本文带你 从网络层 → 服务层 → 认证层 → 用户层 全链路拆解 SSH 登录失败的所有可能原因，给出 检查参数 → 实验复现 → 解决方案，手把手教你定位问题。
无论是运维新人，还是一线 DBA，照着这篇走，你能解决 99% 的 SSH 登录失败问题。
Linux 远程登录（以 SSH 为例）是系统管理的核心操作，但实际使用中常因网络、服务配置、认证机制等问题导致登录失败,如图1-1所示。
图1-1
所有实验基于Kylin Server V10 环境，客户端为 Windows 10（使用 PuTTY/Xshell）或 Linux 主机（使用ssh命令）。
01
网络层故障：远程主机不可达
网络是远程登录的基础，若客户端与目标主机无法建立网络连接，后续认证环节无从谈起。
可能原因
目标主机 IP 地址错误或主机名解析失败；
客户端与目标主机不在同一网段，且无路由可达；
目标主机网卡未启用或 IP 配置错误；
客户端 目标主机防火墙（firewalld/iptables）拦截 SSH 端口（默认 22）；
物理网络故障（网线松动、交换机故障等）。
关键检查参数
实验过程：模拟 “防火墙拦截 SSH 端口” 场景
实验目标
验证 “目标主机防火墙未开放 SSH 端口” 导致的登录失败，并解决问题。
实验步骤
1）目标主机（192.168.2.46）配置：关闭 SSH 服务放行
# 1. 查看当前防火墙开放端口（默认未开放22端口时，无22/tcp记录）
firewall-cmd --list-ports
--输出如下
public (active)
target: default
icmp-block-inversion: no
interfaces: ens160 ens224
sources:
services: cockpit dhcpv6-client ssh
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks
# 2. 若已开放，手动移除ssh服务（模拟故障场景）
firewall-cmd --permanent --remove-service=ssh
firewall-cmd --reload # 重载配置生效
2）客户端测试登录：验证失败
# Linux客户端执行（Windows客户端用CRT连接192.168.2.46:22）
ssh root@192.168.2.46
失败现象
长时间无响应，最终提示ssh: connect to host 192.168.2.46 port 22: No route to host。
验证端口连接
telnet 192.168.2.46 22
--输出如下
Trying 192.168.2.46...
telnet: connect to address 192.168.2.46: No route to host
3）定位故障：检查防火墙规则
# 目标主机执行，确认ssh未开放
firewall-cmd --list-all | grep service
services: cockpit dhcpv6-client
4）解决问题：开放 SSH服务
# 目标主机执行，永久开放22端口并重载
firewall-cmd --permanent --add-service=ssh
firewall-cmd --reload
# 再次验证端口开放状态
firewall-cmd --list-all | grep service
services: cockpit dhcpv6-client ssh # 输出包含“ssh”即为成功
5）重新测试登录：验证成功
ssh root@192.168.2.46
root@192.168.2.46's password: # 可正常提示输入密码
02
SSH 服务层故障：服务未启动
或配置错误
SSH 服务（sshd）是远程登录的 “服务器端程序”，若服务未运行或核心配置错误，会直接拒绝客户端连接。
可能原因
sshd服务未启动或未设置开机自启；
SSH 服务配置文件（/etc/ssh/sshd_config）关键参数错误（如端口、允许登录用户、认证方式）；
sshd服务异常崩溃（如内存不足、配置文件语法错误）；
系统中存在与sshd冲突的进程（占用 SSH 端口）。
关键检查参数
实验过程：模拟 “sshd 服务未启动” 场景
实验目标
验证 “sshd服务未启动” 导致的登录失败，并恢复服务。
实验步骤
1）目标主机（192.168.2.46）配置：停止 sshd 服务
# 停止sshd服务并禁止开机自启（模拟故障）
systemctl stop sshd
systemctl disable sshd
# 验证服务状态（应为inactive）
systemctl status sshd
# 输出示例：
# ● sshd.service - OpenSSH server daemon
# Loaded: loaded (/usr/lib/systemd/system/sshd.service; disabled; vendor preset: enabled)
# Active: inactive (dead) since ...
2）客户端测试登录：验证失败
ssh root@192.168.2.46
失败现象
长时间无响应，最终提示ssh: connect to host 192.168.2.46 port 22: No route to host。
3）定位故障：检查 sshd 服务与端口
# 目标主机执行，确认sshd未运行
systemctl status sshd # 状态inactive
netstat -tulnp | grep 22 # 无sshd进程监听22端口
4）解决问题：启动 sshd 服务
# 启动sshd并设置开机自启
systemctl start sshd
systemctl enable sshd
# 验证服务状态（应为active）
systemctl status sshd
# 输出示例：
sshd.service - OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; preset: enabled)
Active: active (running) since Mon 2025-09-01 23:08:26 CST; 10s ago
5）重新测试登录：验证成功
ssh root@192.168.2.46 # 可正常提示输入密码
03
认证层故障：密码 密钥认证失败
网络与服务正常后，认证是登录的核心环节，分为 “密码认证” 和 “密钥认证” 两类故障。
密码认证失败
1. 可能原因
用户名错误（如输入 “root” 误写为 “roo”）；
用户密码错误（包括大小写错误、特殊字符遗漏）；
sshd_config禁用密码认证（PasswordAuthentication no）；
用户被锁定（/etc/shadow中密码字段前有 “!” 或 “*”）；
用户过期（/etc/shadow中过期时间字段超期）。
2. 关键检查参数
3. 实验过程：模拟 “密码认证被禁用” 场景
1) 实验目标
验证 “sshd_config设置PasswordAuthentication no” 导致密码登录失败，并恢复配置。
2) 实验步骤
① 目标主机（192.168.2.46）配置：禁用密码认证
# 编辑sshd_config文件
vi etc/ssh/sshd_config
# 修改以下配置（若注释则取消注释）
PasswordAuthentication no
# 重启sshd服务生效
systemctl restart sshd
② 客户端测试密码登录：验证失败
ssh root@192.168.2.46
失败现象
客户端提示root@192.168.2.46: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).（即使输入正确密码也反复提示错误）；目标主机日志显示：
tail -f var/log/secure
#输出示例：
Sep 1 22:19:37 db1 sshd[928]: Received signal 15; terminating.
Sep 1 22:19:37 db1 sshd[3467]: Server listening on 0.0.0.0 port 22.
Sep 1 22:19:37 db1 sshd[3467]: Server listening on :: port 22.
Sep 1 22:19:41 db1 sshd[3468]: Connection closed by authenticating user root 192.168.2.45 port 53160 [preauth]
Sep 1 22:20:50 db1 sshd[3472]: Connection closed by authenticating user root 192.168.2.45 port 53162 [preauth]
3）定位故障：检查密码认证配置
# 目标主机执行，确认配置禁用密码认证
grep "PasswordAuthentication" /etc/ssh/sshd_config
# 输出：PasswordAuthentication no
4）解决问题：启用密码认证
# 编辑sshd_config，恢复密码认证
vi etc/ssh/sshd_config
PasswordAuthentication yes # 修改为yes
# 重启sshd服务
systemctl restart sshd
5）重新测试密码登录：验证成功
ssh root@192.168.2.46 # 输入正确密码后成功登录
04
用户层故障：用户本身不可登录
即使网络、服务、认证均正常，若用户本身被系统限制登录，仍会导致远程登录失败。
这类故障的核心是 “用户属性配置不符合登录要求”，需从 Shell、账号状态、家目录权限等维度排查。
可能原因
用户 Shell 设置为 “不可交互 Shell”（如/sbin/nologin、/bin/false），无法建立登录会话；
用户家目录（~）权限过宽（如其他用户可写），SSH 为安全拒绝登录；
用户账号被设置 “不可登录” 标记（/etc/passwd中用户 ID 小于 1000 且无登录权限）；
临时文件目录（如/tmp）权限异常或磁盘满，导致登录时无法创建临时文件。
关键检查参数
实验过程 1：模拟 “用户 Shell 为
/sbin/nologin” 场景
实验目标
验证 “用户 Shell 设置为/sbin/nologin” 导致远程登录失败，并修改为可交互 Shell。
实验步骤
1）目标主机（192.168.2.46）配置：修改用户 Shell
# 创建测试用户test，并设置Shell为/sbin/nologin
useradd -s sbin/nologin test
echo "test123" | passwd --stdin test # 设置密码（确保密码正确）
# 验证Shell配置（最后一列为/sbin/nologin）
grep "test" /etc/passwd
# 输出示例：test:x:1001:1001::/home/test:/sbin/nologin
2）客户端测试登录：验证失败
ssh test@192.168.2.46
test@192.168.2.46's password:
Last failed login: Mon Sep 1 22:40:37 CST 2025 from 192.168.2.45 on ssh:notty
There was 1 failed login attempt since the last successful login.
This account is currently not available.
Connection to 192.168.2.46 closed.
失败现象
输入密码后提示This account is currently not available.（账号当前不可用），直接断开连接；目标主机日志显示：
tail -f var/log/secure
# 输出示例：
Sep 1 22:41:39 db1 sshd[3717]: pam_unix(sshd:session): session opened for user test(uid=54322) by test(uid=0)
Sep 1 22:41:39 db1 sshd[3738]: Received disconnect from 192.168.74.45 port 50390:11: disconnected by user
Sep 1 22:41:39 db1 sshd[3738]: Disconnected from user test 192.168.74.45 port 50390
Sep 1 22:41:39 db1 sshd[3717]: pam_unix(sshd:session): session closed for user test
3）定位故障：确认 Shell 类型
# 目标主机执行，确认Shell为不可交互类型
cat etc/shells # 查看系统支持的可交互Shell（如/bin/bash、/bin/sh）
grep "test" /etc/passwd # 确认test用户Shell为/sbin/nologin（不在/etc/shells列表中）
test:x:54322:54331::/home/test:/sbin/nologin
4）解决问题：修改为可交互 Shell
# 将test用户的Shell修改为/bin/bash（系统支持的可交互Shell）
usermod -s bin/bash test
# 验证修改结果（最后一列为/bin/bash）
grep "test" /etc/passwd
test:x:54322:54331::/home/test:/bin/bash
5）重新测试登录：验证成功
ssh test@192.168.2.46 # 输入密码后成功登录，显示test用户的命令行提示符
05
Linux 远程登录失败场景总表
（全场景梳理）
为方便快速排查，将所有场景按 “故障层级” 整理为总表，包含 “场景分类→可能原因→核心检查命令→解决方案关键词”：
06
故障排查方法论（通用流程）
遇到 Linux 远程登录失败时，建议按以下 “从底层到上层” 的流程逐步排查，避免盲目操作：
1）先查网络：用ping验证主机可达性，telnet 目标IP 端口（如telnet 192.168.2.46 22）验证端口是否开放；
2）再查服务：登录目标主机（本地或 KVM），用systemctl status sshd确认服务状态，sshd -t检查配置语法；
3）后查认证：查看/var/log/secure日志（核心日志文件），根据 “Failed password”“bad ownership” 等关键词定位认证问题；
4）最后查用户 / 特殊策略：确认用户 Shell、家目录权限，检查 SELinux 状态和连接数上限。
通过以上流程，可覆盖 99% 以上的 Linux 远程登录失败场景，结合本文的实验步骤和参数检查方法，能高效解决问题。
写在最后
SSH 登录失败，看似千奇百怪，其实都能归纳到 网络 → 服务 → 认证 → 用户 四个层级。
运维高手不是没遇到过问题，而是能在第一时间想到 从哪一层切入，快速定位。
👉 记住：
先验证“能不能连上”；
再确认“服务跑没跑”；
接着排查“认证机制”；
最后才是“用户属性”。
只要掌握了这套方法论，Linux 远程登录再难搞的故障，你都能迎刃而解。
💡 下期，我们会继续带来 SSH 安全加固 & 高可用场景配置 的实战分享，敬请期待！
作者介绍
大家好，我是刘峰，安丫科技创始人 & 数据库技术高级讲师，专注于 PostgreSQL、国产数据库运维与迁移、数据库性能优化 等方向。
作为 PG中国分会官方授权讲师、PostgreSQL ACE 讲师认证专家，我长期活跃在一线项目实战中，拥有 10年以上大型数据库管理与优化经验，曾深度参与电信、金融、政务等多个行业的数据库性能调优与迁移项目。
欢迎关注我，一起深入探索数据库的无限可能，技术交流不设限！
📌 觉得有收获的话，记得点赞、收藏、转发支持一下哦，别忘了关注我获取更多数据库干货~
关键词回复(可见相应文章):
oracle、mysql、pg、postgresql、sql、性能优化、故障处理、数据迁移、备份恢复、版本升级、补丁管理、深度巡检、解决方案、架构设计......
有任何问题或疑问，欢迎加V进群探讨哦～
\ | /
★
动动你的手指
给【安呀智数据坊】加个星标吧~
这样你就不会丢下我啦~
记得加星标呀！
