3695 字
18 分钟
从root+密码到普通用户+SSH密钥：我整理出的一套 Linux VPS 迁移经验
2026-07-08
Notes
Linux
/
SSH

从 root + 密码 到 普通用户 + SSH 密钥：我整理出的一套 Linux VPS 迁移经验#

刚拿到一台新 VPS 的时候，商家通常给你的都是一套最直接的登录方式：

  • 一个公网 IP
  • 一个 root 用户
  • 一串登录密码

从“先用起来”这个角度说，这没有问题。毕竟你第一时间想做的，往往只是先连上服务器、把环境跑起来、确认机器没问题。

但如果你准备长期用这台机器，或者你后面还要管理不止一台 VPS，那么继续长期依赖 root + 密码，基本就只是“能用”，谈不上“合适”。

我后来把自己的 VPS 登录方式，逐步改成了：

  • 平时不用 root 直接登录
  • 新建一个普通用户，比如 ops
  • 需要管理系统时，用 sudo 临时提权
  • 登录方式尽量切到 SSH 密钥

这篇文章不是在讲一套抽象的安全理论，而是把我自己整理出来的一套迁移顺序和踩坑经验，写成一篇能直接看懂、也能直接照做的分享。

如果你现在手上的 VPS 也是商家刚交付的默认状态，这篇文章应该会比较适合你。

为什么我不建议长期直接用 root + 密码#

一开始我也会直接用 root 登录，因为方便，所有事情都能做，几乎没有门槛。

但这个模式的问题也很明显。

第一，风险太集中。
root 是 Linux 里权限最高的账号，一旦密码泄露，或者你在某个不安全的环境里误用了它，损失就是整台机器级别的。

第二，不利于后续管理。
如果你以后要把服务器接入自动化脚本、部署流程、主控机、远程 agent，长期直接使用 root 会让权限边界非常模糊。很多事情“现在也能做”，但后面会越来越乱。

第三，容易犯低级错误。
平时就以最高权限工作，意味着很多本来应该被拦住的误操作，都可能直接生效。删错文件、改错权限、执行错命令，代价都会放大。

所以我后来越来越倾向于把 VPS 调整到一种更稳的状态：

  • 普通操作用普通用户
  • 系统管理时再 sudo
  • 尽量不用密码登录
  • 登录凭证改成 SSH 密钥

它未必是最复杂、最“高级”的方案，但对大多数个人开发者、独立部署者、小规模多机管理场景来说，已经足够实用。

我真正想要的，不是“更安全”三个字，而是更清晰的管理方式#

很多文章讲这类话题时，容易一上来就强调安全。但我自己后来发现，驱动我去改这件事的，不只是“安全”，更是“清晰”。

我希望服务器的权限结构是清楚的：

  • 谁负责登录
  • 谁能提权
  • 哪把密钥对应哪台机器
  • 如果将来不用了，应该删哪个用户、删哪把公钥、查哪些残留

当一台机器只有你自己在用时，你可能感觉不到这种差异。
但只要机器数量开始增加，或者你开始引入脚本、自动化、远程协作，这种“清晰”会比“先凑合用”重要得多。

所以后来我的思路变得很固定：

  1. 商家交付的 root + 密码 先作为起点
  2. 尽快创建一个普通用户
  3. 给这个用户配好 sudo
  4. 用 SSH 公钥完成登录切换
  5. 确认一切稳定之后，再考虑关掉 root 直登和密码登录

这个顺序本身，比单个命令更重要。

我最想先提醒的一句话：不要太早关闭 root 和密码登录#

如果只让我从整件事里挑出一条最重要的经验，那就是这句：

在你确认新用户和 SSH 密钥都能稳定登录之前，不要急着关闭 root，也不要急着关闭密码登录。

这是最容易把人锁在服务器外面的地方。

很多人不是不会建用户，也不是不会配公钥，而是太着急“做完整套加固”。结果新用户还没测试透，sshd_config 已经先改了；root 还没来得及兜底，入口已经关了。

只要顺序错了，事故就很容易发生。

我的做法一直很保守：

  • 当前 root 会话不要关
  • 新开一个终端测试新用户登录
  • 测试 sudo
  • 再开一次新连接重复验证
  • 确认密钥真的在自己机器上可用
  • 这些都没问题之后，再谈进一步加固

这看起来慢一点，但它比“觉得自己应该没问题”可靠得多。

我实际采用的迁移顺序#

1. 先继续用商家给的 root + 密码 登录#

这一步没有什么好羞耻的。
既然机器刚交付就是这个状态，那就先用它把过渡动作完成。

重点不在于“永远别用 root”，而在于“不要长期只用 root”。

2. 创建一个普通用户#

我一般会先建一个用于日常管理的普通用户，比如：

Terminal window
adduser ops

这一步通常会顺带创建：

  • 用户本身
  • 家目录 /home/ops
  • 一些默认初始化配置

建完以后，我会立刻看一眼：

Terminal window
id ops

这一步我后来越来越重视，因为它不仅能确认用户建好了，还能顺便看到这个用户的 UID。
如果将来你想删除这个用户并检查残留，UID 会比用户名更可靠。

