SSH连接失败90%因sshd未运行或防火墙拦截：先用systemctl status sshd确认active (running)，再用ss -tlnp | grep :22验证监听0.0.0.0:22，最后检查ufw/firewalld及云安全组是否放行22端口。
Linux 上 SSH 远程连接失败，90% 的情况不是密码错了，而是 sshd 根本没在跑，或者防火墙拦住了 22 端口。先确认服务状态和端口监听，再折腾密钥或密码——顺序反了只会浪费时间。
怎么确认 sshd 服务真的在运行
很多人执行 systemctl start sshd 就以为搞定了，但没验证实际状态。服务可能启动失败、配置语法错误、或被其他进程占了端口。
- 用
systemctl status sshd看输出里有没有active (running)；如果显示failed或inactive，别跳步，先看日志：sudo journalctl -u sshd --since "1 hour ago" | tail -20 -
ps aux | grep sshd应该至少看到两个进程：一个 root 权限的主进程，一个带@notty的子进程；如果只看到 grep 自己，说明没起来 -
sudo ss -tlnp | grep :22必须有输出，且State是LISTEN，Process列要显示sshd；如果显示Cannot open netlink socket，说明你没加sudo
为什么 Xshell 连接超时，而不是报“拒绝访问”
超时 = 网络层没通，大概率是防火墙或网络配置问题；拒绝访问 = SSH 服务收到了请求但拒绝了登录，才是认证环节的问题。
- Ubuntu 默认用
ufw：必须执行sudo ufw allow OpenSSH（比allow 22更稳妥，它会自动适配sshd_config里的实际端口） - CentOS/RHEL 默认用
firewalld：不能只跑firewall-cmd --add-port=22/tcp，得加--permanent再--reload，否则重启就失效 - 云服务器（如阿里云、腾讯云）额外要检查安全组：控制台里必须手动放行 22 端口（或自定义端口），光配系统防火墙没用
- 虚拟机桥接模式下，宿主机 ping 不通虚拟机 IP，先查
ip addr show输出里有没有inet地址，没有就说明网卡根本没获取到 IP
sshd_config 改完不生效？重启只是第一步
改完配置文件不重启服务当然无效，但只重启还不够——常见坑是权限错误或语法错误导致服务启动回退到默认配置。
- 改之前先备份：
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak - 改完用
sudo sshd -t检查语法，返回空行才表示 OK；如果有报错，按提示定位行号修正 - 重启后立刻验证：
sudo systemctl restart sshd && sudo systemctl status sshd，不要中间切窗口 - 关键配置项注意大小写和空格：
PasswordAuthentication yes不能写成passwordauthentication yes，也不能漏掉yes前面的空格
公钥登录失败，八成是 ~/.ssh 目录权限太松
OpenSSH 对权限极其敏感。只要 ~/.ssh 或 ~/.ssh/authorized_keys 权限高于规定值，就会静默禁用公钥认证，连日志都不报错。
-
~/.ssh目录必须是700（drwx------），不是755也不是777 -
~/.ssh/authorized_keys文件必须是600（-rw-------），不能是644 - 用户家目录（
~）本身不能是777，否则 sshd 会拒绝读取.ssh下任何内容 - 检查命令：
ls -ld ~ ~/.ssh ~/.ssh/authorized_keys，三者权限必须严格匹配上述要求
最常被忽略的是：改完 sshd_config 后忘记 sshd -t 验证，或者把公钥复制到了错误用户的 authorized_keys 里——比如你是用 ubuntu 用户登录的，却把公钥塞进了 root 的 ~/.ssh/authorized_keys。
