1. 初识SSH连接失败的两种典型错误第一次遇到SSH连接失败时屏幕上冷冰冰的Connection refused或Permission denied提示确实会让人手足无措。这两种错误看似简单实则代表了SSH连接过程中不同阶段的故障。Connection refused就像按门铃却无人应答——要么屋里没人SSH服务未运行要么大门紧锁端口被防火墙拦截。而Permission denied则是主人开了门却把你挡在门外——认证环节出了问题可能是用户名/密码错误也可能是权限配置不当。我处理过最棘手的一个案例是某台服务器先报Connection refused解决后又出现Permission denied。这种连环故障往往意味着多个层面的配置问题需要系统性地排查。2. 解决Connection refused错误2.1 检查SSH服务状态当看到ssh: connect to host [IP] port 22: Connection refused时首先要确认目标服务器是否运行着SSH服务。执行以下命令检查# 检查SSH进程是否运行 ps -e | grep sshd # 检查SSH服务状态系统使用systemd时 systemctl status sshd # 旧版系统使用init.d时的检查方式 service sshd status如果服务未运行启动命令如下# 安装openssh-server如未安装 sudo apt install openssh-server # Ubuntu/Debian sudo yum install openssh-server # CentOS/RHEL # 启动服务 sudo systemctl start sshd sudo systemctl enable sshd # 设置开机自启2.2 验证端口监听情况SSH默认使用22端口确认该端口是否处于监听状态sudo netstat -tulnp | grep :22 # 或使用更现代的ss命令 sudo ss -tulnp | grep sshd如果没有输出可能是配置文件修改了默认端口。检查/etc/ssh/sshd_config中的Port配置项grep ^Port /etc/ssh/sshd_config2.3 排查防火墙拦截即使SSH服务正常运行防火墙规则也可能拦截连接。常见防火墙工具检查方法UFW防火墙Ubuntusudo ufw status sudo ufw allow 22 # 如果22端口被拒绝firewalldCentOS/RHELsudo firewall-cmd --list-all sudo firewall-cmd --add-servicessh --permanent sudo firewall-cmd --reloadiptables传统Linuxsudo iptables -L -n云服务器还需检查安全组规则确保入方向放行SSH端口。3. 攻克Permission denied难题3.1 基础认证检查当看到Permission denied, please try again时按以下顺序排查确认用户名存在# 在目标服务器上执行 id [用户名] # 检查用户是否存在检查密码正确性确认密码没有输错检查Caps Lock键状态尝试用正确密码直接在服务器本地登录验证认证方式grep -E ^PasswordAuthentication|^PubkeyAuthentication /etc/ssh/sshd_config确保至少一种认证方式为yes3.2 关键配置文件解析/etc/ssh/sshd_config中影响登录权限的重要参数PermitRootLogin yes # 是否允许root登录 AllowUsers user1 user2 # 白名单用户 DenyUsers baduser # 黑名单用户 PasswordAuthentication yes # 密码认证开关修改配置后必须重启服务sudo systemctl restart sshd3.3 文件权限检查SSH对相关文件的权限要求严格# 检查家目录权限应为700 ls -ld ~ # 检查.ssh目录权限应为700 ls -ld ~/.ssh # 检查authorized_keys权限应为600 ls -l ~/.ssh/authorized_keys修正权限的命令示例chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys chown -R user:user ~/.ssh # 确保属主正确4. 高级排查技巧4.1 启用详细日志模式在客户端使用-vvv参数获取详细连接日志ssh -vvv userhost分析服务器端日志位置因系统而异# Ubuntu/Debian sudo tail -f /var/log/auth.log # CentOS/RHEL sudo tail -f /var/log/secure4.2 SELinux安全模块排查如果启用了SELinux可能导致意外的权限拒绝# 检查SELinux状态 sudo sestatus # 临时设置为宽容模式 sudo setenforce 0 # 永久禁用需重启 sudo sed -i s/SELINUXenforcing/SELINUXpermissive/ /etc/selinux/config4.3 连接超时问题处理如果遇到连接超时而非直接拒绝可能是网络问题# 测试网络连通性 ping server_ip # 测试端口连通性 telnet server_ip 22 nc -zv server_ip 22 # 检查本地防火墙 sudo iptables -L -n5. 安全加固建议5.1 密钥认证配置比密码更安全的密钥认证配置步骤本地生成密钥对ssh-keygen -t ed25519 -C your_emailexample.com上传公钥到服务器ssh-copy-id -i ~/.ssh/id_ed25519.pub userhost服务器端配置# 禁用密码认证 PasswordAuthentication no PubkeyAuthentication yes5.2 端口安全策略修改默认SSH端口降低扫描风险# /etc/ssh/sshd_config Port 2222 # 改为非标准端口同时更新防火墙规则sudo ufw allow 2222/tcp5.3 Fail2Ban防护安装配置Fail2Ban防止暴力破解sudo apt install fail2ban # Ubuntu/Debian sudo yum install fail2ban # CentOS/RHEL # 复制配置文件 sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local编辑/etc/fail2ban/jail.local配置SSH防护[sshd] enabled true port ssh filter sshd logpath /var/log/auth.log maxretry 3 bantime 1h6. 典型场景解决方案6.1 修改端口后无法连接检查流程确认新端口在sshd_config中已设置检查防火墙是否放行新端口验证服务是否监听新端口ss -tulnp | grep sshd6.2 用户被锁定问题检查锁定状态sudo passwd -S username解锁用户sudo usermod -U username6.3 证书过期处理检查证书有效期ssh-keygen -L -f /etc/ssh/ssh_host_ed25519_key重新生成主机密钥sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N sudo systemctl restart sshd7. 自动化排查脚本以下脚本可快速检查SSH服务状态#!/bin/bash # SSH连接快速排查工具 echo SSH服务状态 systemctl status sshd --no-pager | grep -E Active:|Loaded: echo -e \n 端口监听情况 ss -tulnp | grep sshd || netstat -tulnp | grep sshd echo -e \n 防火墙状态 if [ -f /usr/sbin/ufw ]; then ufw status | grep 22 elif [ -f /usr/bin/firewall-cmd ]; then firewall-cmd --list-ports | grep ssh else iptables -L -n | grep :22 fi echo -e \n 关键配置 for param in PermitRootLogin PasswordAuthentication AllowUsers DenyUsers; do grep -E ^$param /etc/ssh/sshd_config || echo $param not set done echo -e \n SELinux状态 sestatus | grep mode将上述内容保存为ssh_check.sh添加执行权限后运行即可获取关键信息。8. 总结与最佳实践经过多次实战我总结出SSH连接排查的黄金法则从外到内由浅入深。先确认网络可达性再检查服务状态最后处理认证问题。每次修改配置后建议先用sshd -t测试配置文件有效性避免重启服务导致不可用。对于生产环境我强烈建议使用密钥认证替代密码定期轮换主机密钥配置监控告警检测SSH服务状态保留至少一个备用管理通道如控制台连接遇到复杂问题时记住ssh -vvv是你的好朋友详细日志往往能揭示问题的真相。