Go 主机安全面试：Linux SSH Agent Socket 凭据代理滥用检测

ssh-agent 不把私钥直接交给客户端，而是通过 SSH_AUTH_SOCK 指向的 Unix Domain Socket 代为签名。这个设计保护了私钥文件，却也把“可请求签名”变成一项敏感能力：能够连接该 socket 的进程，可能借助 Agent 完成身份认证；如果启用了 SSH Agent Forwarding，远端主机上的进程也可能使用被转发的 socket。

面试官问这个主题，重点不是背 ssh -A 命令，而是能否说清：私钥未落地为什么仍有风险、怎样把 socket 访问归因到进程、怎样区分正常开发工具与异常滥用，以及 Go Agent 怎样低开销地输出可解释证据。

岗位场景

Linux 主机
  -> 采集 ssh-agent 创建的 Unix socket、权限和 inode
  -> 采集进程 connect 到该 socket 的事件与父子进程链
  -> 关联 SSH_AUTH_SOCK、登录会话、sshd 子进程和 SSH 转发上下文
  -> 判断同用户正常使用、自动化任务和远端转发场景
  -> 对可疑签名代理使用输出风险原因和时间线

检测对象是“敏感凭据代理被谁使用”，不是把任何 ssh-agent 或 socket 连接都判为入侵；也不能把一次 socket 连接误称为私钥已经被导出。

高频面试题

1. SSH_AUTH_SOCK 是什么？为什么它是安全检测对象？

简洁答案：SSH_AUTH_SOCK 是环境变量，值是 ssh-agent 提供服务的 Unix socket 路径。客户端经 socket 请求 Agent 使用内存中的私钥签名；私钥通常不会通过协议返回，但签名能力本身足以完成某些 SSH 身份认证。

关键知识点：

• ssh-agent 是签名代理，不等同于私钥文件路径。
• socket 访问权限、所属 UID 和进程上下文决定谁可以请求签名。
• 同一用户下被植入的进程，或已失陷的转发目标主机，可能滥用该能力。
• Agent Forwarding 把本地 Agent 的 socket 代理到远端会话，扩大了可信边界。

Go 落地思路：

• 将 SSH_AUTH_SOCK、socket 路径、inode、owner UID、mode 和所属 Agent 进程作为结构化资产记录。
• 事件结论使用“疑似凭据代理滥用”，不要写成“私钥泄露”，除非另有私钥文件访问证据。
• 不上传私钥、签名请求内容或 socket 流量，只保留最小化元数据。

2. 为什么不能仅按 /tmp/ssh-* 路径报警？

简洁答案：传统 ssh-agent 常在 /tmp/ssh-* 创建目录和 socket，但桌面会话、systemd 用户运行时目录、容器和第三方 Agent 的路径都可能不同。路径是线索，不是身份。

关键知识点：

• 优先通过监听 Unix socket 创建、读取 socket 的 stat 信息和进程关系确认 Agent 身份。
• socket 文件名可变，路径白名单容易被绕过或产生误报。
• 同名路径、软链接和容器挂载会造成路径解释歧义；需要记录 mount namespace。
• 权限过宽、owner 不匹配或 socket 位于意外可写目录，比路径本身更值得提升风险。

Go 落地思路：

• 以 mount_namespace + device + inode 作为 socket 运行期标识，路径只作为展示字段。
• 缓存 inode 到 Agent PID 的映射，并在 socket 删除、进程退出或 inode 复用时失效。
• 对路径、命令行和环境变量设置长度上限，避免异常输入扩大采集成本。

3. Go HIDS 如何采集“哪个进程连接了 Agent socket”？

简洁答案：采集 Unix Domain Socket 的 connect 事件，并将目标 socket 与已登记的 Agent socket inode 关联；再补充进程启动、父子链、用户、namespace 和会话信息。只扫描 /proc 当前状态会丢失短生命周期连接。

关键知识点：

