当前位置：首页 > news >正文

SSH公钥登录实战：从原理到应急响应与权限维持

news 2026/5/22 7:10:10

1. 从应急响应到持久化：一次特殊的SSH公钥登录实战复盘

那天晚上，我正在复盘一个已经归档的渗透测试项目，突然想起一个挺有意思的细节。当时我们通过一个Web应用的RCE漏洞拿到了目标Linux服务器的低权限shell，一番提权操作后，最终站上了root的位置。但问题来了，目标机器不出网，我们拿到的密码哈希在彩虹表里跑了一天一夜也没结果，常规的反弹shell因为网络策略限制也走不通。眼看入口就要因为应用重启而丢失，团队里一位老师傅轻描淡写地说：“试试给它种个公钥吧，以后想什么时候进就什么时候进。” 这个操作，后来成了我们内部应急响应和权限维持的经典案例之一，尤其适合那种“只进不出”的内网核心主机。今天，我就把这个从实战中沉淀下来的、利用SSH公钥实现无密码登录的完整流程、背后的原理，以及无数个坑里总结出的经验，掰开揉碎了讲给你听。无论你是安全工程师在做应急响应，还是运维人员需要管理大量无外网访问的服务器，这套方法都能让你在关键时刻多一个可靠的选择。

2. 核心思路与场景深度解析：为什么是公钥登录？

2.1 目标场景的精准画像

首先，我们必须明确这个方法适用的典型场景，它绝不是SSH登录的常规用法，而是特定困境下的“特种作战”方案。

核心困境一：认证凭证缺失。这是最直接的动因。你通过漏洞利用（如RCE、反序列化）或本地提权（如脏牛、sudo滥用）拿到了root权限的shell，但/etc/shadow里的密码哈希强度很高，短时间内无法破解。你无法得知明文密码，也就无法通过su或ssh root@host加密码的方式建立一个新的、可靠的会话。

核心困境二：网络访问受限。目标服务器处于严格的内网环境，防火墙策略禁止了所有向外的主动连接。这意味着你无法让目标机反向连接你的监听端口（即反弹Shell），因为出站流量被阻断。同样，像nc、bash -i >& /dev/tcp/...这类反向Shell技巧全部失效。

核心困境三：需要持久化与稳定性。你获得的初始Shell可能不稳定（例如通过Web漏洞注入的Shell），随时可能因为进程终止、会话超时或应用重启而断开。你需要一个像“后门”一样稳定、隐蔽、随时可用的访问通道，并且最好能绕过后续可能变更的密码。

2.2 公钥认证原理：一把钥匙开一把锁

为什么公钥登录能解决上述问题？这要从SSH的认证机制说起。SSH支持多种认证方式，最常见的是密码认证和公钥认证。

密码认证：你告诉服务器“我是谁”（用户名）和“我的密码是什么”（口令）。服务器核对/etc/shadow中的哈希值，匹配则放行。这需要你知道密码明文。
公钥认证：你向服务器证明你拥有某把“私钥”。这个过程涉及非对称加密：
1. 密钥对：你在本地使用ssh-keygen生成一对密钥：一个私钥（id_rsa），必须严格保密；一个公钥（id_rsa.pub），可以公开分发。
2. 信任建立：你将公钥写入目标服务器对应用户家目录下的~/.ssh/authorized_keys文件中。这个操作相当于在服务器的锁芯里登记了你公钥这把“钥匙”的齿纹。
3. 挑战-响应：当你连接时，客户端声明“我想用密钥A登录”。服务器找到对应的公钥A，生成一段随机字符（挑战），并用公钥A加密后发送给客户端。
4. 身份验证：客户端必须用私钥A解密这段密文，并将解密结果发回服务器。服务器验证结果正确，即证明客户端拥有私钥A，认证通过。

整个过程，私钥从未离开过你的机器，服务器也无需知道你的私钥是什么。因此，只要你能将公钥文件内容写入目标服务器的authorized_keys，你就永久性地获得了无需密码的登录能力。这正是我们解决“无密码”和“需持久化”困境的密码学基础。

2.3 方案优势与潜在风险权衡

优势：

