痛点拆解：为什么「能连上」在 2026 年仍可能是假象
痛点 1：Fail2ban 阈值与 CI NAT。Linux 上常见，但 macOS 需对齐日志字段；阈值过低会把云厂商 NAT 里的 Runner 一并拉黑，排障常误判为 rsync 或磁盘。
痛点 2：只改端口/密钥却忽略 LoginGraceTime。慢扫可堆半开连接；过短又误伤高 RTT 合法握手，需与 known_hosts 同审。
痛点 3：matrix 与错误凭据叠加。数秒内大量失败认证会逼近 MaxAuthTries，应把并行度与凭据轮换绑同一工单，而非只靠防火墙加白。
痛点 4：忽略并发与审计。不调 MaxSessions/ClientAliveInterval 会「限次严但仍打满」；与 统一日志审计割裂则难区分攻击与误配。
威胁模型：扫描暴力破解与合法 CI 抖动应分层处置
暴力破解常见为高频多用户名字典；CI 抖动多为固定服务账号与密钥，根因常在主机密钥、跳板、权限或配额。混在同一失败计数器会导致过松或过紧。
推荐把控制面拆为三层：网络可达性（安全组、Tailscale、专线）、传输与主机身份（known_hosts、证书、跳板）、认证与会话（仅密钥、MaxAuthTries、并发、审计）。本文聚焦第三层与第二层的交界：在主机身份已校验的前提下，如何用限次与宽限期降低 CPU 与日志噪声，同时给 CI 留出可解释的失败预算；ProxyJump 场景下优先在跳板聚合限次，内网 Mac 侧保持温和阈值，并与 SSH 用户证书互补。
可量化基线：把运维拍脑袋变成可审计数字
第一，记每 IP 每小时失败认证与成功会话比，失败远大于成功且用户名分散偏扫描。第二，同一 deploy key 失败陡升先查 known_hosts 与跳板。第三，把 MaxAuthTries 与 matrix 并行度同表估算尖峰。
第四，为 LoginGraceTime 取办公区与 CI 区域的 RTT P95 作参考；第五，把封锁事件与发布窗口关联，凭据轮换不同步常伪装成攻击；第六，把 SHA256 闸门失败重试与认证失败分桶，避免误加白名单。
决策矩阵：限次、宽限期、外层封禁与 CI 白名单如何组合
| 策略 | 适用场景 | 主要收益 | 主要风险 |
|---|---|---|---|
仅提高 MaxAuthTries 上限 | CI 重试多、暂时无法修正密钥 | 快速止血 | 对密码若未关闭仍放大爆破面；必须配合 PasswordAuthentication no |
收紧 MaxAuthTries + 仅密钥 | 公网直连、强合规 | 显著降低口令爆破噪声 | 误配密钥时更快失败；需改进流水线退避 |
缩短 LoginGraceTime | 明显半开连接攻击 | 降低资源占用 | 高 RTT 合法用户可能被断开；要分层到跳板 |
| 云防火墙速率限制 | 大规模扫描 | 在到达 sshd 前丢弃洪峰 | 阈值过低影响批量合法连接；要与 CI 出口表对齐 |
| Fail2ban 类黑名单 | Linux 侧、日志字段稳定 | 自动化响应 | 误封共享 NAT；需白名单与通知渠道 |
| 私网或 mesh 入口 | 可接受架构调整 | 从根上减少公网暴露 | 需要身份与路由治理；参考 Tailscale/Headscale 私网文 |
犹豫时只问三题：是否仍允许密码？CI 是否共享 NAT？跳板是否单点？任一为是就不要只靠单一参数。
实操步骤：从 Match 块到流水线退避的最小闭环
# /etc/ssh/sshd_config 片段（概念示例，按发行版与平台调整）
# PasswordAuthentication no
# KbdInteractiveAuthentication no
# ChallengeResponseAuthentication no
# MaxAuthTries 4
# LoginGraceTime 45
# ClientAliveInterval 30
# ClientAliveCountMax 4
# Match User ci-upload
# MaxAuthTries 6
# ForceCommand internal-sftp -d /Volumes/artifacts
# GitHub Actions 侧：在错误重试前加入 sleep 指数退避，降低瞬时失败认证尖峰
步骤一：人类与 CI 上传账号分 Match。步骤二：internal-sftp 核对 ForceCommand 与 Chroot 权限，避免权限误报成认证失败。步骤三：MaxSessions 对齐 Job 并发。步骤四：CI 固定 UserKnownHostsFile 与 StrictHostKeyChecking=yes。步骤五：凭据大轮换时暂时提高外层阈值并双人复核。步骤六：Runbook 演练写错密钥—观察计数—修正恢复。
强相关 CTA：把身份、会话、传输放在同一评审表
推荐阅读顺序：本文 → known_hosts 固定 → OIDC 与专用账号 → 并发与 keepalive → 跳板单入口 → 首页了解托管资源池。把「限次」提前到架构评审，而不是等扫描洪峰把日志磁盘写满后再救火。
FAQ 与为什么考虑 SFTPMAC 托管远程 Mac
macOS 上能用 Fail2ban 吗？
可以自建，但成本在日志对齐与升级维护；多数团队更倾向先用系统防火墙、上游云安全组与仅密钥组合，再把敏感入口收敛到私网。
MaxAuthTries 与 PAM 模块关系？
不同发行版与 Apple OpenSSH 组合下行为略有差异；变更后务必用受控账号压测，并在审计日志中核对失败原因码。
总结：公网 SFTP 入口在 2026 年应把「限次 + 宽限期 + 仅密钥 + 主机身份校验 + 并发预算」写成同一张运维表，再用外层限速与拓扑收敛处理扫描洪峰，而不是依赖单一魔法参数。
局限：自建远程 Mac 需要持续维护系统补丁、日志、密钥与出口表；团队若希望把稳定在线的 Apple 原生构建入口与可运营的 SFTP/rsync 面打包交付，减少 DIY 防火墙与 Runner 漂移的隐性成本，SFTPMAC 托管远程 Mac 让交付侧专注产物与发布，而不是反复在「误封 CI」与「被扫爆」之间走钢丝。
把限次参数、跳板拓扑与 CI 并发预算写进同一变更单，托管环境更容易做到可审计与可演练。