• eBPF 或 auditd 可以补足进程系统调用和执行事件；能力不可用时可降级为 procfs 快照，但要明确覆盖缺口。
• 文件系统路径型 Unix socket 可由路径和 inode 关联；不能假设所有 Unix socket 都有稳定路径。
• /proc/net/unix 是辅助证据，不能单独替代实时连接事件和进程归因。
• 建立进程唯一键时要包含 PID 和 start time，避免 PID 复用串错事件。

Go 落地思路：

type AgentSocketUse struct {
	OccurredAt      time.Time
	SocketID        string // mount namespace + device + inode
	SocketPath      string
	AgentProcess    ProcessRef
	ClientProcess   ProcessRef
	SessionID       string
	Forwarded       bool
	CollectionMode  string // ebpf, auditd, procfs
}

• 内核事件只做轻量过滤和 key 提取，进程树、socket 表和风险规则放在用户态批量关联。
• 使用有界队列与按 SocketID + ClientProcess 的短窗口去重，防止 IDE 或 Git 操作形成告警风暴。

4. SO_PEERCRED 能解决什么，不能解决什么？

简洁答案：对 Unix Domain Socket 服务端而言，Linux 的 SO_PEERCRED 可读取已连接对端的 PID、UID 和 GID，用于确认“谁连到了我”。它是 socket 双端的本地身份线索，不是远程来源证明，也不能让一个外部 HIDS 事后自动得到标准 ssh-agent 的所有连接凭据。

关键知识点：

• SO_PEERCRED 由 socket 服务端读取，正常客户端不能依此识别 Agent 服务端的所有其他客户端。
• 它反映本机内核看到的对端凭据；容器 namespace、代理和转发会影响解释边界。
• 不应为了采集信息包装或替换生产中的 ssh-agent，这会改变认证链路并引入兼容性风险。

Go 落地思路：

• 如果自研 Unix socket 服务需要鉴权，可在 accept 后读取 peer credential 并最小权限控制。
• 对标准 ssh-agent 的检测优先使用 eBPF/auditd 的连接事件与进程事件关联，而非假设能从 Agent 端直接读到审计日志。
• 上报中标出 collection_mode 和缺失字段，避免把推断包装成确定事实。

5. 如何识别 SSH Agent Forwarding 带来的风险？

简洁答案：远端登录会话中的转发 socket 代表远端进程可代本地 Agent 请求签名。私钥仍在发起端，但远端主机一旦不可信、被入侵或存在恶意多用户程序，攻击者可能利用转发能力认证到其他系统。

关键知识点：

• ssh -A、ForwardAgent yes 和跳板机会扩大可使用 Agent 的环境。
• 远端看到的 socket 使用者常是 sshd 会话派生进程，需要关联登录用户、SSH_CONNECTION、TTY 和父子链。
• 开启转发不是恶意行为，CI、跳板机和运维工作站都可能合法使用。
• 发起端记录“启用了转发”，不等于能证明远端每次签名请求的真实意图。

Go 落地思路：

• 在远端 Agent 上将“socket 使用者来自 sshd 会话且非预期命令链”作为风险因子。
• 在发起端将 Agent Forwarding 作为可配置的暴露面指标，而不是单独高危告警。
• 对高价值环境优先提示禁用全局转发、按主机显式开启，并配合 ssh-agent 的确认约束或硬件密钥策略。

6. 正常 Git、IDE 使用和异常 socket 滥用怎么区分？

简洁答案：不能只看 git、ssh 或连接次数。要比较 socket owner、执行用户、父子进程、命令来源、登录会话、主机角色和后续网络行为；同用户交互式 Git 拉取通常可信度更高，而 Web 进程、定时任务或临时目录落地程序连接用户 Agent 则应提高风险。

关键知识点：

• 合法链路常见为终端或 IDE -> git/ssh -> SSH_AUTH_SOCK。
• 高风险链路包括 sshd 会话、Web RCE、异常 cron、容器进程或 /tmp、/dev/shm 落地程序访问其他用户的 Agent。
• 同 UID 不等于可信；多租户跳板机需要额外结合终端会话和业务基线。
• 一次正常连接不说明安全，多次连接也不天然恶意；重在异常主体和攻击链上下文。

