如何在Linux中管理密钥对 Linux ssh-keygen生成-linux运维-PHP中文网

SSH密钥对通过非对称加密实现安全远程登录，使用ssh-keygen生成密钥，ssh-copy-id部署公钥，私钥加密码保护并严格设置文件权限，结合~/.ssh/config和ssh-agent可高效管理多密钥，避免密码认证风险，提升安全性和自动化能力。

如何在linux中管理密钥对 linux ssh-keygen生成

在Linux环境中，管理密钥对，特别是通过

ssh-keygen

登录后复制

工具生成的SSH密钥，是确保远程连接安全与便捷的核心操作。简单来说，它涉及生成一对加密密钥——一个公开的，一个私有的——然后将公钥部署到你想要访问的服务器上。当你尝试连接时，你的本地客户端会使用私钥与服务器上的公钥进行身份验证，从而取代传统的密码输入。

解决方案

SSH密钥对的使用，在我看来，是远程管理Linux服务器的基石。它的流程其实并不复杂，但每一步都值得细心对待。

首先，我们通常在本地机器上生成密钥对。最常见的命令是：

ssh-keygen -t rsa -b 4096 -C "你的邮箱或标识符"

登录后复制

这里，

-t rsa

登录后复制

指定了加密算法为RSA，虽然现在也有更现代的

ed25519

登录后复制

，但RSA依然广泛兼容。

-b 4096

登录后复制

设置了密钥的位数，4096位被认为是当前非常安全的长度。而

-C

登录后复制

参数则为你的密钥添加一个注释，这在管理多个密钥时非常有帮助，一眼就能看出这个密钥是做什么用的。执行这个命令后，系统会提示你选择保存密钥文件的位置（默认是

~/.ssh/id_rsa

登录后复制

），以及是否设置一个密码（passphrase）。强烈建议设置一个强密码，即使私钥被盗，没有密码也无法使用，这就像给你的私钥又加了一把锁。

生成成功后，你会得到两个文件：

id_rsa

登录后复制

（私钥）和

id_rsa.pub

登录后复制

（公钥）。私钥是你个人独有的，绝不能泄露给任何人，它的权限也必须严格控制，通常是

chmod 600 ~/.ssh/id_rsa

登录后复制

。公钥则可以安全地分享。

下一步是将公钥部署到目标服务器。最便捷的方式是使用

ssh-copy-id

登录后复制

命令：

ssh-copy-id 用户名@目标服务器IP或域名

登录后复制

这个命令会自动将你的公钥添加到目标服务器用户目录下的

~/.ssh/authorized_keys

登录后复制

文件中。如果目标服务器还没有

.ssh

登录后复制

目录或

authorized_keys

登录后复制

文件，它也会一并创建并设置正确的权限。

如果

ssh-copy-id

登录后复制

不可用或者你更喜欢手动操作，你可以将

id_rsa.pub

登录后复制

文件的内容复制出来，然后通过SSH连接到目标服务器（可能需要输入密码），编辑

~/.ssh/authorized_keys

登录后复制

文件，将公钥内容粘贴进去。记住，

authorized_keys

登录后复制

文件中的每一行都是一个独立的公钥。手动操作时，务必确保

~/.ssh

登录后复制

目录的权限是

登录后复制

，

authorized_keys

登录后复制

文件的权限是

登录后复制

。权限不对，SSH是会拒绝使用密钥的。

完成这些步骤后，你就可以直接使用

ssh 用户名@目标服务器IP或域名

登录后复制

命令进行连接了，系统会尝试使用你的私钥进行身份验证，如果设置了密码，会提示你输入私钥的密码。

为什么SSH密钥对是远程连接的首选，它比密码更安全吗？

从我个人的经验来看，一旦你习惯了SSH密钥，就很难再回到纯密码认证的时代了。它不仅仅是方便，更重要的是它在安全性上提供了质的飞跃。

密码认证的本质是，你需要将你的秘密（密码）通过网络传输给服务器，服务器验证后让你登录。这个过程中，密码有被嗅探、被暴力破解的风险。即使密码设置得足够复杂，也无法完全避免字典攻击或彩虹表攻击。更别提很多人为了方便，会设置一些弱密码，或者在不同服务间复用密码，这简直是安全灾难。

SSH密钥对则完全不同。它基于非对称加密原理。你的私钥永远不会离开你的本地机器。当你尝试连接服务器时，服务器会发送一个随机挑战，你的客户端使用私钥对这个挑战进行签名，然后将签名发回服务器。服务器使用你预先部署的公钥来验证这个签名。如果签名匹配，就证明你是合法的用户。整个过程中，你的私钥从未被传输，也就不存在被截获的风险。攻击者即使截获了通信数据，也无法从中反推出你的私钥。

