SSH连接失败应先检查sshd服务状态和22端口监听，再排查密钥权限、配置语法及防火墙/安全组放行；禁用密码登录前须确保密钥100%可用，并保留备用通道。
SSH连接失败：检查sshd服务状态和端口监听
远程连不上，第一反应不是改密钥，而是确认服务本身是否在跑。很多新手直接跳过这步，对着Connection refused反复重试密码，其实sshd根本没启动。
- 用
systemctl status sshd（或systemctl status ssh，取决于发行版）看服务是否active (running) - 执行
sudo ss -tlnp | grep :22确认22端口是否被sshd监听；若输出为空，说明未监听，可能配置了非标端口或ListenAddress绑定了特定IP -
/etc/ssh/sshd_config中检查Port、ListenAddress、PermitRootLogin三行——尤其当修改过配置后，必须sudo systemctl restart sshd才生效，reload不一定触发重读
密钥登录配不成功：权限和路径是硬门槛
密钥方式看似安全，但~/.ssh/authorized_keys文件权限不对，sshd会直接拒绝，且不报明确错误，只显示Permission denied (publickey)。
- 客户端私钥
id_rsa必须为600（chmod 600 ~/.ssh/id_rsa），否则OpenSSH会拒绝加载 - 服务端
~/.ssh目录权限不能大于700，authorized_keys不能大于600；常见误操作是用chmod -R 755 ~/.ssh，导致登录失败 - 确保
sshd_config中PubkeyAuthentication yes且AuthorizedKeysFile .ssh/authorized_keys未被注释或改写 - 调试时加
-v参数：运行ssh -v user@host，看日志里是否出现Offering public key和Server accepts key
禁用密码登录前，务必验证密钥已100%可用
把PasswordAuthentication no一加就锁死自己，是远程管理最典型的“手滑事故”。这不是理论风险，是高频真实场景。
Teleport tsh SSH (Identity-First SSH Access, no passwords/static keys)
下载
使用tbot机器ID身份文件配合tsh CLI，通过Teleport访问控制SSH登录托管主机或执行远程命令。
- 不要在单次SSH会话中连续执行：先开两个终端，一个保持密码登录的备用通道，另一个测试密钥登录成功后，再改配置重启
sshd - 改完
sshd_config后，用sudo sshd -t校验语法，避免因拼写错误（如noo）导致systemctl restart sshd失败，服务中断 - 生产环境建议保留一个具有
sudo权限的密码用户作为应急账号，哪怕主账号全走密钥 - 若已锁死，只能通过VPS控制台、物理机本地终端或云平台的Web Console介入修复
非22端口与防火墙协同放行
改端口不是为了“隐蔽”，而是减少暴力扫描噪音。但只改sshd_config里的Port，不碰防火墙，等于开门却堵窗。
- CentOS/RHEL 8+默认用
firewalld：sudo firewall-cmd --permanent --add-port=2222/tcp（替换成你的端口），再firewall-cmd --reload - Ubuntu/Debian常用
ufw：sudo ufw allow 2222/tcp，确认sudo ufw status verbose中该端口状态为ALLOW IN - 若用
iptables，注意规则顺序——INPUT链中ACCEPT规则需在DROP之前；可临时用sudo iptables -I INPUT -p tcp --dport 2222 -j ACCEPT插入最前 - 云服务器（如阿里云、AWS）还需在安全组里额外放行对应端口，这个常被忽略
ssh -i ~/.ssh/mykey.pem -p 2222 admin@192.168.1.100
密钥路径、端口、用户、IP缺一不可；少一个-i或写错-p，连接行为就彻底变成密码尝试。实际运维中，这些参数往往固化在~/.ssh/config里，但首次调试一定手动敲全，避免配置文件掩盖真实问题。