高稳定性：一旦配置成功，只要SSH服务正常运行、网络可达、公钥未被移除，连接就100%可靠，不受进程、会话中断影响。
高隐蔽性：在系统日志（/var/log/auth.log或/var/log/secure）中，成功的公钥登录记录与正常管理登录无异，没有特殊的失败尝试记录，不易被基于暴力破解告警的监控发现。
免交互：非常适合脚本化、自动化运维或渗透测试后期的持久化控制。
绕过密码变更：即使目标系统管理员后续修改了root密码，只要你的公钥还在，你的访问权限就在。

风险与注意事项：

操作痕迹：修改sshd_config、重启sshd服务、在.ssh目录创建文件，这些操作都会在文件系统上留下时间戳痕迹，可能被取证工具发现。
私钥泄露：用于生成公钥的私钥是最高机密。如果私钥文件泄露，等同于该服务器权限完全泄露。因此，密钥的生成和管理必须谨慎。
合规性问题：在非授权环境中，此行为属于非法入侵。本文仅从技术防御角度探讨，用于理解攻击手法以加强防护，或在获得明确授权的渗透测试、内部应急响应中使用。

注意：本文所有操作均假设在已获得合法授权的安全测试或自己完全掌控的内部服务器环境下进行。未经授权访问他人计算机系统是违法行为。

3. 实战操作全流程拆解与精讲

下面，我们按照一次完整的操作流程，分解每一个步骤，并深入讲解其中的细节和“坑点”。

3.1 步骤一：目标主机SSH服务配置修改

拿到root权限的Shell后，第一件事是确保目标服务器的SSH服务允许公钥认证。

操作命令：

echo "RSAAuthentication yes" >> /etc/ssh/sshd_config echo "PubkeyAuthentication yes" >> /etc/ssh/sshd_config systemctl restart sshd

逐行精讲：

echo “RSAAuthentication yes” >> /etc/ssh/sshd_config
- 作用：启用RSA算法进行公钥认证。虽然较新的OpenSSH版本中，PubkeyAuthentication已涵盖此功能，但显式声明可以兼容更老版本的配置。
- 细节：>>是追加操作。如果配置文件中已存在RSAAuthentication行，此命令会新增一行，可能导致配置重复但通常无害。更稳妥的做法是使用sed进行替换，但在应急的root shell下，追加是最快最不容易出错的方式。
echo “PubkeyAuthentication yes” >> /etc/ssh/sshd_config
- 作用：这是核心配置，启用公钥认证方式。没有这一项，后续所有操作都无效。
- 细节：同样使用追加。检查是否生效可以用grep -i “PubkeyAuthentication” /etc/ssh/sshd_config。
systemctl restart sshd
- 作用：重启SSH服务，使配置生效。
- 避坑指南：
  - 风险：重启sshd服务会断开所有当前SSH连接！如果你是通过一个不稳定的Web Shell执行此命令，可能导致当前连接断开，且新配置未生效前无法连接，造成“搬起石头砸自己的脚”。
  - 建议操作：在重启前，先确保你有另一个并行的、可靠的连接通道（比如已经存在的另一个SSH会话，或者一个不会被重启影响的终端）。如果没有，一个更安全的方法是使用systemctl reload sshd，它重新加载配置而不断开现有连接，但并非所有系统都支持。最保险的做法是，在修改配置后，先在后台新开一个测试连接，确认无误后再重启主服务。

实操心得：

在修改任何核心服务配置前，先进行备份：cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak。
使用sshd -T可以检查当前生效的配置，在重启前验证配置是否正确解析。
对于使用upstart或sysvinit的老系统，重启命令可能是service ssh restart或/etc/init.d/ssh restart。

3.2 步骤二：本地生成SSH密钥对

这是准备“钥匙”的阶段。你需要在你控制的一台机器上生成密钥对。

操作命令：

ssh-keygen -t rsa -b 4096 -P “” -f ~/.ssh/id_rsa_target

参数深度解析：

