CN
EN
一台服务器，往往不止一个人用，也不止一台设备登录。团队协作时，每个成员都应该有自己的SSH密钥；个人使用时，笔记本、台式机、备用机也可能需要分别配置。如果所有设备共用同一个密钥，一旦某台设备丢失或密钥泄露，整个服务器都面临风险。
正确的做法是：一台VPS配置多个SSH密钥，一人一钥、一机一钥，权限清晰、风险隔离。这篇文章从生成密钥到服务端配置，再到客户端管理和安全加固，手把手教你完成整套流程。
先理解原理：authorized_keys 是一张“公钥清单”
SSH公钥认证的核心逻辑很简单：服务器上的 `~/.ssh/authorized_keys` 文件里，每一行代表一个被授权登录的公钥。客户端持有对应的私钥，登录时服务器用公钥验证私钥的签名，验证通过即放行。
这个文件可以放任意多个公钥——一个公钥一行。你可以为团队每个人添加一行，也可以为同一个人在不同设备上各添加一行。每行还可以在开头附加限制条件，比如限制来源IP、限制可执行命令，实现更细粒度的权限控制。
第一步：在本地生成多个密钥对
不要覆盖默认的 `id_ed25519`。为每个用途单独生成密钥，文件名带上标识。
工作用密钥
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_work -C "work@company"个人笔记本密钥
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_laptop -C "laptop@home"备用设备密钥
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_backup -C "backup@spare"`-t ed25519` 是目前推荐的密钥类型，比RSA更短、更快、更安全。`-f` 指定保存路径，`-C` 添加注释方便识别。生成时建议设置一个强密码短语，即使私钥文件泄露，攻击者没有密码短语也无法使用。
第二步：将公钥上传到服务器
最直接的方式是用 `ssh-copy-id` 指定密钥文件：
ssh-copy-id -i ~/.ssh/id_ed25519_work.pub user@服务器IP如果服务器已经禁用了密码登录，需要先用现有的可用密钥登录，然后手动追加公钥：
cat ~/.ssh/id_ed25519_laptop.pub | ssh user@服务器IP "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"注意是 `>>` 追加，不是 `>` 覆盖。覆盖会清掉已有的所有公钥，导致其他设备无法登录。
第三步：服务端管理多个公钥
登录服务器后，查看当前已授权的公钥：
cat ~/.ssh/authorized_keys每一行是一个公钥。建议在每行末尾的注释部分写清楚用途，比如 `work-laptop`、`home-desktop`、`ci-deploy`。这样后续排查“这个密钥是谁的”时一目了然。
如果有多人共用同一台服务器，更规范的做法是为每个人创建独立的系统用户。每个用户在自己的家目录下维护 `~/.ssh/authorized_keys`，互不干扰。创建新用户并导入公钥：
sudo adduser alice
sudo mkdir -p /home/alice/.ssh
sudo cp /tmp/alice.pub /home/alice/.ssh/authorized_keys
sudo chown -R alice:alice /home/alice/.ssh
sudo chmod 700 /home/alice/.ssh
sudo chmod 600 /home/alice/.ssh/authorized_keys这样 alice 只能用自己的密钥登录自己的账户，无法访问其他用户的文件，权限隔离更彻底。
第四步：客户端配置，简化登录命令
如果本地有多个密钥，每次登录都要加 `-i` 参数很麻烦。在本地 `~/.ssh/config` 中为每个主机配置别名和对应密钥：
Host jtti-work
HostName 服务器IP
User alice
IdentityFile ~/.ssh/id_ed25519_work
IdentitiesOnly yes
Host jtti-personal
HostName 服务器IP
User bob
IdentityFile ~/.ssh/id_ed25519_laptop
IdentitiesOnly yes`IdentitiesOnly yes` 是关键配置——它强制SSH只使用指定的密钥，避免客户端把本地所有密钥都尝试一遍。这在服务器限制登录尝试次数时尤为重要。
配置完成后，直接执行 `ssh jtti-work` 即可登录，不需要记住IP和密钥路径。
第五步：为公钥添加限制条件
`authorized_keys` 的每一行可以在公钥前面添加选项，实现更精细的控制。例如，限制某个密钥只能从特定IP登录：
from="192.168.1.0/24,10.0.0.5" ssh-ed25519 AAAAC3... work@company限制某个密钥只能执行备份命令：
command="/usr/local/bin/backup.sh" ssh-ed25519 AAAAC3... backup@spare这些选项让同一个服务器上的多个密钥拥有不同的权限边界。部署密钥用于自动化任务时，限制其只能执行特定命令，即使密钥泄露，攻击者也无法获得完整shell。
第六步：验证与故障排查
新增密钥后，不要关闭当前SSH会话。新开一个终端，用新密钥登录测试：
ssh -i ~/.ssh/id_ed25519_work user@服务器IP如果登录失败，按以下顺序排查：
权限问题是最常见的原因。服务器上 `~/.ssh` 必须是700，`authorized_keys` 必须是600，家目录不能是777。权限不对，SSH会直接拒绝使用该密钥。
SELinux上下文在RHEL/CentOS系上可能拦截。执行 `restorecon -Rv ~/.ssh` 恢复正确的安全上下文。
authorized_keys格式要求每行一个完整公钥，不能有多余换行或空格。如果从网页复制时被截断，也会导致认证失败。
sshd_config配置确认 `PubkeyAuthentication yes` 已启用，且没有 `AuthorizedKeysFile` 指向其他路径。
安全建议与Jtti的底层保障
多个密钥管理起来比单一密钥复杂，安全习惯需要同步跟上。定期审查 `authorized_keys`，删除离职成员或退役设备的公钥。禁用密码登录和root直接登录，强制所有用户使用密钥认证。为每个密钥设置独立的密码短语，避免私钥文件被盗后直接可用。
底层基础设施的稳定性同样重要。Jtti的云服务器默认提供纯净的Linux系统，用户从第一次登录起就可以自主管理SSH密钥体系。香港及美国节点接入CN2 GIA精品线路，三网直连优化，从国内通过SSH管理服务器的延迟低、不丢包，多设备切换登录的体验流畅稳定。全系标配独立IP与独享带宽，不存在共享环境下的资源争抢。续费同价政策确保长期运行的成本可预期。
一台VPS配置多个SSH密钥，本质上是把“谁能进来、从哪里进来、进来能做什么”这三件事管清楚。 访问Jtti官网，查看适合团队协作与多设备管理场景的云服务器方案。