Go 落地思路：

• 规则输入至少包含 client/agent UID、进程可执行文件、命令行摘要、父进程、TTY、login session、路径来源、namespace 和网络后继事件。
• 白名单精确到主机组、用户、可执行文件 hash 或已知 CI job，不按全局进程名放行。
• 规则命中给出 reason code，例如 web_process_uses_user_agent_socket，让客户能复核结论。

7. 面对高频 socket 事件，如何保证 Agent 性能和数据安全？

简洁答案：Agent 只采集用于归因的元数据，内核侧先过滤非 Unix socket 和非已登记 inode，用户态做有界缓冲、聚合和丢失统计。绝不能为排障记录或上传 Agent 协议载荷。

关键知识点：

• socket 协议载荷可能包含挑战、主机和用户上下文，采集价值低且隐私与安全风险高。
• CPU、内存和队列上限必须可观测；满载时丢弃低风险事件并上报覆盖缺口。
• 与其把每次 connect 上报，不如按时间窗口聚合同一进程与同一 socket 的使用次数。
• 事件关联必须超时，避免未完成的进程树或网络关联一直占内存。

Go 落地思路：

key := event.SocketID + "|" + event.ClientProcess.UniqueID()
if aggregator.SeenRecently(key, time.Minute) {
	return // 保留计数，抑制重复原始事件
}

• SeenRecently 需要容量上限和过期淘汰；它是降噪缓存，不应成为安全判定的唯一依据。
• 以指标暴露采集速率、队列长度、丢失数、聚合数和降级状态，方便线上定位漏报边界。

8. 客户问“这次告警是否意味着 SSH 私钥已泄露”时如何回答？

简洁答案：先明确证据边界：socket 使用事件说明某进程尝试或完成了凭据代理交互的可观测步骤，并不直接证明私钥文件被读取或导出。随后核查调用进程、登录会话、socket 所属、是否为转发场景、目标主机和后续认证/网络事件。

排查顺序：

1. 确认 Agent socket 的 owner、mode、路径和 Agent PID 是否符合预期。
2. 核查 client PID 的可执行文件、hash、命令行、父子链、UID、TTY 和启动来源。
3. 判断是否来自 sshd、cron、容器、Web 服务或交互式开发链路。
4. 检查该进程前后的 SSH 连接、认证日志和异常外联，但不要把相关性说成因果。
5. 对确认不可信的会话撤销其访问路径，必要时停止 Agent、轮换受影响凭据并审计转发配置。

Go 落地思路：

• 告警详情展示“观测事实”“关联证据”“推断结论”三段，分别标明置信度。
• 保留原始事件 ID 和关联时间窗口，支持客户复现查询，避免只能看到一句模糊的高危标签。

学习要点

方向	需要掌握
SSH 机制	ssh-agent、SSH_AUTH_SOCK、签名代理、Agent Forwarding
Linux IPC	Unix Domain Socket、inode、权限、mount namespace、SO_PEERCRED
采集归因	connect、exec、进程树、procfs、auditd、eBPF、PID 复用
Go 工程化	有界队列、事件去重、TTL 缓存、能力降级、可观测性
误报治理	Git/IDE/CI 基线、会话上下文、精确白名单、reason code
客户排障	证据边界、转发风险、最小化数据、凭据处置

小练习/复盘题

1. 设计 AgentSocketUse 的 ProcessRef，保证 PID 被复用时不会串错进程。
2. 为“Web 服务进程连接交互用户的 Agent socket”写一条包含证据字段的规则。
3. 为什么 Agent Forwarding 的风险不能直接等同于私钥文件泄露？
4. 如何为 CI runner 使用 Agent socket 建立精确基线，而不放行所有 git 进程？
5. 如果 eBPF 不可用且只能读取 procfs，你会向服务端声明哪些检测覆盖缺口？