-t rsa：指定密钥类型为RSA。虽然Ed25519更现代、更安全，但RSA的兼容性最好，几乎所有环境的SSH都支持。
-b 4096：指定密钥长度为4096位。这是当前推荐的安全长度，2048位也已足够，但4096位更能抵御未来的算力攻击。切勿使用默认的1024位。
-P “”：设置私钥的密码短语（passphrase）为空。这是关键决策点。
- 为空：私钥文件无需密码即可使用，便于自动化脚本，但一旦私钥文件泄露，攻击者可直接使用。
- 设置强密码：每次使用私钥时需要输入密码，安全性高，但无法用于全自动流程。
- 实战选择：在渗透测试或应急场景下，我们通常追求可用性，会设置为空。但事后必须将私钥存储在绝对安全的地方（如加密的密码管理器）。
-f ~/.ssh/id_rsa_target：指定生成的密钥文件名。这里没有使用默认的id_rsa，而是加了_target后缀。这是一个极其重要的好习惯。
- 为什么？你的~/.ssh/id_rsa可能是你登录其他重要服务器（如公司跳板机、Git仓库）的默认私钥。将其用于目标机器，会在连接时暴露你的本地用户名和主机名（密钥注释部分），造成信息泄露。使用独立的密钥文件，并在连接时通过-i参数指定，可以隔离风险。

命令执行后，会生成两个文件：

~/.ssh/id_rsa_target：私钥。权限自动设置为600（-rw-------），内容以-----BEGIN OPENSSH PRIVATE KEY-----开头。此文件等同于最高权限密码，必须严防泄露。
~/.ssh/id_rsa_target.pub：公钥。内容是一长串以ssh-rsa AAAAB3...开头的文本，末尾通常有user@hostname的注释。这个注释可以修改，不影响功能。

关键注意事项：

生成环境：务必在你信任的、干净的机器上生成。避免在虚拟机快照、临时云主机等可能被他人恢复或检查的环境中操作。
权限检查：确保~/.ssh目录权限为700（drwx------），公钥文件权限为644，私钥为600。权限错误会导致SSH客户端出于安全考虑拒绝使用密钥。

3.3 步骤三：将公钥植入目标主机

这是将“钥匙齿纹”登记到目标服务器“锁芯”的过程。你需要把上一步生成的id_rsa_target.pub文件的内容，写入目标机root用户的authorized_keys文件。

方法一：直接命令写入（最常用）假设你已经将公钥内容复制到了剪贴板，或者可以通过不稳定的Shell执行echo命令。

# 1. 确保.ssh目录存在，权限正确 mkdir -p /root/.ssh chmod 700 /root/.ssh # 2. 将公钥内容追加到authorized_keys文件 echo “ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC8Zrks74SYQ4JzKFvYPyL2tG+Scx/y/gIDk5znJF6XKjJ2MFS7RfsjKqpRk7bb+bDpgb5awiMzMOUgwBDheJKerji9/FD+jHEI133ejCZphiPL0+OItLdl7uUt+NFMMPNeXh9lmDOwApxVg54xhDjyzWYaV6xQgvWuZK+6qNBD1TW2/zXImeHpC+L37KQSgFvtxyOiYw/Uq/Caoa9VkcFsUsJ1ftmKSh7unkEJiJAHpzmI0SquNdrgTJ5AiVclQbTa8viyl+irXYjUyvxWKCqBhMhuQQFEMRdViVStgSRoVREEH361J7T7oCC0rJE2XV8MlejXZGi7if34gYHYgyBKvEQ9/Ff+fkQV5LXdZLkC0h3wOBLV9lWwMamlFSjJMTSBlZP1syHYV/X1YNO76SmLUUi48PwDQa52g0tI2TusDmjgARWxwhCndu463dwbCcGjfHnSEAWEB2WGJcKOcpfGLUrdDt9My/d26dfMTNdlaw+kdnDVlYvk0qnyBBZhyfE= generated-key” >> /root/.ssh/authorized_keys # 3. 修正authorized_keys文件权限 chmod 600 /root/.ssh/authorized_keys

重要细节：

mkdir -p：如果目录不存在则创建，存在则不报错。
chmod 700 /root/.ssh：SSH协议严格要求.ssh目录权限必须是700（所有者完全控制），组和其他用户无任何权限，否则会因安全原因拒绝公钥认证。
echo … >>：使用>>追加，避免覆盖文件中可能已存在的其他授权公钥。
chmod 600 /root/.ssh/authorized_keys：该文件权限必须是600或更严格，同样是为了满足SSH的安全要求。

