SSH 密钥管理多台服务器：创建、配置与连接速查

前言

随着现在自己所拥有的云服务器或者 VPS 越来越多，外加现在还在使用的各种各样的 AI 工具也变得越来越多。

那么，有一种统一的方式，能够让我的各种 AI Agent 方便地协助我管理和维护我的多台 Linux 服务器，不必每次输入 IP、端口和密码就成了我当前的迫切需求。

解决方案

经过一番研究和搜索，采用 SSH 密钥认证 + SSH Config 别名，是目前兼顾安全性和日常使用便利的解决方案。它可以把各种针对服务器的连接简化成 ssh server-demo，（即ssh 你的自定义服务器别名）。

由于SSH相关的配置存储于每台电脑上的~/.ssh中，因此，文件传输和具备本地终端权限的 AI 工具也可以复用这套配置，不用在每一个Agent中单独配置。

本文以 macOS 连接 Linux 服务器为例。所有地址、账号和名称均为示例；server.example.com 需要换成你的服务器 IP 或域名。以下操作不会替你创建远程用户，请使用服务器上已有且允许 SSH 登录的账号。

新服务器接入：照着这五步做

每当你有了一台新的要维护的服务器，先确定四件事：别名、地址、SSH 端口、登录账号。下面统一使用：

项目	示例
本地别名	`server-demo`
服务器地址	`server.example.com`
SSH 端口	`22`
已有登录账号	`ubuntu`
本地私钥	`~/.ssh/server_demo_ed25519`

提示

本地别名只是为了方便你自己记忆。

1. 在本地生成密钥

以下命令在本地终端执行：

bash

mkdir -p ~/.ssh
chmod 700 ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/server_demo_ed25519 -C "server-demo"

建议按提示设置私钥口令。如果文件已存在，不要覆盖，先确认用途或换一个名称。

生成的两个文件各有用途：

server_demo_ed25519：私钥，留在本地，不发给他人，也不提交到 Git。
server_demo_ed25519.pub：公钥，安装到服务器。

一把密钥可以用于多台服务器。为便于单独更换与撤销，本文采用每台服务器一把密钥；多台本地设备也建议各自生成密钥，不直接复制私钥。

2. 将公钥安装到服务器

前提是确认当前账号能通过密码等已有方式登录后，执行：

bash

ssh-copy-id -i ~/.ssh/server_demo_ed25519.pub -p 22 [email protected]

首次连接时，先通过服务商控制台等可信渠道核对主机密钥指纹，再接受连接。按提示输入的是服务器登录密码，不是刚设置的私钥口令。

如果 macOS 提示找不到 ssh-copy-id，已安装 Homebrew 的用户可以执行 brew install ssh-copy-id；也可以通过服务商控制台，将 .pub 文件中的完整一行追加到目标账号的 ~/.ssh/authorized_keys。不要覆盖已有公钥。若服务器从一开始就禁用了密码登录，应使用已有密钥、云平台注入功能或控制台安装公钥。

公钥必须安装到准备登录的那个账号下。如果给 root 安装公钥，并不会自动授权其他账号，如ubuntu。

如果服务器没有启用公钥登录

大多数 OpenSSH 服务器默认允许公钥认证；如果服务器明确关闭了它，安装公钥后仍无法通过密钥登录。下面的操作在服务器端进行，需要管理员权限和已有登录方式（密码、已有密钥或云服务商控制台）。

修改前先保留当前登录窗口，并确认可以通过控制台恢复访问。 不要在验证成功前禁用密码登录或关闭当前会话。

检查目标账号的生效配置。在服务器上运行；把 ubuntu 换成目标账号，把 192.0.2.10 换成发起 SSH 连接的客户端公网 IP（不是服务器 IP）：

bash

sudo sshd -T -C user=ubuntu,addr=192.0.2.10 | grep -Ei '^(pubkeyauthentication|authorizedkeysfile|authorizedkeyscommand|authenticationmethods) '

如果显示 pubkeyauthentication yes，表示该场景已允许公钥认证，不必修改这项。它不代表公钥已安装，也不保证能登录；还要检查公钥位置、文件权限及账号限制。若使用主机名或本地地址匹配规则，还需按实际连接补充 host、laddr 等条件。若输出为 no，继续下面的步骤。

找到并修改生效设置。检查 /etc/ssh/sshd_config、其中 Include 引入的文件和适用的 Match 配置，将针对目标账号生效的设置改为：

plaintext

PubkeyAuthentication yes

不要盲目在文件末尾追加：配置文件可能被先行加载的文件或 Match 块影响。保留已有的 AuthorizedKeysFile、AuthorizedKeysCommand 和其他登录策略；如果公钥来源不是默认的 ~/.ssh/authorized_keys，按服务器实际配置安装公钥。

检查并重载。在服务器上先验证配置：

bash

sudo sshd -t

有报错时先修正，不要重载。验证通过后，根据发行版重载对应的服务：Ubuntu / Debian 常用 sudo systemctl reload ssh，RHEL 系发行版常用 sudo systemctl reload sshd；如果服务名称不同，以本机实际服务为准。再次执行上面的 sshd -T -C 命令，确认目标账号的生效值。

回到本地，确认已按步骤 2 安装目标账号的公钥，完成下面的 SSH 别名配置后，在新的终端窗口测试 ssh server-demo。确认新连接成功后，再决定是否调整密码登录。若依然失败，查看下方的排查部分；AuthenticationMethods 可能要求公钥之外的额外认证，不能仅凭 PubkeyAuthentication yes 判断一定能登录。

参考：OpenSSH sshd_config 手册。

3. 添加 SSH 别名