3. 给普通用户加 sudo#

在 Ubuntu / Debian 上，我通常这样做：

Terminal window
usermod -aG sudo ops

在 CentOS / Rocky / AlmaLinux 这类系统里，常见的是：

Terminal window
usermod -aG wheel ops

这一点特别容易让刚上手的人迷糊，因为很多教程默认只写一种发行版。
但实际操作时，你只要记住一件事：不同系统的管理员组名可能不一样。

加完组之后，我会再执行一次：

Terminal window
id ops

确认它已经进了正确的组。

4. 在自己的电脑上准备 SSH 密钥#

这一步不是在 VPS 上做，而是在你本机做。

我会先看本地有没有现成密钥：

Terminal window
ls -la ~/.ssh

如果已经有，比如：

  • id_ed25519
  • id_ed25519.pub
  • id_rsa
  • id_rsa.pub

那就先判断这把密钥是不是你打算继续使用的。

如果没有，或者你想为 VPS 单独准备一把，我更推荐一开始就明确指定文件名，而不是一路回车生成默认文件。

比如：

Terminal window
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_vps_main -C "wang-mac-vps-main"

我后来很确定的一点是：

-C 只是备注，真正决定会不会跟旧密钥混在一起的，是 -f。

如果你不写 -f，SSH 很可能还是默认生成到：

Terminal window
~/.ssh/id_ed25519
~/.ssh/id_ed25519.pub

这就意味着你以后再生成别的默认密钥时，很容易遇到覆盖、混淆，或者你自己都分不清哪把钥匙对应哪台机器。

从长期管理角度看，一开始就把名字起清楚，后面会轻松很多。

5. 只把公钥放到服务器上#

这一点听起来像常识，但真的是高频坑。

上传到服务器上的，应该是公钥，也就是 .pub 结尾的那个文件内容；私钥必须只留在你自己的电脑里。

查看公钥内容可以直接用：

Terminal window
cat ~/.ssh/id_ed25519_vps_main.pub

复制那一整行内容，后面写到 VPS 的 authorized_keys 里。

6. 回到 VPS，把公钥配置到新用户下面#

我通常会这样做：

Terminal window
mkdir -p /home/ops/.ssh
nano /home/ops/.ssh/authorized_keys
chmod 700 /home/ops/.ssh
chmod 600 /home/ops/.ssh/authorized_keys
chown -R ops:ops /home/ops/.ssh

这里真正关键的不是“用哪个编辑器”，而是两件事：

  • 公钥要粘贴完整
  • 权限要正确

SSH 对权限是比较挑剔的。
哪怕你的公钥内容没问题，只要 .ssh 目录或 authorized_keys 权限不对，密钥登录仍然可能失败。

我一般会再检查一遍：

Terminal window
ls -ld /home/ops/.ssh
ls -l /home/ops/.ssh/authorized_keys

理想状态通常是：

Terminal window
drwx------ 2 ops ops ...
-rw------- 1 ops ops ...

7. 新开终端测试，不要关掉当前 root 会话#

这一步我会单独强调，因为它是迁移过程里最有“分水岭”意义的一步。

不要在当前 root 会话里自我感动地觉得“应该差不多了”。
直接新开一个终端，像真实登录那样去测。

如果你的私钥是默认文件名，可能直接这样就能连：

Terminal window
ssh ops@你的服务器IP

如果你用了自定义文件名，就明确指定：

Terminal window
ssh -i ~/.ssh/id_ed25519_vps_main ops@你的服务器IP

登录成功以后，再看两眼：

Terminal window
whoami
pwd

理想情况下，应该看到：

Terminal window
ops
/home/ops

这一步失败了，就先排错，不要继续往后推。

8. 测试 sudo#

如果我已经能用 ops 登录，下一步一定会测提权是否正常：

Terminal window
sudo -l
sudo whoami

如果最后输出的是：

Terminal window
root

那就说明这次迁移最核心的两件事已经成立了：

  • 我可以不用 root 直接登录
  • 我需要系统权限时仍然能拿到 root 能力

到了这里，我才会觉得“迁移初步成功”。

到什么程度，我才会考虑关掉 root 和密码登录#

我不会在第一次测试刚成功时，立刻去改 SSH 加固配置。

至少要满足下面这些条件，我才会继续：

  • ops 可以稳定 SSH 登录
  • ops 登录后 sudo 正常
  • 私钥确实在我自己的电脑上能用
  • 我已经用新终端重复测试过，不是只成功过一次

如果这些都没问题，后面才值得考虑：

禁止 root 直接 SSH 登录#

通常涉及修改：

Terminal window
/etc/ssh/sshd_config

常见配置项是：

Terminal window
PermitRootLogin no

禁止密码登录，只保留密钥#

同样是在 SSH 配置里，常见相关项是：

Terminal window
PasswordAuthentication no
PubkeyAuthentication yes

但我的建议一直是一样的：

第一天先不要着急把所有安全动作一次做满。

先把一台机器跑顺，再复制到别的机器，效率反而更高。

如果以后不用这个用户了，我会怎么删#