方法二：通过SCP/SFTP上传（当有稳定连接时）如果你已经有一个可用的SSH会话（即使是用密码登录的），可以更方便地上传。

# 从本地机器操作，将公钥文件上传到目标机 scp -P 22 ~/.ssh/id_rsa_target.pub root@target_ip:/tmp/my_key.pub # 然后在目标机的Shell中执行 mkdir -p /root/.ssh cat /tmp/my_key.pub >> /root/.ssh/authorized_keys chmod 700 /root/.ssh chmod 600 /root/.ssh/authorized_keys rm /tmp/my_key.pub # 清理临时文件

备份与审计意识：在追加公钥前，强烈建议备份原有的authorized_keys文件：

cp /root/.ssh/authorized_keys /root/.ssh/authorized_keys.bak.$(date +%Y%m%d_%H%M%S)

这样，如果操作失误或后续需要清理痕迹，你可以轻松恢复原状。同时，查看一下原文件内容（cat /root/.ssh/authorized_keys），可以了解是否有其他管理员已经配置了公钥，做到心中有数。

3.4 步骤四：进行无密码登录测试

配置完成后，从你的本地机器发起连接测试。

基础连接命令：

ssh -i ~/.ssh/id_rsa_target root@target_ip

-i ~/.ssh/id_rsa_target：指定使用的私钥文件路径。这是使用非默认密钥的关键。
如果一切配置正确，你将直接获得root的Shell，无需输入密码。

进阶用法与参数解释：原文中提到了一个命令：ssh -T root@192.168.1.1 /usr/bin/bash -i

-T：禁用伪终端（pty）分配。这意味着这次连接不会分配一个完整的交互式终端。通常用于执行单条非交互命令。
/usr/bin/bash -i：作为远程命令执行。-i参数使bash以交互模式启动。
这个组合的妙用：它创建了一个交互式的bash会话，但没有分配完整的pty。在某些严格的监控环境下，缺少$TERM环境变量或特定的终端类型，可能使会话看起来更像一个自动化脚本任务，而非人工登录，从而降低被关注的风险。但它的副作用是，一些需要完整终端的程序（如vim,top）可能无法正常工作。

更稳健的测试命令，我推荐：

ssh -i ~/.ssh/id_rsa_target -o “StrictHostKeyChecking=no” -o “ConnectTimeout=10” root@target_ip “whoami && hostname”

-o “StrictHostKeyChecking=no”：首次连接时，自动接受新的主机密钥，避免交互式提示“Are you sure you want to continue connecting? (yes/no)”，便于脚本化。
-o “ConnectTimeout=10”：设置连接超时为10秒。
“whoami && hostname”：连接后执行两条简单命令并退出。这既能验证登录成功（输出root），又能确认连接到正确的主机，还不会留下一个长期空闲的会话。

3.5 步骤五：利用SCP进行无密码文件传输

公钥登录一旦建立，所有基于SSH的工具（如SCP、SFTP、Rsync over SSH）都能享受无密码的便利。

从本地上传文件到目标机：

scp -i ~/.ssh/id_rsa_target -P 22 -r /local/path/to/file_or_dir root@target_ip:/remote/path/

-i：指定私钥，同上。
-P 22：指定SSH端口（默认22，如果目标机修改了端口则需对应更改）。
-r：递归复制整个目录。

从目标机下载文件到本地：

scp -i ~/.ssh/id_rsa_target -P 22 root@target_ip:/remote/path/to/file /local/path/

实操心得：SCP与Rsync的选择

scp：简单直接，适合传输单个文件或小目录。
rsync：功能更强大，支持增量同步、断点续传、更详细的进度和权限保持。在需要同步大量文件或经常更新时是更好的选择。

rsync -avz -e “ssh -i ~/.ssh/id_rsa_target” /local/path/ root@target_ip:/remote/path/

-a归档模式，-vverbose，-z压缩传输，-e指定远程shell。

4. 高阶技巧、隐蔽性与痕迹清理