此外，密钥的长度通常远超密码的复杂度。一个4096位的RSA密钥，其破解难度是天文数字级别的，远超任何人类能记住的复杂密码。这意味着暴力破解几乎不可能成功。

当然，密钥也并非万无一失。如果你的私钥文件本身被盗，并且没有设置密码保护，那么攻击者就能直接冒充你。这就是为什么我反复强调私钥的权限管理和密码保护的重要性。但是，相比于密码认证，SSH密钥对在设计上就提供了更高的安全性层级，并且显著提升了远程操作的效率，尤其是在自动化脚本或持续集成/部署（CI/CD）流程中，密钥认证几乎是唯一的选择。

生成SSH密钥对时有哪些关键选项和最佳实践？

生成密钥对时，

ssh-keygen

登录后复制

提供了几个关键选项，理解它们能让你更好地控制密钥的安全性与适用性。

首先是加密算法的选择。

-t rsa

登录后复制

：这是最常用也是兼容性最好的算法。如果你不确定选择什么，RSA通常是安全的默认选项。

-t ed25519

登录后复制

：这是更现代、更高效且通常被认为更安全的算法。它的密钥长度固定，性能优异，且不易受到某些侧信道攻击。如果你的所有客户端和服务器都支持，我个人更倾向于使用

ed25519

登录后复制

。

然后是密钥长度。

-b 4096

登录后复制

：对于RSA密钥，指定4096位是当前推荐的最佳实践。虽然默认的2048位在短期内可能也够用，但为了长远考虑，4096位提供了更高的安全边际。对于

ed25519

登录后复制

，密钥长度是固定的，所以不需要这个参数。

注释。

-C "your_email@example.com"

登录后复制

：这个注释会附加到公钥文件的末尾。它不会影响密钥的功能，但对于管理多个密钥，或者在

authorized_keys

登录后复制

文件中识别哪个密钥属于哪个用户或哪个目的，都非常有用。养成添加有意义注释的习惯，会让你未来的管理工作轻松很多。

密码（Passphrase）。这是我一直强调的，也是最容易被忽视但极其重要的一个环节。当你生成密钥时，系统会提示你输入一个密码。这个密码是用来加密你的私钥文件的。即使你的私钥文件不幸被泄露，没有这个密码，攻击者也无法使用它。这就像给你的房子加了道大门（SSH密钥），然后又给大门上了一把锁（Passphrase）。当然，每次使用私钥都需要输入密码可能会有些不便，但你可以结合

ssh-agent

登录后复制

来解决这个问题，我会在下一个部分提到。

文件保存位置。默认情况下，

ssh-keygen

登录后复制

会将密钥对保存在

~/.ssh/id_rsa

登录后复制

和

~/.ssh/id_rsa.pub

登录后复制

。如果你需要生成多个密钥对用于不同的目的（例如，一个用于工作，一个用于个人项目），你可以使用

-f

登录后复制

参数指定不同的文件名和路径，例如：

ssh-keygen -f ~/.ssh/id_work_rsa -C "Work Key"

登录后复制

。

最后，权限设置是重中之重。你的

~/.ssh

登录后复制

目录权限应该是

登录后复制

（只有所有者可读写执行）。你的私钥文件（例如

~/.ssh/id_rsa

登录后复制

）权限应该是

登录后复制

（只有所有者可读写）。你的公钥文件（例如

~/.ssh/id_rsa.pub

登录后复制

）权限可以是

登录后复制

（所有者可读写，其他人只读）。如果这些权限设置不正确，SSH客户端会拒绝使用这些密钥，并通常会给出警告信息。我见过太多因为权限问题导致SSH连接失败的案例了。

如何有效管理多个SSH密钥，以及处理常见的连接问题？

随着你使用SSH密钥的场景越来越多，你可能会发现自己需要管理不止一个密钥对。比如，你可能有一个密钥用于公司内部服务器，另一个用于GitHub，还有一个用于个人VPS。这时，

~/.ssh/config

登录后复制

文件就成了你的得力助手。

管理多个密钥

~/.ssh/config

登录后复制

文件允许你为不同的主机或域名定义特定的SSH连接参数，包括指定使用哪个私钥。

一个典型的

~/.ssh/config

登录后复制

文件可能看起来像这样：

NameGPT名称生成器

