SSH密钥认证是Linux上远程登录的一种核心安全机制，它通过一对非对称密钥（公钥和私钥）来验证用户身份，避免了传统密码认证的诸多弱点。简单来说，就是用一把只有你自己有的“钥匙”去开一把放在服务器上的“锁”，比每次输密码安全多了，而且更方便。
解决方案
要实现安全的SSH密钥认证，流程其实挺直观的，但每个步骤的细节都值得注意。
生成SSH密钥对：在你的本地机器上（客户端），打开终端，运行命令：
ssh-keygen -t ed25519 -b 4096 -C "your_email@example.com"
或者如果你更偏好RSA（虽然Ed25519更推荐）：
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
系统会提示你选择保存密钥的路径（通常默认是
~/.ssh/id_ed25519
或
~/.ssh/id_rsa
），并设置一个密码短语（passphrase）。这个密码短语非常重要，它会加密你的私钥，即使私钥文件泄露，没有密码短语也无法使用。我个人强烈建议每次都设置一个强密码短语，这是保护私钥的最后一道防线。
将公钥复制到远程服务器：这是最关键的一步。你需要将刚刚生成的公钥（文件名为
id_ed25519.pub
或
id_rsa.pub
）复制到目标Linux服务器的用户主目录下的
.ssh/authorized_keys
文件中。
推荐方式（最简单且安全）： 使用
ssh-copy-id
命令。
ssh-copy-id user@remote_host
这个命令会自动处理公钥的复制和目标服务器上
~/.ssh
目录及
authorized_keys
文件的权限设置，非常省心。它会提示你输入远程用户的密码。
手动方式（当ssh-copy-id不可用时）：首先，确保远程服务器上存在
~/.ssh
目录，如果没有，创建它：
ssh user@remote_host "mkdir -p ~/.ssh"
然后，将本地公钥内容复制到远程服务器的
authorized_keys
文件中：
cat ~/.ssh/id_ed25519.pub | ssh user@remote_host "cat >> ~/.ssh/authorized_keys"
接着，设置正确的权限，这至关重要：
ssh user@remote_host "chmod 700 ~/.ssh"
ssh user@remote_host "chmod 600 ~/.ssh/authorized_keys"
如果权限设置不当，SSH服务器会出于安全考虑拒绝使用密钥认证。我踩过不少次这个坑，权限不对是导致密钥认证失败最常见的原因之一。
禁用远程服务器上的密码认证（可选但强烈推荐）：为了进一步提升安全性，你应该在远程服务器上禁用密码认证，强制只使用密钥认证。编辑SSH服务器的配置文件
/etc/ssh/sshd_config
：
sudo nano /etc/ssh/sshd_config
找到以下几行，并确保它们被设置成：
PubkeyAuthentication yes
(通常默认就是yes)
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
(如果你不使用PAM进行认证)修改后，保存文件并重启SSH服务：
sudo systemctl restart sshd
(或
sudo service sshd restart
)
客户端配置（可选）：为了方便管理多个服务器或使用非默认私钥，你可以在本地
~/.ssh/config
文件中创建别名：
Host my_server HostName your_remote_host_ip_or_domain User your_username IdentityFile ~/.ssh/id_ed25519 Port 22 # 如果端口不是22
这样，你就可以直接使用
ssh my_server
来连接了。
为什么SSH密钥认证比密码更安全？
在我看来，SSH密钥认证之所以能够取代传统密码成为远程登录的首选，其安全性优势是压倒性的。
首先，它基于非对称加密原理。你生成一对密钥：一个公钥可以随意分发，一个私钥则必须严格保密。认证时，服务器用你的公钥加密一个挑战信息，只有拥有对应私钥的客户端才能解密并响应。这和密码认证完全不同，密码是明文或哈希值在网络上传输（尽管SSH会加密传输通道，但密码本身仍然是可猜测的），而密钥认证过程中，私钥本身从不离开你的本地机器，这从根本上杜绝了私钥在传输过程中被窃取的风险。
其次，密钥的复杂度和长度远超人类能记忆的密码。一个4096位的RSA密钥或者Ed25519密钥，其随机性之高，意味着暴力破解几乎是不可能完成的任务。相比之下，即使是“强密码”，也可能被字典攻击或彩虹表攻击攻破，尤其是在面对算力不断提升的今天。我看到过太多因为密码弱或复用而被攻破的案例，但因为SSH密钥本身被暴力破解而导致的安全事件，几乎闻所未闻。
再者，密钥认证提供了更好的自动化能力。你可以将私钥加载到
ssh-agent
中，配合密码短语，实现无需重复输入密码的无缝连接，这对于脚本自动化部署、持续集成/持续交付（CI/CD）流程来说是不可或缺的。同时，它也降低了因人工输入密码可能带来的错误或泄露风险。
最后，密钥认证能够有效抵御钓鱼攻击。当攻击者试图通过伪造的登录页面骗取你的密码时，你可能会不慎输入。但对于密钥认证，攻击者无法通过一个简单的网页来获取你的私钥，因为私钥只存在于你的本地文件系统，且通常受密码短语保护。这使得钓鱼攻击的成功率大大降低。
如何妥善保管你的SSH私钥？
妥善保管SSH私钥，这在我看来，是整个SSH安全体系中与生成密钥同等重要的一环。私钥一旦泄露，其后果可能比密码泄露还要严重，因为私钥通常能提供对服务器的完全访问权限，而无需任何额外的密码。
最核心的防护措施，就是为你的私钥设置一个强密码短语。我见过太多人为了方便，生成密钥时不设密码短语。这简直是给自己埋雷！想象一下，如果你的笔记本电脑丢失或被盗，而你的私钥没有密码短语保护，任何人拿到你的硬盘，就能直接用你的私钥登录你所有的服务器。有了密码短语，即使私钥文件被复制走，没有这个密码短语，它也只是一堆加密的数据，无法直接使用。虽然每次连接都要输入密码短语可能有点烦，但你可以利用
ssh-agent
来管理，一次输入，多次使用，非常方便。
其次是文件权限。这是Linux系统安全的基础，也是SSH私钥保护的基石。你的私钥文件（如
~/.ssh/id_ed25519
）必须只有你自己有读写权限，其他任何用户都不能有任何权限。通常，这意味着权限应该是
chmod 600 ~/.ssh/id_ed25519
。如果权限设置得过于开放（例如
644
或
777
），SSH客户端会直接拒绝使用这个私钥，因为它认为这不安全。这是我个人在日常使用中，最常遇到但也最容易被忽视的问题点。
新CG儿
数字视觉分享平台 | AE模板_视频素材
412 查看详情 
再来是备份策略。私钥是唯一的身份凭证，如果丢失，你将无法登录依赖该私钥的服务器。所以，务必对其进行加密备份，并存储在安全、离线的位置，比如加密的U盘、云存储（确保是加密的）。但切记，备份的私钥必须是加密的，并且备份介质本身也要安全。
最后，永远不要分享你的私钥。这听起来是常识，但总有人为了图方便，将私钥文件直接发送给同事或朋友。正确的做法是，如果需要共享访问，应该为每个人生成独立的密钥对，并将各自的公钥添加到服务器上。如果私钥不幸泄露，你需要立即将其从所有服务器的
authorized_keys
文件中移除，并生成新的密钥对。
当SSH密钥认证遇到问题时，如何排查？
SSH密钥认证虽然安全高效，但在实际操作中也难免遇到各种问题。我处理过不少这类故障，总结下来，排查思路通常围绕几个核心点展开。
最直接有效的方法是使用详细模式连接：
ssh -v user@remote_host
这个命令会输出大量的调试信息，详细展示SSH客户端和服务器之间的认证过程。很多时候，错误信息会直接告诉你问题出在哪里，比如“Permissions too open”或者“Agent admitted failure to sign using the key”。
检查服务器端的日志是另一个关键步骤。在大多数Linux系统上，SSH认证的日志记录在
/var/log/auth.log
（Debian/Ubuntu）或通过
journalctl -u sshd
（CentOS/RHEL 7+）查看。当客户端尝试连接失败时，服务器端的日志会记录下拒绝的原因，例如“Authentication refused: bad ownership or modes for directory /home/user/.ssh”或者“No more authentication methods available”。这比客户端的错误信息通常更具体。
权限问题是导致密钥认证失败的“头号杀手”。我个人在这上面栽过无数次跟头。请务必检查以下权限：
服务器端用户主目录的权限：
~
目录的权限不能过于开放，通常是
755
或
700
。服务器端
~/.ssh
目录的权限： 必须是
700
。服务器端
~/.ssh/authorized_keys
文件的权限： 必须是
600
。客户端
~/.ssh
目录的权限： 通常是
700
。客户端私钥文件（如
~/.ssh/id_rsa
）的权限： 必须是
600
。你可以使用
ls -ld ~/.ssh
和
ls -l ~/.ssh/authorized_keys
来检查。
公钥是否正确复制也是常见问题。确认你复制到服务器
authorized_keys
文件中的公钥内容是完整且正确的，没有多余的空格或换行符。有时候，手动复制粘贴时会不小心引入这些问题。
SSH代理（ssh-agent）的问题。如果你使用了密码短语保护私钥，但
ssh-agent
没有运行，或者私钥没有被添加到代理中，那么每次连接都会要求输入密码短语，甚至可能因为没有加载私钥而认证失败。你可以通过
ssh-add -l
来查看当前
ssh-agent
中加载了哪些密钥。如果没有，使用
ssh-add ~/.ssh/id_ed25519
来添加。
服务器端SSH配置（sshd_config）。确保
/etc/ssh/sshd_config
中
PubkeyAuthentication yes
没有被注释掉，并且没有其他配置项（如
AuthorizedKeysFile
）指向了错误的路径。修改后记得重启SSH服务。
防火墙或SELinux/AppArmor。偶尔，防火墙规则（无论是客户端还是服务器端）可能会阻止SSH连接。检查
ufw status
或
firewall-cmd --list-all
。另外，SELinux或AppArmor的安全策略也可能阻止SSH服务访问
authorized_keys
文件，但这相对少见，通常在日志中会有明确提示。
遇到问题时，保持冷静，一步步排查，大多数问题都能迎刃而解。
以上就是Linux如何管理SSH密钥认证？_Linux安全远程登录配置技巧的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/792969.html
微信扫一扫 
支付宝扫一扫 
