Linux 中 SSH 密钥存储在哪里 — 以及如何安全地管理它们

SSH (Secure Shell) 是 Linux 生态系统中最关键的工具之一。系统管理员、开发人员和 DevOps 工程师每天都依靠它来进行远程服务器访问、安全文件传输、部署自动化和基础设施管理。虽然大多数用户通过简单的终端命令与 SSH 交互，但真正的安全支柱在于 SSH 密钥对 — 加密凭证，可实现无密码身份验证、自动化工作流和强化访问控制。

无论您是管理单个 VPS Hosting 实例，还是跨数十个 Dedicated Servers 协调访问，准确了解 SSH 密钥的存储位置 — 以及如何正确管理它们 — 不是可选的。这是一项基础安全要求。

本指南涵盖所有内容：默认密钥存储位置、系统范围的主机密钥、自定义配置、权限要求以及安全密钥管理的最佳实践。

什么是 SSH 密钥，为什么它们很重要？

SSH 密钥使用非对称密码学来验证用户和服务器。每个密钥对包括：

• 私钥 — 保存在客户端机器上，从不共享
• 公钥 — 放在远程服务器上以验证身份

当你连接到服务器时，SSH 使用密码握手来验证你持有与服务器上的公钥相对应的私钥 — 而无需传输私钥本身。这在根本上比基于密码的身份验证更安全。

默认 SSH 密钥存储位置（用户密钥）

对于任何标准 Linux 用户，SSH 密钥存储在主文件夹内的隐藏目录中：

~/.ssh/

这扩展为完整路径：

/home/username/.ssh/

对于 root 用户具体来说：

/root/.ssh/

~/.ssh/ 内的常见文件

当您运行 ssh-keygen 时，除非您在密钥生成期间明确指定不同的路径，否则密钥默认写入此目录。

系统范围 SSH 密钥位置（主机密钥）

除了用户密钥外，SSH daemon (sshd) — 服务器端组件 — 维护自己的一组主机密钥。这些密钥存储在系统范围内的：

/etc/ssh/

/etc/ssh/ 中的主机密钥文件

这些主机密钥的用途与用户密钥不同。当客户端首次连接到服务器时，服务器会显示其主机公钥。客户端将此指纹存储在 ~/.ssh/known_hosts 中。在后续连接中，SSH 验证指纹是否匹配 — 防止中间人攻击。

> 重要：主机密钥在 SSH 服务器安装期间自动生成。您永远不需要手动创建它们，但您应该知道它们的位置以便进行审计和备份。

自定义 SSH 密钥位置

您不受限于默认 ~/.ssh/ 目录。SSH 密钥可以在文件系统的任何位置生成和存储。要使用存储在非默认位置的密钥，请明确指定它：

ssh -i /path/to/custom_key user@host

使用 ~/.ssh/config 管理多个密钥

使用正确配置的 ~/.ssh/config 文件，管理多个服务器、项目或用户账户会变得更加清晰。这允许您定义每个主机的设置，包括要使用的密钥：

Host production-server
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/production_ed25519

Host staging-server
    HostName 203.0.113.20
    User deploy
    IdentityFile ~/.ssh/staging_ed25519

Host github.com
    User git
    IdentityFile ~/.ssh/github_key

使用此配置，运行 ssh production-server 会自动使用正确的密钥，无需任何额外标志。

SSH 密钥的使用方式：客户端与服务器

出站连接（客户端）

当您启动 SSH 连接时，SSH 客户端默认在 ~/.ssh/ 中搜索私钥。这些密钥用于向远程服务器验证您的身份。

使用 SSH 客户端密钥的工具包括：

• ssh — 直接远程 shell 访问
• scp — 安全文件复制
• rsync — 通过 SSH 进行文件同步
• git — 使用基于 SSH 的远程仓库时

入站连接（服务器端）

在服务器上，SSH 检查特定文件以确定哪些用户被授权连接：

~/.ssh/authorized_keys

此文件每行包含一个公钥。每个条目授予相应私钥的持有者以该用户身份登录的权限。

实际示例：如果用户 alice 想要以用户 webadmin 的身份 SSH 连接到服务器，Alice 的公钥必须存在于 /home/webadmin/.ssh/authorized_keys 中 — 而不是在该服务器上 Alice 自己的主目录中。

文件权限 — SSH 安全的关键

这是许多管理员犯代价高昂错误的地方。SSH 对文件权限的要求非常严格。如果权限过于开放，SSH 将默默拒绝使用您的密钥或完全拒绝登录尝试。

所需权限设置

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 600 ~/.ssh/config

权限参考表

在一个命令中修复权限：