一个合格的实战者，不仅要会“攻”，还要会“藏”和“清”。公钥登录虽然稳定，但留下的操作痕迹需要妥善处理。

4.1 密钥的隐蔽化处理

修改公钥注释：生成密钥时，默认注释是user@hostname，这会泄露你的本地信息。可以在生成时指定，也可以事后修改公钥文件。直接编辑id_rsa_target.pub文件，将末尾的user@hostname改为一个不起眼的字符串，如internal-admin或一个随机ID。
使用非标准端口：如果条件允许，修改目标机的SSH服务端口（/etc/ssh/sshd_config中的Port项），可以绕过一些针对22端口的简单扫描和封锁。
限制来源IP：在authorized_keys文件中，可以在公钥行前面加上from=”1.2.3.4″来限制只有特定IP可以使用该密钥登录。但在渗透场景下，攻击者IP不固定，此方法不适用。防御方则可以利用此特性加强安全。

4.2 操作痕迹的清理（仅供防御方了解）

了解攻击者如何清理痕迹，才能更好地进行溯源和取证。

文件时间戳（atime, mtime, ctime）：touch命令可以修改文件的访问和修改时间，但改变时间（ctime）无法被普通用户直接修改。高级攻击者可能会将备份的原始文件覆盖回来，或者使用/usr/bin/touch -r reference_file target_file将目标文件的时间戳设置为与参考文件一致（如/bin/ls）。
历史命令：root用户执行的命令会记录在~/.bash_history中。清理方法是：history -c清空当前会话历史，然后rm -f ~/.bash_history删除历史文件，或者直接unset HISTFILE禁用当前会话的历史记录，再执行敏感操作。
系统日志：SSH的登录、认证日志通常在/var/log/auth.log（Debian/Ubuntu）或/var/log/secure（RHEL/CentOS）。需要root权限才能修改或删除。直接删除日志文件非常可疑。更隐蔽的做法是使用sed等工具删除包含特定IP或密钥指纹的日志行，但这需要较高的权限和对日志格式的精确了解。
wtmp/utmp日志：记录当前登录用户。可用/usr/bin/utmpdump工具查看和编辑，但操作复杂且风险高。

重要声明：痕迹清理在真实攻击中属于恶意行为，会破坏取证证据。作为防御者和安全研究人员，我们的重点是发现这些痕迹，而不是练习清理。加固系统，确保日志发送到远程的、只追加的日志服务器（如ELK Stack），是应对此类持久化攻击的根本方法。

4.3 防御措施：如何发现和清除非法公钥？

作为系统管理员，应定期审计授权密钥文件，并采取主动防御。

定期检查：

# 检查所有用户家目录下的authorized_keys文件 find /home /root -name “.ssh” -type d 2>/dev/null | xargs -I {} find {} -name “authorized_keys” -type f 2>/dev/null # 查看root的授权密钥 cat /root/.ssh/authorized_keys # 查看所有用户的授权密钥 for user in $(getent passwd | cut -d: -f1); do if [ -f “/home/$user/.ssh/authorized_keys” ]; then echo “=== $user ==“; cat “/home/$user/.ssh/authorized_keys”; fi; done

使用工具监控：部署文件完整性监控（FIM）工具，如AIDE、Tripwire或Osquery，监控/root/.ssh/authorized_keys、/etc/ssh/sshd_config等关键文件的任何更改。
强化SSH配置：
- 在/etc/ssh/sshd_config中设置PermitRootLogin prohibit-password或PermitRootLogin no（如果不需要root直接登录）。
- 使用AllowUsers或AllowGroups限制可以登录的用户。
- 禁用密码认证，强制使用公钥认证：PasswordAuthentication no。这能从根本上杜绝密码爆破，但要求你提前部署好自己的公钥。
- 使用Fail2ban等工具防御暴力破解。
清除非法密钥：一旦发现可疑公钥，立即从对应的authorized_keys文件中删除该行，并调查入侵途径。

5. 常见问题排查与实战案例复盘

即使按照步骤操作，也可能会遇到连接失败的情况。下面是一个快速排查清单。

5.1 连接失败排查表

