ssh/rdp压测对象非协议本身，而是底层认证服务与会话链路；需分层设计：先测认证子系统吞吐（如每秒成功ssh握手数），再模拟真实接入，最后长期运行观察资源泄漏；须监控time_wait堆积、连接跟踪表、日志错误及会话状态，并提供p95耗时趋势、内存句柄变化、失败抓包等可回溯证据。

SSH 和 RDP 接入控制本身不是被压测的“服务性能”主体，而是访问通道。真正的压测对象是底层认证服务（如 OpenSSH 的 auth 子系统、Windows 的 Terminal Services 认证模块）和会话建立链路（网络层、协议解析、用户上下文初始化）。直接对 SSH/RDP 做高并发连接冲击，容易误判——很多失败源于连接未完成就断开、密钥交换超时或防火墙限速，而非服务本身崩溃。因此，有效的方案必须分层设计：先隔离验证认证子系统承载力，再模拟真实接入行为，最后叠加长期运行观察资源泄漏与状态退化。

SSH 接入链路压力与稳定性测试要点

重点不在“能连多少台”，而在“单台服务器每秒可成功建立多少个新 SSH 会话”，尤其关注密钥认证路径（非密码）下的吞吐与内存驻留表现：

• 使用 ssh-bench 或自研脚本（基于 paramiko 或 libssh），控制并发连接数，每次连接后立即执行 exit，不维持 shell；记录每秒成功 handshake 数、平均建立耗时、失败原因（timeout / auth-fail / connection-reset）
• 强制启用公钥认证并禁用密码，关闭 UsePrivilegeSeparation（仅测试环境），避免 fork 开销干扰核心 auth 性能
• 监控关键指标：ss -s 查看 TIME_WAIT 连接堆积；cat /proc/net/nf_conntrack | grep :22 | wc -l 观察连接跟踪表占用；journalctl -u sshd -n 100 --no-pager 检查是否有 “max startups” 或 “fork failed” 日志
• 稳定性阶段：持续以 70% 极限速率运行 8 小时，检查 systemctl status sshd 是否出现 restart、free -h 是否内存缓慢增长、ss -i 是否重传率上升

RDP 接入链路压力与稳定性测试要点

RDP 压测更复杂，因涉及图形协商、NLA 验证、会话初始化及 Windows Session Manager 调度。不能只看“能否弹出桌面”，而要看“会话是否真正进入 Active 状态且可交互”：

• 使用 PowerShell + WMI 或 RDPSessionBench 工具（非 GUI 客户端），调用 Invoke-WmiMethod -Class Win32_TerminalServiceSetting -Name CreateSession 模拟登录，跳过 mstsc.exe 图形握手开销
• 确保 NLA 强制开启（UserAuthentication = 1），否则压测结果反映的是弱认证路径，无实际安全意义
• 监控项包括：query session 输出中状态为 Active 的数量；Get-Counter '\Terminal Services*\*' 中 Active Sessions、Logon Rate/sec、Failed Logons/sec；事件查看器中 Microsoft-Windows-TerminalServices-LocalSessionManager/Operational 日志中的 21/24/40 事件
• 极限测试后执行 logoff /server:xxx * 清理会话，观察是否存在 “ghost session”（状态为 Disc / Listen 却无法注销），这是资源泄漏典型信号

统一接入网关层的协同压测设计

若部署了跳板机、堡垒机或 Azure AD Conditional Access 等前置网关，SSH/RDP 实际走的是代理链路。此时压测重心要上移：

• 在网关节点部署 tcpdump -i any port 22 or port 3389，统计原始连接新建速率与 TLS 握手成功率，区分是后端服务瓶颈还是网关转发瓶颈
• 对网关做连接复用能力验证：同一客户端 IP 发起 1000 次 SSH 连接，观察网关是否触发 MaxStartups 限流，或 RDP 网关是否返回 0x204 错误（表示连接队列满）
• 模拟网络抖动：用 tc netem 在网关出口注入 5% 丢包 + 100ms 延迟，测试认证超时容忍度与重试逻辑健壮性
• 日志关联分析：将网关 access.log、后端 sshd 日志、Windows Security Event ID 4624/4625 按时间戳对齐，定位延迟毛刺发生在哪一跳

报告输出必须包含的稳定性证据项

一份可信的评估报告，不能只有“通过/失败”，而应提供可回溯的行为证据：

• 每个测试周期的 连接建立 P95 耗时趋势图（横轴时间，纵轴毫秒），标注拐点时刻
• 内存与句柄数变化曲线（Linux：/proc/PID/status 中 VmRSS / HandleCount；Windows：Get-Process sshd | Select PM, Handles）
• 失败样本抓包（pcap），标出 SYN → SYN-ACK → ACK → SSH banner 的完整时序，确认是服务未响应还是中间设备拦截
• 连续运行 24 小时后的对比快照：启动时 vs 结束时的 ss -s、query session、netstat -an | grep ESTAB | wc -l