我见过不少人遇到 VPS SSH 登录失败，第一反应是：机器是不是坏了？要不要重装？
其实 Permission denied 这个报错通常不代表服务器挂了。它更像是在说：SSH 服务还活着，但它不认你这次登录。
常见场景大概是这些：
- 刚买 VPS，用邮件里的密码登录失败
- 换了密钥以后，突然提示
Permission denied (publickey) - 以前能登录，改过
/etc/ssh/sshd_config后进不去了 - 复制了别人的 SSH 命令，用户名写错了
- 本地私钥权限太松，被 SSH 客户端直接拒绝使用
这篇文章不讲一堆玄学，直接按排查顺序来。你照着走，大多数问题 10 分钟内能定位到。
SSH 的完整报错一般长这样：
Permission denied (publickey).
Permission denied (publickey,password).
Permission denied, please try again.
这几个意思不一样。
| 报错 | 大概说明 |
|---|---|
Permission denied (publickey) | 服务器只接受密钥，当前密钥没通过 |
Permission denied (publickey,password) | 密钥和密码都可能允许，但都没通过 |
Permission denied, please try again | 密码错、用户名错，或者密码登录被限制 |
如果你只复制最后一句 Permission denied 去搜索，很容易走偏。先把完整报错贴出来看，尤其是括号里的认证方式。
建议先加 -v 看详细日志：
ssh -v root@your_server_ip
如果信息太多，可以用更详细的：
ssh -vvv root@your_server_ip
重点看这几行：
Offering public key: /Users/you/.ssh/id_ed25519
Authentications that can continue: publickey
No more authentication methods to try.
这说明客户端确实拿了密钥去试，但服务器没接受。
VPS 登录不是所有系统都用 root。
常见默认用户大概是：
| 系统 / 镜像 | 常见用户名 |
|---|---|
| Debian / Ubuntu 裸系统 | root 或 ubuntu |
| Ubuntu 云镜像 | ubuntu |
| Debian 云镜像 | debian 或 root |
| CentOS / Rocky / AlmaLinux | root 或 centos |
| 部分云厂商托管镜像 | 控制台里指定的用户名 |
我之前帮朋友看过一次，他一直用：
ssh [email protected]
结果那台机器是 Ubuntu cloud image，默认只允许：
ssh [email protected]
密码、密钥、端口都没问题，单纯是用户名错了。
排查时先做三件事：
- 看 VPS 开通信邮件
- 看云控制台的登录说明
- 看你创建实例时有没有指定 SSH 用户
如果你不确定，优先试这些：
ssh root@your_server_ip
ssh ubuntu@your_server_ip
ssh debian@your_server_ip
不要一上来就重置系统。
很多人本地有好几个 SSH key：
ls -la ~/.ssh
可能会看到：
id_rsa
id_rsa.pub
id_ed25519
id_ed25519.pub
my-vps.pem
company-key.pem
SSH 客户端不一定会自动选中你想用的那把。最稳的做法是明确指定：
ssh -i ~/.ssh/my-vps.pem root@your_server_ip
如果你已经写了 ~/.ssh/config，也检查一下是不是 Host 匹配错了：
Host my-vps
HostName your_server_ip
User root
IdentityFile ~/.ssh/my-vps.pem
IdentitiesOnly yes
然后登录：
ssh my-vps
这里 IdentitiesOnly yes 很有用。它会让客户端只用你指定的那把 key，避免本地 agent 一口气塞一堆无关密钥，结果服务器提前拒绝。
如果你看到类似提示：
WARNING: UNPROTECTED PRIVATE KEY FILE!
Permissions 0644 for 'my-vps.pem' are too open.
This private key will be ignored.
那不是服务器拒绝你，是你本地 SSH 客户端压根没用这把私钥。
修一下权限：
chmod 700 ~/.ssh
chmod 600 ~/.ssh/my-vps.pem
如果是公钥文件：
chmod 644 ~/.ssh/my-vps.pem.pub
再试：
ssh -i ~/.ssh/my-vps.pem root@your_server_ip
Windows 用户如果用的是 WSL，也要在 WSL 里面改权限。私钥放在 Windows 挂载盘里时，有时权限模型会比较烦，建议直接复制到 WSL 的 ~/.ssh/ 目录里。
如果你还能通过控制台 VNC、救援模式、云厂商 Web Shell 进去，检查服务器端权限：
ls -ld ~/.ssh
ls -l ~/.ssh/authorized_keys
对 root 来说，通常应该是：
chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
chown -R root:root /root/.ssh
对普通用户，比如 ubuntu：
chmod 700 /home/ubuntu/.ssh
chmod 600 /home/ubuntu/.ssh/authorized_keys
chown -R ubuntu:ubuntu /home/ubuntu/.ssh
一个很容易忽略的坑是：你用 root 把 key 写进了普通用户目录，结果 owner 还是 root。
比如：
-rw------- 1 root root 399 authorized_keys
但你登录的是 ubuntu，那就不对。要改成：
chown ubuntu:ubuntu /home/ubuntu/.ssh/authorized_keys
authorized_keys 里面应该放的是公钥，不是私钥。
公钥一般长这样：
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... yourname@machine
或者：
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ... yourname@machine
私钥一般长这样，千万不要放进去：
-----BEGIN OPENSSH PRIVATE KEY-----
...
-----END OPENSSH PRIVATE KEY-----
如果你本地有私钥，可以这样生成对应公钥：
ssh-keygen -y -f ~/.ssh/my-vps.pem
然后把输出追加到服务器对应用户的：
~/.ssh/authorized_keys
追加时用：
echo 'ssh-ed25519 AAAA...' >> ~/.ssh/authorized_keys
不要覆盖原文件，除非你确定里面没有其他仍在使用的 key。
如果你改过 SSH 安全配置，重点看：
sudo sshd -t
sudo grep -E '^(PasswordAuthentication|PubkeyAuthentication|PermitRootLogin|AuthorizedKeysFile|AllowUsers|DenyUsers)' /etc/ssh/sshd_config
常见问题有几个。
PasswordAuthentication no
这时你再怎么输密码都没用，只能用密钥。
如果你确实要临时打开密码登录：
PasswordAuthentication yes
改完测试配置：
sudo sshd -t
再重载：
sudo systemctl reload ssh
有些系统服务名是 sshd：
sudo systemctl reload sshd
PermitRootLogin no
这时 ssh root@ip 肯定进不去。你应该改用普通用户登录，再 sudo -i。
还有一种配置：
PermitRootLogin prohibit-password
它允许 root 用密钥登录，但不允许 root 用密码登录。
如果配置里有：
AllowUsers deploy
那只有 deploy 能登录，root、ubuntu 都会被拒绝。
这种问题很隐蔽，因为端口通、密码也对，但就是不让进。
能进控制台的话，直接看 SSH 日志。
Ubuntu / Debian 常见：
sudo tail -n 100 /var/log/auth.log
Rocky / AlmaLinux / CentOS 常见：
sudo tail -n 100 /var/log/secure
systemd 也可以看：
sudo journalctl -u ssh -n 100 --no-pager
sudo journalctl -u sshd -n 100 --no-pager
你会看到更明确的原因，比如：
Failed publickey for root from 1.2.3.4 port 52110 ssh2
Authentication refused: bad ownership or modes for directory /root/.ssh
User ubuntu not allowed because not listed in AllowUsers
Failed password for invalid user admin from 1.2.3.4
这比在本地盲试有效得多。
如果你连续输错很多次，可能不是认证配置问题，而是 IP 被封了。
先查 Fail2Ban：
sudo fail2ban-client status
sudo fail2ban-client status sshd
如果你的 IP 在封禁列表里：
sudo fail2ban-client set sshd unbanip your_home_ip
如果你完全进不去，只能从云控制台、VNC 或救援模式处理。
云厂商防火墙也要看：
- 安全组是否放行 22 端口
- 是否只允许某个 IP 登录
- 你家宽 IP 是否变了
- 你是否把 SSH 端口改成了 2222、22022 之类
如果端口改过，命令要带 -p：
ssh -p 2222 -i ~/.ssh/my-vps.pem root@your_server_ip
注意大小写：SSH 命令里端口是小写 -p，scp 里端口是大写 -P。
如果 SSH 已经完全无法登录，别急着重装。按这个顺序来：
大多数 VPS 面板都有：
- VNC Console
- Serial Console
- Web Console
- Rescue Console
进去后先别乱改，先看日志和配置。
如果系统本身进不去，可以进 rescue mode，把原系统磁盘挂载出来：
mkdir /mnt/sysroot
mount /dev/vda1 /mnt/sysroot
实际磁盘名可能是 /dev/sda1、/dev/vda1、/dev/nvme0n1p1，先用：
lsblk
再检查：
cat /mnt/sysroot/etc/ssh/sshd_config
ls -la /mnt/sysroot/root/.ssh
常见救急动作：
- 修正
authorized_keys - 修正
.ssh权限和 owner - 临时允许密码登录
- 去掉错误的
AllowUsers - 恢复默认 SSH 端口
改完后重启回原系统，再登录。
如果只是：
- 用户名写错
- key 权限错
authorized_keys写错- sshd 配置改错
修完就行，不需要重装。
但如果你看到这些信号，就要谨慎：
authorized_keys里出现陌生公钥- 多了陌生用户
- SSH 日志里有大量成功登录记录
/etc/sudoers被改过- crontab / systemd 里有陌生任务
- 机器疑似被拿去扫端口、发包、挖矿
这种就不是单纯 SSH 登录问题了，要按入侵事件处理。可以看这篇：VPS 被入侵后的 24 小时处置清单。
修好以后，建议整理成这种状态：
PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin prohibit-password
再配一个普通 sudo 用户：
adduser deploy
usermod -aG sudo deploy
mkdir -p /home/deploy/.ssh
nano /home/deploy/.ssh/authorized_keys
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh
本地写 ~/.ssh/config：
Host my-vps
HostName your_server_ip
User deploy
Port 22
IdentityFile ~/.ssh/my-vps.pem
IdentitiesOnly yes
以后登录就一句：
ssh my-vps
别每次都手敲一长串，也别把 root 密码登录长期打开。
遇到 Permission denied，按这个顺序走：
ssh -v user@ip看完整认证过程- 确认用户名是不是
root、ubuntu、debian或厂商指定用户 - 用
ssh -i key user@ip明确指定私钥 - 修本地私钥权限：
chmod 600 key - 检查服务器端
.ssh和authorized_keys权限 - 确认
authorized_keys里放的是公钥，不是私钥 - 检查
PasswordAuthentication、PermitRootLogin、AllowUsers - 看
/var/log/auth.log、/var/log/secure或journalctl - 检查 Fail2Ban 是否封了你的 IP
- 检查云防火墙、安全组、SSH 端口
- 仍进不去就用 VNC / rescue mode 修配置
如果你的现象不是 Permission denied，而是连接超时、端口不通、服务没响应，那排查方向不一样。可以接着看：VPS 服务启动了但外网访问不了 和 VPS 被 Fail2Ban 误封怎么办。
最后给一个实际建议：改 SSH 配置前，先开两个终端。一个保持现有 SSH 会话不要断，另一个测试新连接。确认新连接能进，再关闭旧窗口。这个小习惯能少救很多次机器。