免费AI公司名称生成器，AI在线生成企业名称，注册公司名称起名大全。

查看详情

Host github.com
    Hostname github.com
    User git
    IdentityFile ~/.ssh/id_github_rsa
    IdentitiesOnly yes

Host my_vps
    Hostname 192.168.1.100
    User admin
    IdentityFile ~/.ssh/id_vps_ed25519
    Port 2222 # 如果你的SSH服务不在默认端口
    IdentitiesOnly yes

Host *
    IdentityFile ~/.ssh/id_rsa
    IdentitiesOnly yes
    # AddKeysToAgent yes # 自动将密钥添加到ssh-agent

登录后复制

```
Host
```
登录后复制
：这是一个别名，你可以在命令行中使用它，比如
```
ssh github.com
```
登录后复制
。
```
Hostname
```
登录后复制
：实际的服务器地址。
```
User
```
登录后复制
：连接时使用的用户名。
```
IdentityFile
```
登录后复制
：指定连接此主机时使用的私钥文件路径。
```
Port
```
登录后复制
：如果SSH服务不在默认的22端口，可以在这里指定。
```
IdentitiesOnly yes
```
登录后复制
：这个选项非常重要。它告诉SSH客户端只尝试
```
IdentityFile
```
登录后复制
指定的密钥进行认证，而不会尝试
```
ssh-agent
```
登录后复制
中加载的所有密钥。这可以避免在连接某些服务器时，因为
```
ssh-agent
```
登录后复制
加载了过多密钥导致认证失败或连接变慢。

SSH Agent的妙用

如果你为私钥设置了密码，那么每次使用密钥连接时都需要输入密码，这无疑会降低效率。

ssh-agent

登录后复制

就是来解决这个问题的。它是一个后台运行的程序，可以缓存你的解密后的私钥。你只需要在会话开始时将私钥添加到

ssh-agent

登录后复制

一次，之后在整个会话期间，所有需要使用该私钥的SSH连接都可以直接进行，无需再次输入密码。

启动

ssh-agent

登录后复制

并添加密钥的典型命令是：

eval "$(ssh-agent -s)" # 启动ssh-agent
ssh-add ~/.ssh/id_rsa # 添加你的私钥，会提示你输入密码

登录后复制

如果你有多个私钥，可以逐一

ssh-add

登录后复制

它们。

处理常见的连接问题

SSH连接失败是常有的事，以下是一些我经常遇到的问题和排查思路：

权限问题：这是最最常见的。如果你的私钥、公钥或
```
~/.ssh
```
登录后复制
目录的权限不正确，SSH会直接拒绝使用密钥。
- 检查本地：
```
ls -l ~/.ssh/
```
  登录后复制
  和
```
ls -l ~/.ssh/id_rsa*
```
  登录后复制
  ，确保私钥是
```
600
```
  登录后复制
  ，公钥是
```
644
```
  登录后复制
  ，
```
.ssh
```
  登录后复制
  目录是
```
700
```
  登录后复制
  。
- 检查服务器：登录到服务器，检查
```
~/.ssh
```
  登录后复制
  目录是
```
700
```
  登录后复制
  ，
```
~/.ssh/authorized_keys
```
  登录后复制
  文件是
```
600
```
  登录后复制
  。
- 调试命令：
```
ssh -v 用户名@服务器
```
  登录后复制
  可以显示详细的调试信息，帮助你定位权限问题。
公钥未正确部署：
- 确认服务器上的
```
~/.ssh/authorized_keys
```
  登录后复制
  文件是否存在，并且你的公钥内容完整无误地复制在其中，没有多余的空格或换行符。
- 注意：
```
authorized_keys
```
  登录后复制
  文件中的每个公钥应该占一行。
SSH服务配置：
- 服务器上的SSH服务（
```
sshd
```
  登录后复制
  ）可能配置为不允许密钥认证。检查
```
sshd_config
```
  登录后复制
  文件（通常在
```
/etc/ssh/sshd_config
```
  登录后复制
  ），确保
```
PubkeyAuthentication yes
```
  登录后复制
  ，并且没有被其他设置（如
```
PasswordAuthentication yes
```
  登录后复制
  ）冲突。修改后需要重启
```
sshd
```
  登录后复制
  服务。
防火墙：
- 本地或服务器上的防火墙可能阻止了SSH端口（默认22）的通信。检查防火墙规则。
用户名不匹配：
- 确保你使用的SSH连接用户名与服务器上拥有
```
authorized_keys
```
  登录后复制
  文件的用户匹配。