Ubuntu安装SSH后无法远程连接怎么办
详细解析在 Ubuntu 系统中安装 SSH 后出现无法远程连接时的完整排查方案,从服务状态、网络连通性、防火墙与安全组规则,到 sshd_config 配置文件及权限设置,提供精准的排查步骤与修复命令。
一、排查路径总览:先理清连接卡在哪一层
排查 SSH 连接故障最忌讳没有章法地盲目修改配置文件。SSH 连接在底层基于标准 TCP 协议与密码学认证握手,一个连接从客户端发起直至建立终端会话,必须依次通过四道关卡:
- 进程监听层:Ubuntu 系统内部是否真正安装并运行了
openssh-server服务守护进程,是否正在监听 22 号端口。 - 网络连通层:客户端与 Ubuntu 服务端之间的物理或虚拟网络是否互通,输入的 IP 地址是否属于目标主机且可路由。
- 安全访问控制层:Ubuntu 本地的 UFW 防火墙、云厂商安全组或路由器端口转发规则是否放行了 TCP 协议流量。
- 凭证与授权层:服务端的
/etc/ssh/sshd_config是否限制了特定用户登录、是否关闭了密码登录,以及密钥文件的权限是否符合安全规范。
二、第一步:确认服务端 SSH 服务与端口状态
初次在 Ubuntu 上配置 SSH 时,最容易出现的失误是只安装了客户端(openssh-client),而没有安装负责监听远程请求的服务端套件(openssh-server);或者服务安装后由于系统原因未自动拉起。
1. 检查 SSH 服务端是否已安装并处于运行状态
在 Ubuntu 本地控制台(桌面终端、物理机屏幕或虚拟机窗口)中执行以下命令查看服务运行状态:
sudo systemctl status ssh
在较老版本或特定发行版镜像中,服务名也可能被称为 sshd。执行后观察终端输出中的 Active: 字段状态:
- 状态为
active (running):说明服务正在正常运行,可直接进入下一步网络排查。 - 状态为
inactive (dead)或failed:说明服务停止或启动崩溃。执行启动命令:sudo systemctl start ssh sudo systemctl enable ssh # 设置开机自启 - 提示
Unit ssh.service could not be found.:说明系统中根本未安装服务端程序。请执行完整安装:sudo apt update sudo apt install -y openssh-server
2. 验证本地端口监听情况
即使进程处于运行状态,也需要验证其是否在预期网络端口上监听连接请求。使用 ss 工具检查 TCP 监听状态:
sudo ss -tulpn | grep :22
预期输出示例:
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1024,fd=3))
tcp LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=1024,fd=4))
如果监听地址显示为 127.0.0.1:22,则表示 SSH 服务被限制为仅允许本机回环访问,外部请求一律会被内核直接拒接,需在后续配置文件中修改监听地址。
三、第二步:核对 IP 地址与双向网络连通性
当客户端连接返回 Connection refused 或 Connection timed out 时,需要区分这两者的根本差异。
1. 获取 Ubuntu 服务端的真实 IP 地址
切勿直接使用 127.0.0.1 或 localhost 作为远程连接目标。在 Ubuntu 服务端终端中输入:
ip a
在输出结果中查找以太网卡(通常为 eth0、enp3s0 等)或无线网卡(wlan0)下的 inet 条目。例如 inet 192.168.1.120/24,则 192.168.1.120 即为服务端的局域网 IP。
2. 从客户端测试基础网络与端口联通
在远程客户端(Windows 命令提示符、macOS 终端或另一台 Linux)中执行连通性测试:
# 测试 ICMP 底层路由
ping 192.168.1.120
# 测试 22 端口 TCP 连通性(Linux/macOS)
nc -zv 192.168.1.120 22
# Windows PowerShell 测试端口
Test-NetConnection -ComputerName 192.168.1.120 -Port 22
- 如果
ping无法收到响应,或者端口测试报Timed out,说明流量在网络链路或防火墙层被直接丢弃,属于网络或安全策略问题。 - 如果
ping正常,但连接测试立刻报Connection refused,说明网络可达,但目标主机上没有进程响应该端口,通常是服务端没跑起来或端口号写错。
3. 虚拟机与云主机的特殊网络注意项
- VMware / VirtualBox 虚拟机:如果虚拟机网卡配置为 NAT 模式,虚拟机与物理宿主机位于隔离的虚拟子网中,局域网其他计算机默认无法直接访问该虚拟机 IP。解决方法是将虚拟机网卡调整为桥接模式(Bridged Adapter)使其获取独立路由器 IP,或在虚拟网络编辑器中配置端口转发规则(将宿主机的 2222 端口转发至虚拟机的 22 端口)。
- 云服务器(ECS / CVM / Lightsail 等):连接公网 IP 时必须确认绑定的公网 IP 有效,且网络无欠费停机。
四、第三步:放行防火墙规则与安全组
Ubuntu 默认配备了 UFW (Uncomplicated Firewall) 作为主机防护工具。安装 SSH 后,如果防火墙处于激活状态且未添加针对 22 端口的放行规则,所有外部连接都将被静默屏蔽。
1. 检查并配置 Ubuntu 本地 UFW 防火墙
在 Ubuntu 服务端检查防火墙当前工作状态:
sudo ufw status verbose
若状态显示为 Status: active,请检查规则列表中是否有针对 22/tcp 或 OpenSSH 的 ALLOW 规则。如果列表中没有放行记录,执行以下命令开启访问权限:
sudo ufw allow 22/tcp
# 或者基于应用名称放行
sudo ufw allow OpenSSH
# 重载规则使配置即时生效
sudo ufw reload
2. 检查云厂商入方向安全组规则
如果 Ubuntu 部署在阿里云、腾讯云、华为云或 AWS 等云平台上,云控制台的安全组(Security Group)位于操作系统之前,其防护优先级高于系统内 UFW。
必须登录对应云平台的管理控制台,找到该实例关联的安全组规则,检查“入方向规则(Inbound Rules)”是否允许:
- 协议类型:TCP
- 端口范围:22(或自定义端口)
- 授权对象:
0.0.0.0/0(允许任意 IP 连接)或指定客户端的公网静态出口 IP - 策略:允许(Accept / Allow)
五、第四步:调整 SSH 服务端配置文件与权限
如果网络和端口畅通,客户端发起的握手能够到达 Ubuntu,但连接立刻断开或在输入密码后提示 Permission denied (publickey,password),则属于 SSH 服务端的身份认证配置限制。
1. 编辑主配置文件 /etc/ssh/sshd_config
使用管理员权限打开配置文件:
sudo nano /etc/ssh/sshd_config
重点检查并确认以下几个关键配置项(注意去掉开头的 # 注释符):
| 配置项参数 | 默认值 / 易错表现 | 排查与调整方案 |
|---|---|---|
Port |
默认为 22 |
若自定义为非 22 端口(如 2222),客户端连接必须加 -p 2222 参数。 |
ListenAddress |
默认为 0.0.0.0(监听所有网卡) |
切勿设置为 127.0.0.1,否则拒绝除本机以外的全部远程请求。 |
PermitRootLogin |
prohibit-password |
Ubuntu 官方镜像默认禁止 root 密码远程登录。如确需使用 root 登录,需改为 yes;常规推荐使用普通 sudo 用户登录。 |
PasswordAuthentication |
yes(部分云镜像预设为 no) |
若设为 no,系统将全面禁用密码输入,必须通过 SSH 密钥对才能登录。使用密码登录时需设为 yes。 |
/etc/ssh/sshd_config.d/*.conf 目录机制。如果主配置文件配置正确但依旧不生效,请检查该目录下是否存在名为 50-cloud-init.conf 的覆写文件,检查里面是否强制设置了 PasswordAuthentication no。
2. 配置文件语法测试与服务重载
修改配置文件后,切勿直接盲目重启服务。先运行测试命令检查是否存在拼写错误:
sudo sshd -t
如果终端没有产生任何输出,表明配置文件语法完全合格。此时执行重启命令让修改生效:
sudo systemctl restart ssh
3. 检查公钥与 .ssh 目录权限
如果采用公钥认证(SSH Key)登录,OpenSSH 对文件权限有极度严格的校验机制(StrictModes)。权限若过于宽松(如允许其他用户读取或修改),sshd 会出于安全考虑自动忽略该公钥,导致认证失败:
# 修复用户家目录 .ssh 权限为 700
chmod 700 ~/.ssh
# 修复公钥授权文件权限为 600
chmod 600 ~/.ssh/authorized_keys
# 确保目录与文件的所有权归当前用户
chown -R $USER:$USER ~/.ssh
六、第五步:客户端常见报错针对性处理
在排查过程中,客户端终端给出的错误回执是定位问题的最精确依据。结合详细日志参数 -v 可以更清晰地观察握手细节:
ssh -v user@192.168.1.120
1. 报错:Host key verification failed
原因:Ubuntu 系统近期重装过、重新生成了主机密钥,或者当前 IP 曾被局域网内其他设备占用。客户端本地的 known_hosts 记录的旧密钥指纹与服务器当前指纹不吻合,出于防范中间人攻击(MITM)的机制中断连接。
解决方案:在客户端机器上清除针对该 IP 的缓存记录:
ssh-keygen -R 192.168.1.120
清除完成后重新执行 ssh 连接,输入 yes 确认并保存新主机的公钥指纹即可。
2. 报错:Permission denied (publickey,password)
原因:身份验证完全失败。通常有两种情况:
- 目标用户名为
root,但服务器sshd_config中未开启PermitRootLogin yes; - 服务端设置了
PasswordAuthentication no,且客户端没有匹配的私钥文件; - 输入的用户密码确实错误,或连续输错多次导致触发了防暴破限制(如安装了 fail2ban)。
3. 报错:Connection reset by peer
原因:连接请求已经与服务端握手,但被服务端的访问控制策略(如 /etc/hosts.deny、TCP Wrappers)主动掐断,或 sshd 进程在分配伪终端时发生内部异常崩溃。
解决方案:在 Ubuntu 服务端查看实时系统日志定位具体中断根因:
sudo journalctl -u ssh -e --no-pager
七、总结:SSH 远程连接故障速查清单
当遇到 Ubuntu 安装 SSH 无法远程连接的问题时,保持清晰的层级排查思路是解决问题的核心。您可以依照下表逐一核实:
| 排查层级 | 检查项 | 关键验证命令 | 合格指标 |
|---|---|---|---|
| 服务层 | openssh-server 进程 | sudo systemctl status ssh |
显示 active (running) |
| 端口层 | 端口 22 本地监听 | sudo ss -tulpn | grep :22 |
监听在 0.0.0.0:22 |
| 网络层 | 目标主机连通性 | ping <目标IP> |
正常收发 ICMP 报文,无丢包 |
| 防火墙 | 主机 UFW 状态 | sudo ufw status |
22/tcp 规则为 ALLOW |
| 安全组 | 云平台安全组规则 | 云控制台检查入方向规则 | TCP 22 端口允许通行 |
| 配置层 | 密码与 root 权限 | /etc/ssh/sshd_config |
允许指定登录方式,语法测试无误 |
| 权限层 | .ssh 密钥目录 | ls -ld ~/.ssh ~/.ssh/authorized_keys |
目录 700,公钥文件 600 |
按照以上步骤逐一验证后,无论是全新的虚拟机实验环境,还是正式生产运行的云端 Ubuntu 实例,均能彻底解决安装 SSH 后远程连接失败的各类故障。
免责声明:本文内容仅供参考,不代表本站观点。转载或引用请注明出处。