chmod 700 ~/.ssh && chmod 600 ~/.ssh/* && chmod 644 ~/.ssh/*.pub

安全生成 SSH 密钥

对于新密钥，始终优先选择 Ed25519 而不是 RSA。Ed25519 提供更强的安全性，密钥大小更短，性能更快。

ssh-keygen -t ed25519 -C "your_email@example.com"

对于需要 RSA 的旧系统，至少使用 4096 位：

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

在提示时始终设置密码短语。密码短语会加密磁盘上的私钥，因此即使攻击者获得了对文件系统的访问权限，他们也无法在没有密码短语的情况下使用该密钥。

使用 ssh-agent 管理密钥

每次使用 SSH 密钥时都输入密码变得不切实际。ssh-agent 通过在会话期间将解密的密钥缓存在内存中来解决此问题。

启动 ssh-agent 并添加密钥

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

系统会提示您输入一次密码。之后，SSH 操作会自动使用缓存的密钥。

有用的 ssh-agent 命令

# List currently loaded keys
ssh-add -l

# Remove a specific key from the agent
ssh-add -d ~/.ssh/mykey

# Remove all keys from the agent
ssh-add -D

将公钥复制到远程服务器

在远程服务器上安装公钥的最简单方法是使用 ssh-copy-id:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@remote-host

这会将您的公钥附加到远程服务器上的 ~/.ssh/authorized_keys，并自动设置正确的权限。

如果 ssh-copy-id 不可用，请手动执行：

cat ~/.ssh/id_ed25519.pub | ssh user@remote-host "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

SSH 密钥问题的审计和调试

详细连接日志

当 SSH 身份验证失败时，详细模式会显示确切发生的情况：

ssh -v user@host

获取更多详细信息：

ssh -vvv user@host

此输出显示尝试了哪些身份文件、是否咨询了代理以及身份验证在何处失败。

检查服务器端 SSH 日志

在远程服务器上，SSH 身份验证事件被记录到：

# Debian/Ubuntu
tail -f /var/log/auth.log

# CentOS/RHEL/Fedora
tail -f /var/log/secure

# Systems using journald
journalctl -u sshd -f

验证您的 authorized_keys 文件

# Check the file exists and has correct permissions
ls -la ~/.ssh/authorized_keys

# View its contents
cat ~/.ssh/authorized_keys

# Count how many keys are authorized
grep -c "ssh-" ~/.ssh/authorized_keys

SSH 密钥安全最佳实践

正确的密钥管理不仅仅是了解文件存储位置。在您管理的每个系统上遵循以下做法：

1. 每个用途使用一个密钥

切勿在不同的环境、客户端或项目中重复使用相同的 SSH 密钥。为个人访问、部署自动化和团队共享访问使用单独的密钥。

2. 定期轮换密钥

将 SSH 密钥视为密码 — 定期轮换它们，特别是在团队成员离职或怀疑泄露后。

3. 审计 authorized_keys 文件

定期检查每个服务器上授权了哪些公钥。删除属于前员工、已弃用的自动化或无法识别来源的任何密钥：

# Find all authorized_keys files on a system
find / -name "authorized_keys" 2>/dev/null

4. 禁用密码身份验证

配置 SSH 密钥后，在 /etc/ssh/sshd_config 中完全禁用基于密码的 SSH 登录：

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password

更改后重启 sshd：

systemctl restart sshd

5. 限制 Root 密钥使用

避免在多个环境中使用 root SSH 密钥。改用具有各自密钥的启用 sudo 的用户账户。

6. 为大规模部署使用基于证书的身份验证

对于大型基础设施，考虑使用 SSH 证书（通过 SSH 证书颁发机构）而不是管理单个 authorized_keys 条目。这大大简化了跨多个服务器的访问管理。

云和托管环境中的SSH密钥

在云或托管环境中部署服务器时，SSH密钥管理变得更加关键。大多数平台——包括VPS托管提供商——允许您在配置时注入公钥，使您能够立即获得安全访问，而无需设置密码。

对于管理多个环境的团队，考虑将您的SSH密钥策略与结构化的VPS控制面板设置配对，这可以简化整个基础设施中的用户管理和访问控制。

如果您运行需要超越SSH的安全通信的Web应用程序或服务，将您的服务器设置与正确配置的SSL证书配对，可以确保所有流量的端到端加密——不仅仅是管理访问。

对于依赖电子邮件托管与其服务器基础设施的团队，SSH密钥管理扩展到保护处理您的邮件的系统——这是为什么在所有服务器上保持一致的密钥卫生很重要的另一个原因。

快速参考：SSH 密钥文件位置

结论

了解 SSH 密钥在 Linux 中的存储位置——并有纪律地管理它们——是任何与服务器打交道的人（无论是独立开发者还是大型运维团队的一部分）最重要的技能之一。

总结关键要点：

• 用户密钥存储在 ~/.ssh/ 中，用于客户端身份验证
• 主机密钥存储在 /etc/ssh/ 中，用于向连接的客户端标识服务器
• authorized_keys 控制入站访问——定期审计它
• 文件权限是不可协商的——不正确的权限会无声地破坏 SSH
• Ed25519 是生成新密钥的首选密钥类型
• 始终使用密码短语和 ssh-agent 进行日常密钥管理
• 轮换和审计密钥作为常规安全卫生的一部分

在生产系统上——无论您运行的是专用服务器还是共享基础设施——SSH 密钥管理不当是未授权访问最常见的向量之一。花时间把这件事做好的投资在安全性、可靠性和心理安宁方面获得了回报。

像对待任何关键凭证一样对待您的 SSH 密钥。因为这正是它们的本质。