有时候迁移完成以后，你会想做反向操作，比如删掉某个旧用户，或者撤销某个临时运维账号。

最常见的删除方式是：

Terminal window
userdel -r ops

这通常会一起删掉：

  • 用户账号
  • 家目录
  • .ssh 目录
  • 用户自己的大多数配置文件

如果你的目标只是“不让这个用户再登录”，那很多时候到这里已经够了。

真想删得更干净，我会先记 UID 再删除#

这是我后来才逐渐养成的习惯，而且很值得保留。

很多人删完用户后，会习惯性执行：

Terminal window
find / -user ops 2>/dev/null

这个写法的问题在于：
用户删掉以后，用户名解析有时就不可靠了，查出来的结果不一定完整，甚至可能直接失效。

所以更稳的做法是：

第一步：删除前先记住 UID#

Terminal window
id ops

如果你看到：

Terminal window
uid=1001(ops)

那就把 1001 记下来。

第二步：删用户#

Terminal window
userdel -r ops

第三步：按 UID 查残留#

Terminal window
find / -uid 1001 2>/dev/null

这样查文件残留会更稳。

还有一种残留，很多人会忘：sudoers 配置#

如果你之前不是只把用户加进 sudo 或 wheel 组，而是给它单独写过 sudo 规则，比如：

Terminal window
/etc/sudoers.d/ops

那删除用户之后，最好顺手检查一下：

Terminal window
ls -l /etc/sudoers.d/

如果里面确实还有这个用户对应的规则文件，再手动删掉。

这里我自己的原则是：

  • 尽量不要直接乱改 /etc/sudoers
  • 真要改，用 visudo
  • 更推荐把单独规则放在 /etc/sudoers.d/ 里管理

这样既清晰，也更不容易因为语法问题把 sudo 整体搞坏。

这件事里，我觉得最容易踩的几个坑#

1. 太早禁用 root#

这是最经典的一种翻车方式。
新用户还没验证透，就把 root 入口关掉，结果发现自己进不去了。

2. authorized_keys 权限不对#

很多人会反复怀疑公钥粘错了，但其实问题只是权限不对。

这三个命令值得反复确认：

Terminal window
chmod 700 /home/ops/.ssh
chmod 600 /home/ops/.ssh/authorized_keys
chown -R ops:ops /home/ops/.ssh

3. 把私钥传到了服务器#

服务器上只需要公钥。
私钥应该只放在你自己的电脑里。

4. 测试时还在用错用户名#

你明明是在验证新用户，却还是下意识连成：

Terminal window
ssh root@服务器IP

这样测不出任何迁移结果。

真正该测的是：

Terminal window
ssh ops@服务器IP

5. 把 -C 备注当成“不会覆盖旧密钥”的关键#

这个误解很常见。
真正决定输出文件名的是 -f，不是 -C。

如果你想长期清晰管理多把密钥，最务实的办法就是：

Terminal window
ssh-keygen -t ed25519 -f ~/.ssh/自定义文件名 -C "备注"

如果你手上有十几台 VPS，我的建议反而是先慢一点#

很多人一旦把这套流程理解了，就会很想一次性把所有机器都改完。

但从经验上看，最稳的做法通常不是“立刻批量推进”，而是：

  1. 先挑一台最不重要的机器
  2. 完整走一遍迁移流程
  3. 把登录、提权、密钥、回滚思路都确认清楚
  4. 再复制到其他机器

你只要把一台机器跑顺，后面的十几台大概率就只是重复动作。
真正难的不是命令本身，而是第一次把顺序和判断边界搞清楚。

最后总结：这不是“高级操作”，而是一套更稳的起手式#

回头看，我觉得这件事最有价值的地方，不是学会了几个 Linux 命令，而是把一台 VPS 从“商家默认交付状态”，调整成了“适合长期自己管理的状态”。

如果把整套经验压缩成最小版本，其实就是下面这些：

VPS 上执行#

Terminal window
adduser ops
usermod -aG sudo ops
mkdir -p /home/ops/.ssh
nano /home/ops/.ssh/authorized_keys
chmod 700 /home/ops/.ssh
chmod 600 /home/ops/.ssh/authorized_keys
chown -R ops:ops /home/ops/.ssh

本机测试#

Terminal window
ssh -i ~/.ssh/id_ed25519_vps_main ops@你的服务器IP
sudo -l
sudo whoami

确认都没问题之后，再决定是否继续做更严格的 SSH 加固。

如果你现在正准备从 root + 密码 迁到 普通用户 + SSH 密钥，我最想重复的仍然是那句话：

先把登录链路走通，再做封口动作。

这句话，往往比多背几个命令更重要。

从root+密码到普通用户+SSH密钥：我整理出的一套 Linux VPS 迁移经验
https://blog.wlens.top/posts/linux_vps_从root密码到普通用户与ssh密钥的迁移经验/
作者
Lao Wang
发布于
2026-07-08
许可协议
CC BY-NC-SA 4.0
Alpine Linux 家宽_NAT X-UI VLESS-TLS
© 2026 Lao Wang. All Rights Reserved. / RSS / Powered by Astro