connection refused 通常因 sshd 未运行或仅监听 127.0.0.1，需先用 systemctl status sshd 和 ss -tlnp | grep :22 确认状态与监听地址，再检查 listenaddress、防火墙、云安全组、认证日志、权限及 selinux。
sshd服务没运行或没监听外部端口
连接直接报 Connection refused，八成是服务根本没起来，或者只绑了本地回环。先别急着改配置，登录服务器控制台（VNC、救援模式或物理终端），执行：
-
systemctl status sshd—— 看是否为active (running)；若显示inactive或failed，用sudo systemctl start sshd启动 -
ss -tlnp | grep :22—— 关键看输出里有没有0.0.0.0:22或[::]:22；如果只有127.0.0.1:22，说明外部连不上，得检查/etc/ssh/sshd_config中的ListenAddress是否被设成127.0.0.1，注释掉或改成0.0.0.0后重启服务 - 改过端口？比如设了
Port 2222，那客户端必须显式加-p 2222，否则默认连 22 就必然失败
防火墙或云安全组拦住了22端口
能 ping 通但 telnet/nc 连不上 22，大概率是中间有策略拦截。这个环节最容易漏掉云平台那一层。
- 本地测试：在客户端运行
nc -zv 服务器IP 22；若显示Connection refused，说明服务未监听或被拒；若超时（timed out），就是被丢包了 - 查服务端防火墙：
sudo ufw status（Ubuntu）或sudo firewall-cmd --list-all（CentOS/RHEL）；确认 22 端口或ssh服务已放行 - 云服务器（阿里云、腾讯云等）必须单独检查安全组——它和系统防火墙是两套独立规则；入方向 TCP 22（或自定义端口）必须显式添加，源 IP 建议先设为
0.0.0.0/0快速验证
认证阶段卡住：密码输对也拒绝
能连上端口、弹出密码提示，但输完就断，问题出在认证逻辑。日志比猜更准。
- 服务端实时盯日志：
sudo tail -f /var/log/auth.log（Debian/Ubuntu）或sudo tail -f /var/log/secure（CentOS/RHEL）；新起一次连接，看最后几行具体报什么，比如User xxx from xxx not allowed because account is locked或no matching key exchange method - 客户端加
-v看协商细节：ssh -v user@host；重点扫debug1: kex_input_ext_info和debug1: Authentications that can continue:行，密钥类型不兼容（如新客户端连老 OpenSSH）会在这里暴露 - 用户本身状态要合法：
getent passwd username确认存在，passwd -S username看是否被锁，grep username /etc/passwd确保 shell 是/bin/bash而非/sbin/nologin
.ssh目录权限错误导致密钥登录失败
OpenSSH 对权限极其敏感，哪怕只是 ~/.ssh 目录是 755，也会静默拒绝密钥登录，且不给明确提示。
- 服务端检查：
ls -ld ~/.ssh应为drwx------（即 700）；ls -l ~/.ssh/authorized_keys应为-rw-------（600）；chown -R $USER:$USER ~/.ssh+chmod 700 ~/.ssh+chmod 600 ~/.ssh/authorized_keys是最稳妥的修复组合 - 客户端私钥也得守规矩：
chmod 600 ~/.ssh/id_rsa；若私钥带密码但输错，也会卡在Enter passphrase for key后无响应 - SELinux 启用时可能干扰：
sestatus查状态，临时setenforce 0测试；若恢复连接，需setsebool -P sshd_can_network_connect on
Connection refused 和 Permission denied 看似简单，但背后可能是 ListenAddress 写死、安全组漏配、authorized_keys 权限多了一个 r、甚至 SELinux 的布尔值没开——每个点都得亲手验证，不能跳步。