问题现象	可能原因	检查命令/解决方案
`Permission denied (publickey).`	1. 公钥未成功写入`authorized_keys`。 2.`authorized_keys`或`.ssh`目录权限不对。 3.`sshd_config`中`PubkeyAuthentication`未设为`yes`。 4. 使用了错误的私钥或用户。	1.`cat /root/.ssh/authorized_keys`确认公钥存在且完整。 2.`ls -la /root/.ssh/`确认目录700，文件600。 3.`grep -i PubkeyAuthentication /etc/ssh/sshd_config`。 4. 检查`ssh -i`指定的私钥路径和登录用户名。
`Connection refused`或`Network is unreachable`	1. SSH服务未运行或端口不对。 2. 防火墙/网络策略阻止。	1.`systemctl status sshd`，`netstat -tlnp \| grep :22`。 2. 检查本地与目标机之间的网络连通性。
`Agent admitted failure to sign using the key.`	SSH代理（ssh-agent）未加载该私钥或加载失败。	1. 使用`ssh-add ~/.ssh/id_rsa_target`添加密钥到代理。 2. 或直接使用`ssh -i`指定，绕过代理。
登录后立即断开	1. 目标机shell配置问题（如`.bashrc`,`.profile`中有`exit`）。 2. 使用的`-T`参数导致环境不完整。	1. 尝试`ssh -i key user@host /bin/sh`使用更简单的shell。 2. 检查目标机对应用户的shell配置文件。
SCP传输失败	除了上述SSH问题，还可能因为磁盘空间不足、权限不足等。	1.`df -h`检查目标磁盘空间。 2. 检查目标路径的写入权限。

5.2 一个真实的踩坑案例：权限的“魔鬼细节”

在一次内部演练中，我严格按照流程操作，但公钥登录始终失败，报Permission denied。排查了所有配置都正确。最后，我无意中执行了ls -la /root，发现/root目录的权限竟然是drwxr-xr-x（755）。问题就出在这里！

SSH协议在公钥认证时，会进行一系列严格的权限检查，以防止私钥文件被其他用户窥探。其中一条就是：用户家目录（/root）、.ssh目录以及authorized_keys文件，组和其他用户都不能有写权限（w）。/root目录的755权限，意味着其他用户有读和执行权限，这虽然比写权限好，但在某些极其严格的SSH配置或版本下，仍然可能被拒绝。

解决方案：

chmod 700 /root

将/root目录权限改为700后，公钥登录立即成功。

经验教训：SSH的公钥认证对文件权限敏感到了“苛刻”的地步。在部署时，务必确保整个路径上的权限都符合要求：

用户家目录：700(drwx------)
.ssh目录：700(drwx------)
authorized_keys文件：600(-rw-------)
id_rsa（私钥，在本地）：600(-rw-------)

5.3 关于不出网机器的思考延伸

原文场景是“机器无法正常出网”。除了用本文的正向公钥登录，还有其他思路吗？有的，这考验的是对网络协议的深入理解。

端口复用：如果目标机上有正在监听的Web服务（80/443），可以尝试利用HTTP/HTTPS隧道工具（如reGeorg,Neo-reGeorg），将流量封装在HTTP协议中，绕过防火墙对非标准端口的限制。但这需要Web服务器支持特定技术（如PHP、JSP）。
DNS隧道：防火墙通常不会完全封锁DNS查询。可以利用iodine,dnscat2等工具，将TCP流量编码到DNS查询和响应中，建立隐蔽通道。这速度较慢，但隐蔽性极高。
ICMP隧道：类似DNS隧道，使用ptunnel等工具将数据封装在ICMP Echo请求和回复（即ping包）中。在一些允许ICMP通行的环境中有效。
寻找出站代理：内网机器可能无法直接出网，但也许能访问某个内部代理服务器。可以尝试查找环境变量（env | grep -i proxy）、配置文件或扫描内网开放的代理端口（如3128, 8080）。

公钥登录，实际上是这些复杂隧道技术失败或不便时，最直接、最稳定的一种“锚定”技术。它不依赖于持续的网络穿透，一旦建立，就提供了一个随时可用的、高质量的访问入口。

查看全文

http://www.jsqmd.com/news/862895/