最近搬瓦工 KiwiVM 面板里的Assistant Amy好像升级了，所以来试试看。
这个功能从买搬瓦工到现在就从来没有用过，以为它只是一个普通的 AI 聊天窗口，最多帮忙解释一下 Linux 命令。但今天实际打开看了一下，它不是单纯聊天，而是直接集成在 KiwiVM 面板里的 VPS 助手。
Amy 自己的介绍里写得很直接：它可以诊断 VM、检查控制台、运行命令，并且在需要的时候执行 KiwiVM 控制面板相关操作。
对于很多老手来说，这可能只是多了一个方便工具。但我感觉这个功能 对 VPS 新手来说算是很有用了，遇到服务器一些解决不了的问题时，可以直接用中文描述现象，让它帮你按顺序排查。可以说这个功能大大降低了新手的学习成本。
谁没有第一次用服务器的时候呢，想当初我开的第一台机我连怎么用finalshell连接都不会，最后还是在网上搜索了很久才解决的。所以这次我主要测试的是 VPS 连接问题。因为这是新手最常遇到，也最容易慌的场景。
比如：
- 服务器到底是不是正常在线？
- ping 通了，为什么 SSH 还是连不上？
- SSH 服务有没有运行？
- 防火墙有没有挡住端口？
- 修改 SSH 端口会不会把自己锁在外面？
- 最近有没有异常登录尝试？
一、打开 Amy
在 KiwiVM 面板左侧菜单里可以看到 Assistant Amy，点进去以后会弹出一个独立窗口。
可以看到界面里的提示是：
Hello! I’m Amy, your VPS assistant. I can diagnose the VM, inspect the console, run commands, and perform KiwiVM control panel actions when needed. How can I assist?
您好！我是您的VPS助理Amy。我可以诊断虚拟机、检查控制台、运行命令，并在需要时执行KiwiVM控制面板操作。我能帮您什么？
下面的测试没有用复杂英文，也没有提前准备命令，单纯直接用中文问它，看它能不能理解并给出实际排查思路。
二、让 Amy 检查 VPS 当前状态
遇到 VPS 出问题时，我以前很容易第一反应就是重启。但很多时候重启并不能解决问题，反而会把问题现场清掉。
所以第一步我先让 Amy 做一次基础检查。
直接用中文问：
请帮我检查这台 VPS 当前是否正常在线，包括系统负载、内存、磁盘、网络状态和 SSH 状态。如果发现异常，请告诉我可能的原因。
检查完成：这台 VPS 当前看起来是正常在线的 ✅
- 运行状态：RUNNING，系统已正常启动，运行时间约 11 小时 29 分
- 公网 IPv4：`80.251.**.**`
- 公网连通性：
- Ping 可达，丢包率 0%
- SSH 端口 `22/tcp` 从公网可达
- SSH 状态：
- `sshd.service` 正在运行
- 正在监听 `0.0.0.0:22` 和 `[::]:22`
- 配置允许密码登录、公钥登录、root 登录
- 系统负载：
- load average：`0.00 0.00 0.00`
- CPU 基本空闲，未发现 CPU throttling
- 内存：
- 总内存约 2023 MB
- 已用约 374 MB
- 可用约 1649 MB
- Swap 总量 1024 MB，当前使用 0 MB
- 磁盘：
- 根分区 `/`：38G 总量，已用 2.0G，使用率 6%
- `/boot`：使用率 10%
- 未发现磁盘空间压力
- 未发现磁盘 I/O 限速
- 网络配置：
- `eth0` 已 UP
- IP：`80.251.**.**/22`
- 默认网关：`80.251.**.**`
- 防火墙 iptables INPUT/OUTPUT/FORWARD 默认 ACCEPT，没有明显拦截规则
- 服务状态：
- NetworkManager、sshd、qemu guest agent、chronyd、crond 均正常运行
- `x-ui.service` 也在运行，并监听 `22092`、`2096` 等端口
目前没有发现明显异常。IP 没有被 nullroute/黑洞，服务也没有被暂停，未检测到政策违规状态。
你也可以自行复测公网状态：
- Ping：
https://ping.pe/80.251.**.**
- SSH 端口 22：
http://tcp.ping.pe/80.251.**.**:22
结论：VPS 当前在线且状态健康，SSH 可从公网访问。
这个问题适合用在任何不确定服务器状态的时候。
比如你觉得机器卡了、服务打不开、SSH 偶尔断开，都可以先让 Amy 看一遍基础状态。
它主要可以帮忙确认这些内容：
- VPS 是否正常运行；
- CPU / 负载是否异常；
- 内存是否紧张；
- 磁盘是否快满；
- 网络状态是否正常；
- SSH 服务是否正常；
- 系统日志里有没有明显错误。
以前这些内容需要自己登录 SSH 后分别执行命令查看。现在可以先让 Amy 做第一轮检查。
这个功能对新手比较友好，因为很多人不是不会复制命令，而是不知道第一步该查什么。
三、ping 通但 SSH 连不上，让 Amy 按步骤排查
第二个场景是我觉得最常见的：服务器能 ping 通，但是 SSH 连不上。
很多新手会误以为 ping 通就代表服务器没问题。实际上 ping 走的是 ICMP，SSH 走的是 TCP。ping 通只能说明服务器对 ICMP 有回应，不代表 SSH 端口一定能连上。
直接用中文问：
我现在可以 ping 通这台 VPS，但是 SSH 连接不上。请帮我按步骤排查原因，重点检查 SSH 服务、SSH 端口、防火墙规则和网络连通性。
我已按步骤排查完了。结论先说：VPS 端 SSH 服务本身是正常的，22 端口从公网可达，防火墙没有阻断。
如果你本地仍然 SSH 连不上，更可能是本地网络/运营商到该 IP:22 的路径问题、客户端参数/用户名密码/密钥问题，或临时被外部扫描连接干扰。
## 1. VPS 基础在线状态
- VPS 状态：RUNNING
- 公网 IPv4：`80.251.**.**`
- 没有 nullroute / 黑洞
- 没有暂停、没有检测到政策违规
- 系统负载：`0.00 0.00 0.00`
- 内存、磁盘都正常，没有资源压力
## 2. SSH 服务状态
`sshd.service` 当前状态：
- active running
- 已运行约 11 小时
- 配置语法检查通过：`sshd_config OK`
有效 SSH 配置里关键项如下：
port 22
listenaddress 0.0.0.0:22
listenaddress [::]:22
permitrootlogin yes
passwordauthentication yes
pubkeyauthentication yes
authenticationmethods any
maxstartups 10:30:100
说明：
- SSH 端口是 22
- 同时监听 IPv4 和 IPv6
- 允许 root 登录
- 允许密码登录
- 允许公钥登录
- 配置文件没有语法错误
## 3. SSH 端口监听状态
系统内部确认 SSH 正在监听：
0.0.0.0:22 sshd
[::]:22 sshd
这表示 VPS 内部 SSH 端口没有问题，不是 sshd 没启动或只监听本地地址导致的。
## 4. 防火墙规则
检查结果：
- `firewalld`：inactive
- iptables 默认策略：
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
没有看到阻断 22 端口的规则。
所以目前看，VPS 内部防火墙没有拦截 SSH。
## 5. 公网连通性测试
我从外部公网探测了这台 VPS：
- Ping：可达
- TCP 22：可达
- SSH banner：能读到
外部探测返回的 SSH banner 是：
SSH-2.0-OpenSSH_9.9
这说明从公网至少有探测节点可以正常连到你的 `80.251.**.**:22`，并且 sshd 有响应。
你也可以自行复测：
- Ping：
https://ping.pe/80.251.**.**
- TCP 22：
http://tcp.ping.pe/80.251.**.**:22
## 6. 发现的可疑情况
SSH 日志里看到来自 `91.92.40.43` 的大量失败登录尝试，例如：
Failed password for root from 91.92.40.43
Invalid user admin
Invalid user deploy
Invalid user bob
Invalid user hadoop
并且当前还有一些到 22 端口的 `SYN-RECV` 连接来自同一个 IP：
80.251.**.**:22 91.92.40.43:xxxxx SYN-RECV
这看起来像是常见的 SSH 扫描/爆破尝试。
目前数量不算特别夸张，`sshd` 也没有被打满，但它可能会造成短时间连接变慢或偶发连接失败，尤其是在 `MaxStartups` 限制触发时。
## 当前判断
服务器端目前没有发现这些问题：
- SSH 服务未启动：没有
- SSH 端口没监听：没有
- SSH 配置错误：没有
- 防火墙阻断：没有
- IP 被黑洞/nullroute：没有
- VPS 资源耗尽：没有
- 公网 22 端口完全不可达：没有
更可能的原因是：
1. 你本地网络或运营商阻断/干扰了出站 TCP 22
2. 你连接的端口、用户名、密码或密钥不正确
3. 本地 SSH 客户端报错属于认证问题，而不是网络问题
4. SSH 正在被扫描，偶发触发连接限制
5. 如果你用的是公司、校园、机场、代理网络，可能禁止 22 端口
## 建议你下一步确认
你可以把你本地 SSH 的具体报错发给我，例如：
Connection timed out
Connection refused
Permission denied
No route to host
Connection reset by peer
Permission denied (publickey,password)
不同报错对应的原因不一样。
如果你愿意，我也可以继续帮你做两件事之一：
1. 给 SSH 增加一个备用端口，比如 `2222`，降低被本地网络屏蔽 22 端口影响的概率。
2. 临时封禁正在扫描的 IP `91.92.40.43`，减少 SSH 扫描干扰。
这个场景下，Amy 可以帮忙把问题拆开。
一般来说，ping 通但 SSH 连不上，可能有这些原因：
- SSH 服务没有运行；
- SSH 端口不是默认 22；
- SSH 正常监听，但防火墙没有放行；
- SSH 配置被改错；
- 禁用了 root 登录或密码登录；
- 本地网络到服务器 TCP 端口不通；
- 登录失败太多，被安全规则临时限制。
这个地方 Amy 的价值不是简单给一个命令，而是把排查顺序列出来。
比较合理的顺序应该是：
- 先确认 VPS 是否在线；
- 再确认 SSH 服务是否运行；
- 再确认 SSH 实际监听哪个端口；
- 再看防火墙是否放行这个端口；
- 再判断是不是本地网络或外部线路问题；
- 最后检查 SSH 配置和登录方式。
这比一上来就重启或者重装系统稳很多。
四、让 Amy 检查防火墙有没有挡住 SSH
VPS 新手很容易在防火墙上翻车。
比如刚学会 ufw、iptables 或 firewalld，就想加几条规则提高安全性。但如果 SSH 端口没有提前放行，很可能规则一启用，自己就连不上了。
所以我继续问 Amy：
请帮我检查当前防火墙规则有没有可能挡住 SSH 连接。如果我要修改 SSH 端口，应该提前检查哪些地方，避免把自己锁在服务器外面？
我刚帮你检查了当前状态：现在的防火墙规则不会挡住 SSH 连接。✅
当前结果如下：
- VPS 公网 IP：`80.251.**.**`
- SSH 当前监听端口：`22`
- `sshd` 正在监听：
- `0.0.0.0:22`
- `[::]:22`
- `firewalld`：未运行 / inactive
- `iptables`：规则为空，默认 ACCEPT
- `nftables`：没有规则集
- 公网探测 SSH 端口 22：可连接
- SSH banner 正常返回：`SSH-2.0-OpenSSH_9.9`
你也可以用这个链接自己从外部复测 SSH 端口：
- http://tcp.ping.pe/80.251.**.**:22
---
如果你要修改 SSH 端口，建议提前检查这些地方，避免把自己锁在服务器外面：
### 1. 确认新端口没有被占用
当前已经在监听的端口包括：
- `22`：SSH
- `2096`：x-ui
- `22092`：x-ui
- `127.0.0.1:11111`
- `127.0.0.1:62789`
建议不要使用已经被占用的端口。可以选一个未使用的高位端口，比如 `2222`、`2022`、`22022` 等。
---
### 2. 不要直接替换端口，先双端口监听
安全做法是先让 SSH 同时监听旧端口和新端口，例如：
Port 22
Port 2222
确认新端口可以登录后，再考虑移除 `Port 22`。
---
### 3. 先放行防火墙，再改 SSH
你这台机器目前没有启用 firewalld/iptables/nftables 拦截，所以现在改端口本身不会被现有防火墙挡住。
但如果之后启用了防火墙，需要提前放行新端口，例如 firewalld 环境一般是：
firewall-cmd --permanent --add-port=2222/tcp
firewall-cmd --reload
如果用了 nftables 或 iptables，也要在对应规则里允许新端口。
---
### 4. AlmaLinux/RHEL 系系统要注意 SELinux
如果 SELinux 是 enforcing，新 SSH 端口可能还需要加入 `ssh_port_t`，例如：
semanage port -a -t ssh_port_t -p tcp 2222
如果端口已经存在于其他类型，可能需要用 `-m` 修改。
---
### 5. 修改后先检查配置语法
改完 SSH 配置后，先跑：
sshd -t
只有没有报错，再 reload SSH：
systemctl reload sshd
不要一上来就重启机器。
---
### 6. 保留当前连接或 KiwiVM 面板入口
修改端口时建议：
- 不要关闭当前 SSH 会话；
- 新开一个窗口测试新端口；
- 如果新端口登录成功，再移除旧端口；
- 万一出错，还可以通过 KiwiVM 的 Root Shell / Interactive 入口修复。
---
### 7. 用公网探测确认新端口开放
改完后要从公网测试新端口，不要只在服务器内部看监听。内部 `ss -tulnp` 只能说明服务在监听，不代表公网能连通。
例如如果新端口是 `2222`，需要确认：
ssh -p 2222 [email protected].**.**
或者用外部 TCP 测试。
---
### 8. 不建议同时修改多个 SSH 安全项
为了避免排障困难，建议不要同时做这些事：
- 改 SSH 端口；
- 禁用密码登录；
- 禁用 root 登录；
- 改防火墙默认策略；
- 改 SELinux；
- 重启网络服务。
最好一次只改一项，确认能登录后再继续。
---
如果你愿意，我也可以帮你按“安全双端口方式”修改，比如先让 SSH 同时监听 `22` 和你指定的新端口，公网确认新端口可用后，再由你决定是否关闭 22。
这个问题非常实用。
修改 SSH 端口之前，至少应该确认这些事情：
- 当前 SSH 正在监听哪个端口；
- 新端口是否已经写入 SSH 配置；
- 防火墙是否放行新端口；
- 旧的 SSH 连接先不要断开；
- 新端口能成功连接后，再考虑关闭旧端口；
- KiwiVM 控制台最好保持可用，防止自己被锁在外面。
Amy 如果能在操作前提醒这些风险，就比单纯给命令更有用。
我觉得这个功能对新手最大的帮助，就是可以减少一些低级但严重的错误。比如防火墙规则写错、SSH 端口没放行、登录方式改错，这些问题本身不复杂，但一旦把自己锁在外面，处理起来就麻烦了。
五、让 Amy 检查最近有没有异常 SSH 登录记录
除了连不上服务器，SSH 安全也很适合让 Amy 帮忙看。
VPS 开在公网以后，经常会遇到各种扫描和暴力尝试。很多新手平时不会主动看日志，也不知道日志里的 failed password、invalid user 这些记录代表什么。
直接用中文问：
请帮我检查这台 VPS 最近有没有异常 SSH 登录失败记录。如果有，请帮我总结来源、频率，并给出适合新手的基础安全建议。
我已检查最近 SSH 登录日志。结论：有异常 SSH 登录失败记录，表现为常见的自动化扫描/暴力破解尝试；暂未发现成功 SSH 登录记录。
## 检查范围
- 当前时间：`2026-06-18 06:11 UTC`
- VPS 已运行：约 11 小时 39 分钟
- 我查询了最近 24 小时的 `sshd` 日志；由于机器本次启动时间约 11 小时多，实际可见日志主要是本次开机以来的记录。
## SSH 服务状态
SSH 服务本身正常：
- `sshd.service`：active running
- 监听端口：`22`
- 当前 SSH 配置重点项：
Port 22
PermitRootLogin yes
PasswordAuthentication yes
PubkeyAuthentication yes
MaxAuthTries 6
MaxStartups 10:30:100
这说明目前 SSH 允许：
- root 直接登录
- 密码登录
- 公钥登录
从安全角度看，root + 密码登录 + 默认 22 端口比较容易被自动扫描器盯上。
## 最近失败登录统计
最近日志中共发现：
134 条 SSH 失败/异常认证相关记录
主要来源 IP：
111 次 91.92.40.43
2 次 91.92.40.12
2 次 43.128.81.242
2 次 34.14.46.90
2 次 212.227.235.203
1 次 41.42.214.101
1 次 185.226.197.30
1 次 101.126.135.131
最明显的是：
91.92.40.43
它贡献了绝大多数失败记录，属于高度可疑来源。
## 失败频率分布
按小时统计：
2026-06-17 20:00 2 次
2026-06-17 21:00 3 次
2026-06-17 23:00 2 次
2026-06-18 00:00 1 次
2026-06-18 01:00 2 次
2026-06-18 02:00 1 次
2026-06-18 03:00 4 次
2026-06-18 04:00 66 次
2026-06-18 05:00 51 次
2026-06-18 06:00 2 次
可以看到异常主要集中在：
- `04:00 - 05:00 UTC`
- `05:00 - 06:00 UTC`
这两个小时内尝试次数明显上升，符合自动化爆破/扫描特征。
## 被尝试的用户名
常见被尝试用户名包括：
admin 12 次
root 9 次
ubuntu 8 次
user 4 次
deployer 4 次
claude 4 次
bot 4 次
bob 4 次
azureuser 4 次
还包括很多常见弱口令扫描用户名，例如：
test
pi
www
web
repo
hadoop
elasticsearch
deploy
这进一步说明这些不是正常用户登录失败，而是互联网上常见的自动化 SSH 扫描。
## 是否发现成功 SSH 登录？
没有发现成功 SSH 登录记录：
Accepted password/publickey: 0 条
`last` 里也没有看到最近用户登录会话，只有系统启动记录。
所以目前看：
> 有暴力破解/扫描尝试，但没有证据显示 SSH 已被成功登录。
## 当前是否还有可疑连接？
检查时仍看到一些到 SSH 端口的半连接/尝试连接，来源包括：
91.92.40.43
35.205.166.70
其中 `91.92.40.43` 和前面的失败登录来源一致，仍然比较可疑。
## 风险判断
当前风险等级我会评估为：中等偏低到中等。
原因：
- ✅ 没发现成功登录
- ✅ SSH 服务正常
- ✅ 系统负载、内存没有异常
- ⚠️ 但 SSH 暴露在公网 `22` 端口
- ⚠️ 允许 root 登录
- ⚠️ 允许密码登录
- ⚠️ 已经被自动化扫描器盯上
如果 root 密码足够强，短期问题不大；但长期建议加固。
## 适合新手的基础安全建议
建议按优先级处理：
### 1. 使用强密码
如果你暂时还需要密码登录，root 密码一定要足够复杂：
- 至少 16 位以上
- 包含大小写字母、数字、符号
- 不要使用生日、手机号、常见单词、重复密码
### 2. 尽量改用 SSH 密钥登录
这是最推荐的方式。
做法是：
- 在你电脑上生成 SSH key
- 把公钥放到 VPS 的 `/root/.ssh/authorized_keys`
- 确认密钥可以登录后，再关闭密码登录
这样即使别人知道用户名，也很难爆破成功。
### 3. 禁止 root 直接 SSH 登录
更安全的做法是：
- 创建一个普通用户
- 给它 sudo 权限
- 用普通用户 SSH 登录
- 登录后再 `sudo -i` 切换 root
然后设置：
PermitRootLogin no
### 4. 关闭密码登录
确认 SSH 密钥能正常登录后，建议设置：
PasswordAuthentication no
这会大幅降低暴力破解风险。
### 5. 安装 Fail2ban
Fail2ban 可以自动封禁连续登录失败的 IP。
例如某个 IP 连续失败 5 次，就临时封禁 1 小时或更久。
这对新手很实用。
### 6. 限制 SSH 来源 IP
如果你有固定公网 IP，最安全的是只允许你的 IP 访问 SSH。
例如只允许你的家宽/公司 IP 访问 22 端口，其他全部拒绝。
不过这个方法需要小心：如果你自己的 IP 变化，可能会把自己锁在外面。
### 7. 可以增加一个备用 SSH 端口
比如额外监听 `2222` 或其他端口。
注意：改端口不能替代安全措施，但可以减少被默认扫描器扫到的次数。
更稳妥的方式是：
- 先保留 22
- 增加备用端口
- 测试备用端口能登录
- 再决定是否关闭 22
### 8. 定期检查登录日志
常用关注点：
- 是否有 `Accepted password`
- 是否有陌生 IP 成功登录
- 是否有大量 `Failed password`
- 是否有陌生用户被创建
- 是否有异常进程或计划任务
## 我建议你下一步做什么
比较稳妥的新手加固方案是：
1. 先安装并配置 Fail2ban
2. 临时封禁当前主要攻击源 `91.92.40.43`
3. 增加一个备用 SSH 端口，例如 `2222`
4. 确认备用端口能连上
5. 再逐步切换到密钥登录、关闭密码登录
如果你愿意，我可以继续帮你直接执行一个温和安全方案：
安装 Fail2ban + 封禁当前可疑 IP + 保持现有 SSH 配置不变，避免把你锁在外面。
这个问题可以让 Amy 帮忙做两件事。
第一，帮忙从日志里找重点。
比如有没有大量失败登录、是不是集中来自某些 IP、有没有 root 用户被反复尝试、有没有明显异常时间段。
第二，给出基础安全建议。
比如：
- 使用强密码；
- 优先使用 SSH key；
- 如果要禁用密码登录，先确认密钥可用；
- 可以考虑修改默认 SSH 端口；
- 可以使用 fail2ban 限制暴力尝试；
- 不需要的端口不要开放；
- 定期查看登录记录。
这类建议不算复杂，但对刚开始用 VPS 的用户比较实用。
六、让 Amy 生成一份 VPS 连接问题排查清单
最后我让 Amy 直接整理一份排查清单。
直接用中文问：
请帮我整理一份 VPS 连接问题排查清单，适合新手使用。场景包括：服务器无法 SSH、ping 通但端口不通、防火墙可能拦截、SSH 端口被修改、登录失败太多。请按照排查顺序列出来，并说明每一步的目的。
下面是一份适合新手使用的 VPS 连接问题排查清单，按推荐排查顺序整理。你可以从上到下一步步看，避免一开始就改防火墙或重装系统。
---
# VPS 连接问题排查清单
适用场景：
- VPS 无法 SSH
- 能 ping 通，但 SSH/网站端口不通
- 防火墙可能拦截
- SSH 端口被修改
- 登录失败太多，被限制或封禁
- 不确定是服务器问题还是本地网络问题
---
## 1. 确认 VPS 是否正在运行
目的：先确认机器本身有没有开机。
检查内容：
- VPS 状态是否是 Running / Online
- 是否刚刚重启、迁移、重装
- 是否被暂停、欠费、封禁、nullroute
- 是否还挂载着 ISO 导致没从系统盘启动
如果 VPS 是 stopped / offline，SSH 一定连不上。
常见现象：
ssh: connect to host x.x.x.x port 22: Connection timed out
或：
No route to host
---
## 2. 确认连接信息是否正确
目的：排除最常见的人为错误。
确认这些信息：
- IP 地址是否正确
- 用户名是否正确，例如：
- `root`
- `ubuntu`
- `debian`
- `centos`
- SSH 端口是否正确
- 密码或密钥是否正确
- 是否连到了旧 IP
- 是否 VPS 迁移后 IP 已变化
常见 SSH 命令格式：
ssh root@你的服务器IP
如果端口不是 22，例如 2222：
ssh -p 2222 root@你的服务器IP
---
## 3. 先测试 ping 是否可达
目的：判断基础网络是否通。
可以在本地电脑执行：
ping 你的服务器IP
结果分两种：
### 情况 A：ping 不通
可能原因：
- VPS 没开机
- IP 被 nullroute
- VPS 防火墙禁 ping
- 本地网络到 VPS 不通
- 服务器网络配置错误
注意：
ping 不通不一定代表服务器挂了，因为有些防火墙会禁 ICMP。
### 情况 B：ping 通
说明：
- VPS IP 至少在网络层可达
- 但不代表 SSH 一定正常
- 接下来要检查端口
---
## 4. 测试 SSH 端口是否开放
目的：判断是不是 SSH 端口不通。
默认 SSH 端口是 `22`。
可以测试：
nc -vz 你的服务器IP 22
或：
telnet 你的服务器IP 22
也可以用网页工具测试：
http://tcp.ping.pe/你的服务器IP:22
### 如果端口通
通常会看到类似：
succeeded
或者能看到 SSH banner：
SSH-2.0-OpenSSH_x.x
说明：
- 服务器公网 22 端口可达
- SSH 服务大概率在运行
- 如果还是登不上，多半是认证问题、用户名密码问题、密钥问题或登录限制
### 如果 ping 通但 22 端口不通
可能原因：
- SSH 服务没启动
- SSH 端口被改了
- 防火墙拦截了 22
- 云平台安全组/控制面板防火墙拦截
- sshd 只监听本地地址
- 服务器负载过高导致无响应
---
## 5. 确认 SSH 端口有没有被修改
目的：避免一直连错端口。
SSH 默认端口是：
22
但有些系统会修改到：
2222
22022
10022
如果你有控制面板的 Root Shell，可以检查：
ss -lntp | grep ssh
常见正常结果：
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=xxx))
如果看到：
0.0.0.0:2222
说明 SSH 端口是 `2222`，连接时要用：
ssh -p 2222 root@你的服务器IP
---
## 6. 检查 SSH 服务是否运行
目的：确认 sshd 有没有启动或崩溃。
在服务器控制面板 Root Shell 里检查：
systemctl status sshd
有些系统服务名叫 `ssh`：
systemctl status ssh
正常状态通常是：
active (running)
如果没有运行，可以尝试：
systemctl restart sshd
或：
systemctl restart ssh
再检查：
systemctl status sshd
---
## 7. 检查 SSH 配置是否有错误
目的：避免配置写错导致 sshd 启动失败。
检查配置语法：
sshd -t
如果没有输出，通常表示配置语法正常。
如果有报错，例如：
Bad configuration option
说明 `/etc/ssh/sshd_config` 里有错误，需要修复后再重启 SSH。
常见需要检查的配置项：
Port 22
PermitRootLogin yes
PasswordAuthentication yes
PubkeyAuthentication yes
ListenAddress 0.0.0.0
注意：
如果你还没有确认密钥可以登录，不建议直接关闭密码登录。
---
## 8. 检查系统防火墙
目的：确认服务器内部有没有拦截 SSH 端口。
常见防火墙有：
- firewalld
- ufw
- iptables
- nftables
### firewalld
systemctl status firewalld
firewall-cmd --list-all
如果 SSH 端口不是 22，例如 2222，需要放行：
firewall-cmd --permanent --add-port=2222/tcp
firewall-cmd --reload
### ufw
ufw status
放行 SSH：
ufw allow 22/tcp
或放行自定义端口：
ufw allow 2222/tcp
### iptables
iptables -S
iptables -L -n -v
重点看有没有 DROP / REJECT 规则拦截 22 或你的 SSH 端口。
---
## 9. 检查云平台/控制面板层面的网络限制
目的：有些拦截不在系统里，而在服务商层面。
需要确认：
- VPS 是否被 nullroute
- 是否有安全组规则
- 是否有控制面板防火墙
- 是否被 DDoS 防护临时封禁端口
- 是否服务被暂停
- 是否 IP 更换后 DNS 没更新
如果系统里 SSH 正常、端口监听正常、防火墙也没拦，但公网不通，就要重点怀疑这一层。
---
## 10. 检查是否因为登录失败太多被限制
目的：判断是否被 Fail2ban、DenyHosts 或 sshd 自身限制。
如果你多次输错密码，可能被临时封禁。
检查 Fail2ban：
fail2ban-client status
查看 sshd jail：
fail2ban-client status sshd
如果你的 IP 被封，可以解封：
fail2ban-client set sshd unbanip 你的本地公网IP
也可以检查日志：
journalctl -u sshd --since "1 hour ago"
或：
grep "Failed password" /var/log/auth.log
CentOS/RHEL 系：
grep "Failed password" /var/log/secure
---
## 11. 区分“连不上”和“登录失败”
目的：不同报错代表完全不同的问题。
### 报错：Connection timed out
ssh: connect to host x.x.x.x port 22: Connection timed out
常见原因：
- 防火墙丢弃连接
- 端口未开放
- 路由问题
- 服务商层面拦截
- 本地网络阻断 22 端口
### 报错：Connection refused
ssh: connect to host x.x.x.x port 22: Connection refused
常见原因：
- 服务器能到，但端口没人监听
- SSH 服务没启动
- SSH 监听的是其他端口
### 报错：Permission denied
Permission denied, please try again.
常见原因：
- 用户名错误
- 密码错误
- 密钥错误
- root 登录被禁用
- 密码登录被禁用
### 报错：Permission denied (publickey)
Permission denied (publickey)
常见原因：
- 服务器只允许密钥登录
- 本地没有使用正确私钥
- 公钥没有写入服务器
- 用户名不对
### 报错：Connection reset by peer
Connection reset by peer
常见原因：
- sshd 主动断开
- Fail2ban 或安全软件拦截
- MaxStartups 限制
- 服务器负载过高
- 网络中间设备干扰
---
## 12. 从外部第三方网络测试
目的：判断是不是你本地网络的问题。
建议用外部工具测：
- Ping：
https://ping.pe/你的服务器IP
- TCP 端口：
http://tcp.ping.pe/你的服务器IP:22
如果第三方能连通，但你本地不能连：
可能是：
- 你本地网络屏蔽 22 端口
- 公司/校园/机场网络限制 SSH
- 本地防火墙或安全软件拦截
- 运营商路由问题
可以尝试：
- 换网络
- 用手机热点
- 换一个 SSH 端口
- 使用 VPN 或代理网络
---
## 13. 检查服务器资源是否耗尽
目的：资源耗尽时 SSH 可能变慢或拒绝连接。
检查负载：
uptime
top
检查内存：
free -h
检查磁盘：
df -h
检查 inode：
df -i
如果磁盘 100%，可能导致：
- SSH 登录失败
- 无法写入日志
- 服务异常
- 系统响应很慢
---
## 14. 检查 SSH 登录日志
目的：判断是否有爆破、误操作、成功登录或异常登录。
Debian/Ubuntu：
grep sshd /var/log/auth.log
CentOS/RHEL/Alma/Rocky：
grep sshd /var/log/secure
systemd：
journalctl -u sshd --since "24 hours ago"
重点看：
Failed password
Invalid user
Accepted password
Accepted publickey
Connection closed
maximum authentication attempts exceeded
如果看到大量：
Failed password for root
Invalid user admin
Invalid user test
说明 VPS 正在被自动扫描或爆破。
---
# 推荐排查顺序总结
新手可以按这个顺序走：
1. 确认 VPS 是否开机
- 目的：排除机器没运行
2. 确认 IP、用户名、端口是否正确
- 目的：排除连错目标
3. 测试 ping
- 目的：确认基础网络是否可达
4. 测试 SSH 端口
- 目的：判断端口是否开放
5. 检查 SSH 服务状态
- 目的：确认 sshd 是否正常运行
6. 检查 SSH 实际监听端口
- 目的：确认端口是否被修改
7. 检查 SSH 配置语法
- 目的：排除配置错误导致服务异常
8. 检查系统防火墙
- 目的：确认端口没有被系统拦截
9. 检查控制面板/服务商网络限制
- 目的：确认不是平台层面拦截
10. 检查是否被 Fail2ban 或安全软件封禁
- 目的：排除登录失败太多导致的封禁
11. 检查 SSH 日志
- 目的：确认失败原因和是否有异常登录
12. 换网络或使用外部工具测试
- 目的：判断是否为本地网络问题
13. 检查系统资源
- 目的：确认不是 CPU、内存、磁盘耗尽导致 SSH 异常
---
# 新手安全建议
如果你经常遇到 SSH 扫描或登录失败很多，建议做这些基础加固：
1. 使用强密码
- 不要用简单密码、生日、常见单词
2. 尽量使用 SSH 密钥登录
- 比密码安全很多
3. 安装 Fail2ban
- 自动封禁连续登录失败的 IP
4. 不要轻易关闭当前 SSH 端口
- 修改 SSH 配置前，最好先开一个备用端口并测试成功
5. 不要在没确认密钥可登录前关闭密码登录
- 否则可能把自己锁在外面
6. 定期检查登录日志
- 关注是否有陌生 IP 成功登录
7. 如有固定 IP，可以限制 SSH 来源
- 只允许自己的 IP 访问 SSH，安全性最高，但要小心 IP 变化
---
如果你愿意，我也可以直接帮你把这台 VPS 按这份清单实际检查一遍，并给出具体结论。
这个用法我觉得很适合保存下来。
因为 VPS 连接问题不是只会遇到一次。下次如果再出现类似情况，可以直接按照清单检查，而不是每次都重新想一遍。
我比较希望 Amy 输出的清单包含这些步骤：
- 先看 KiwiVM 面板里 VPS 是否运行；
- 检查控制台是否能进入；
- 检查系统负载、内存、磁盘是否异常；
- 检查 SSH 服务是否运行；
- 检查 SSH 监听端口；
- 检查防火墙是否放行 SSH 端口；
- 检查 sshd 配置有没有改错；
- 检查是否禁用了当前登录方式；
- 检查最近是否有大量登录失败；
- 判断是否为本地网络或外部 TCP 阻断。
这类清单的好处是，它能让新手先按顺序排查，而不是一遇到问题就重启、重装或者乱改配置。
七、这次测试下来，Amy 具体能帮我做什么？
简单总结一下，这次测试里我觉得 Amy 比较适合做这些事情：
- 第一，检查 VPS 当前状态。
比如系统负载、内存、磁盘、网络和 SSH 状态。遇到服务器异常时，可以先让它做第一轮检查。
- 第二，排查 SSH 连不上。
特别是 ping 通但 SSH 不通这种情况，Amy 可以引导用户继续检查 TCP 端口、SSH 服务、防火墙和配置文件。
- 第三，检查防火墙风险。
如果用户准备改 SSH 端口、启用防火墙、调整 iptables 规则，可以先让 Amy 检查是否有把自己锁在外面的风险。
- 第四，查看 SSH 登录异常。
它可以帮忙检查最近是否有异常登录失败记录，并把日志里的重点信息总结出来。
- 第五，整理排查清单。
这个我觉得很实用。以后遇到类似问题，可以让 Amy 按固定流程生成检查步骤，避免自己乱试。
不过使用 Amy 的时候也要注意几件事。涉及删除文件、清空防火墙、关闭 SSH、修改登录方式、重装系统这类高风险操作时，不要直接无脑执行。最好先让 Amy 解释命令作用，确认没有问题再操作。