编辑本地 ~/.ssh/config，追加以下配置，保留已有内容：

plaintext

Host server-demo
    HostName server.example.com
    User ubuntu
    Port 22
    IdentityFile ~/.ssh/server_demo_ed25519
    IdentitiesOnly yes
    AddKeysToAgent yes

Host 是连接时使用的别名；HostName 是实际地址；IdentityFile 指向私钥。IdentitiesOnly yes 限制 SSH 使用配置指定的身份，避免尝试 Agent 中大量无关密钥。

在这个 Host 配置块末尾，macOS 用户再加一行：

plaintext

    UseKeychain yes

UseKeychain 是 Apple 自带 OpenSSH 的扩展。Linux、Windows 或其他来源的 OpenSSH 不要直接照搬这一项。若文件已有 Host * 通用配置，建议把具体服务器的配置放在它前面，因为多数选项采用先读到的值。

设置本地权限：

bash

chmod 600 ~/.ssh/config ~/.ssh/server_demo_ed25519

4. 让 macOS 记住私钥口令

使用系统自带的工具，将私钥口令保存到钥匙串，并把密钥加载到 Agent：

bash

/usr/bin/ssh-add --apple-use-keychain ~/.ssh/server_demo_ed25519

私钥口令保护本地密钥；服务器密码用于另一种登录认证。二者不同。Agent 和钥匙串减少的是重复解锁私钥的操作。

5. 登录并验证

先交互式连接一次，确认账号、指纹与权限：

bash

ssh server-demo

退出远程会话后，在本地验证公钥认证能否无交互完成：

bash

ssh -o BatchMode=yes -o PreferredAuthentications=publickey server-demo 'whoami; hostname; uptime'

命令成功返回，说明当前终端环境可以使用公钥完成非交互式登录。它不代表另一个用户、后台进程或 AI 执行环境也能访问同一个 SSH Agent。

以后接入新服务器，重复这五步，更换别名、地址、端口、账号和密钥文件名即可。

日常连接与文件管理

配置完成后，ssh、scp 和通过 SSH 传输的 rsync 都可以使用同一个别名：

bash

# 登录
ssh server-demo

# 查看负载和磁盘
ssh server-demo 'uptime; df -h'

# 上传到远程用户的主目录
scp ./example.txt server-demo:~/

# 下载文件到当前目录
scp server-demo:~/example.txt ./

# 先预览目录同步，再去掉 --dry-run 执行
rsync -av --dry-run ./project/ server-demo:~/project/

rsync 需要两端安装；源路径末尾的 / 表示同步目录中的内容。上例不删除远端额外文件，也不需要重复指定端口。

服务器增加后，可以在私人清单里记录“别名、用途、账号、公钥指纹”，不存私钥或密码。查看本地公钥指纹：

bash

ssh-keygen -lf ~/.ssh/server_demo_ed25519.pub

更换密钥时，先安装新公钥、验证新密钥能登录，再从远端 authorized_keys 删除旧公钥对应的完整一行。只删除本地私钥并不会撤销服务器上的授权。

连不上时，按这个顺序排查

先看 SSH 实际用了什么配置

bash

ssh -G server-demo | grep -E '^(hostname|user|port|identityfile|identitiesonly) '
ssh -vvv server-demo

现象	优先检查
连接超时或被拒绝	地址、端口、安全组、防火墙及 SSH 服务监听状态
`Permission denied (publickey)`	登录账号、公钥是否安装、私钥是否匹配、远端权限
`Enter passphrase for key...`	正在解锁本地私钥，检查 Agent 与钥匙串
`ubuntu@... password:`	正在请求服务器密码，公钥认证未完成或服务端要求额外认证
`Too many authentication failures`	检查 `IdentityFile` 和 `IdentitiesOnly yes`
主机密钥发生变化	先确认是否重装或更换服务器，核对新指纹后再处理旧记录

不要通过关闭主机密钥校验来消除告警，也不必遇到失败就重新生成密钥。

再检查服务器

通过仍可用的登录方式或控制台，在目标登录账号下检查：

bash

ls -ld ~ ~/.ssh
ls -l ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

确认文件归属正确，家目录不可被其他用户随意写入。需要管理员进一步检查时，使用 sudo sshd -T 查看服务端配置，重点看 PubkeyAuthentication、AuthorizedKeysFile 和认证限制；存在 Match 规则时，还需要结合真实用户和连接来源检查。

修改服务端 SSH 配置前保留当前会话和控制台救援入口，先运行 sudo sshd -t 验证，再按发行版重载对应服务。在另一个终端确认密钥登录成功后，才考虑禁用密码认证。

让 AI 复用这套连接

具备本地终端执行能力的 AI 工具，可以调用相同的 SSH 别名。例如：

使用本地 SSH 别名 server-demo，只读检查系统负载、内存和磁盘，汇总异常。不要修改配置或重启服务，不要读取或输出私钥。

前提是它的执行环境能读取配置、使用 Agent，并且允许访问服务器网络。普通聊天窗口或隔离的云端环境不会自动获得本机 SSH 能力，也不需要你把私钥粘贴给 AI。

密钥认证决定“谁能登录”，远程账号权限决定“登录后能做什么”。长期自动化应使用权限受限的账号；涉及部署或数据变更时，明确操作范围、备份和回滚方式。

日后回来查用，记住这个顺序就够了：本地生成密钥 → 服务器安装公钥 → 添加 Host 别名 → 解锁密钥 → 测试登录。

参考

OpenSSH：ssh-keygen
OpenSSH：ssh_config
macOS 本机文档：man ssh-add、man ssh_config。