Pain breakdown
Public internet exposure of sshd and SFTP on a remote Mac is a classic split-brain problem for platform teams in 2026. On one side, security wants aggressive throttling, short grace times, and automated bans. On the other side, continuous integration depends on bursty, parallel jobs that may share cloud NAT egress and may legitimately retry after transient failures. If you tune MaxAuthTries without looking at GitHub Actions concurrency, you can create an outage that looks like a network problem but is actually authentication pressure. If you deploy Fail2ban-style bans without understanding shared NAT pools, you can ban an entire region of runners and spend hours blaming rsync flags.
Many teams still treat passwordless key-only authentication as sufficient hardening. Keys remove password guessing, but they do not remove brute-force noise against the SSH handshake itself, nor do they remove misconfiguration storms when a deploy key rotates but the workflow secret lags by one commit. LoginGraceTime becomes a second lever that is often copied from generic guides without measuring real round-trip times from your office regions and from the CI regions you actually use. The result is either wasted CPU on half-open sessions or false negatives where legitimate engineers are cut off during first connection while verifying host keys.
Matrix builds multiply the blast radius. Ten parallel jobs each attempting three authentication retries can create thirty failure events in a short window even when no attacker exists. If MaxAuthTries is globally tight and not segmented by Match user blocks, you can exhaust the attempt budget for everyone, including interactive developers who are trying to debug the same incident. The operational fix is not only to raise limits blindly, but to pair authentication budgets with correct host key pinning, reduced parallelism during credential rotation windows, and exponential backoff in workflows.
Finally, ignoring MaxSessions and ClientAliveInterval while tightening MaxAuthTries produces a deceptive posture: you appear strict on authentication attempts, yet you still allow session pile-ups that starve sftp-server workers or confuse operators reading Unified Logging. Coupling authentication policy with concurrency and audit streams is mandatory if you want to answer whether a spike was an attack or a mis-rotated key.
Threat model
Brute force attempts against SSH usually show high cardinality of usernames, repetitive timing, and password or keyboard-interactive paths when those remain enabled. CI jitter typically shows a stable service account, stable key material, predictable job names in logs, and correlated failures after infrastructure changes such as DNS CNAME flips or bastion routing updates. Mixing both signals into a single counter produces brittle policy: loosening to help CI opens the door to scanners, while tightening to block scanners breaks legitimate bursts.
A practical control-plane split has three layers: network reachability, transport and host identity, and authentication plus sessions. This article focuses on the boundary between host identity and authentication. After StrictHostKeyChecking and known_hosts are correct, MaxAuthTries and LoginGraceTime reduce CPU and log noise while still giving CI a finite failure budget that operators can reason about. If you use a bastion, aggregate throttles at the bastion first and keep inner Mac thresholds gentler to avoid a single matrix explosion locking the entire path.
Measurable baselines
Start with simple ratios: failed authentications per IP per hour versus successful sessions. If failures dominate successes and usernames vary widely, treat the source as scanning. If failures spike for one deploy key fingerprint, prioritize host key verification and secret rotation rather than firewall bans. Model theoretical peaks by multiplying per-job retries with matrix width and dividing by wall-clock seconds to see whether you approach MaxAuthTries semantics on OpenSSH builds used by your remote Mac.
Measure LoginGraceTime against RTT samples from your primary office networks and from the cloud regions where runners originate. Use P95, not best-case LAN numbers. Correlate ban events with release windows: spikes on release day often indicate credential drift rather than coordinated attacks. Separately bucket SHA256 verification retries from authentication failures so you do not whitelist attackers when artifact checks fail repeatedly.
Cloud provider security groups can rate-limit SYN floods before they touch sshd, but they cannot understand application-level authentication semantics. Combine perimeter controls with sshd knobs so that legitimate CI bursts survive while scanners pay a higher cost per attempt. Document which team owns each layer to avoid midnight ping-pong between security and build engineering.
On macOS, Fail2ban is not a first-class subsystem like on many Linux distributions. Teams that install it anyway must align log paths with Apple's logging subsystem and accept upgrade risk across macOS versions. Often a better first step is disabling password authentication entirely, enforcing ed25519 keys, tightening MaxAuthTries for Match users, and moving interactive access behind mesh VPN or Tailscale-style private networks when architecture allows.
Decision matrix: limits, grace time, outer bans, and CI allow lists
| Control | Best for | Benefit | Risk |
|---|---|---|---|
| Raise MaxAuthTries only | Emergency while fixing keys | Fast relief | Wider window if passwords linger |
| Tight MaxAuthTries + keys only | Public ingress | Stops password guessing | Miskeys fail faster; add workflow backoff |
| Shorter LoginGraceTime | Half-open abuse | Less CPU drag | High RTT users may disconnect |
| Cloud firewall rate limits | Scanning storms | Absorbs noise before sshd | Bad thresholds hit CI bursts |
| Fail2ban-style bans | Linux with stable logs | Automated response | Shared NAT false positives |
| Mesh or private ingress | Architecture flexibility | Shrinks exposed surface | Routing and ACL work |
Ask three questions before picking one knob: is password auth still enabled anywhere? Does CI share NAT? Is the bastion a single point? If any answer is yes, combine controls instead of relying on a single parameter.
Executable sshd sketch and workflow backoff
# Example sshd_config fragments (adapt per OS)
# PasswordAuthentication no
# KbdInteractiveAuthentication no
# MaxAuthTries 4
# LoginGraceTime 45
# ClientAliveInterval 30
# ClientAliveCountMax 4
# Match User ci-upload
# MaxAuthTries 6
# ForceCommand internal-sftp -d /Volumes/artifacts
# GitHub Actions: add exponential sleep between retries after auth failures
Compliance, developer experience, and testing
Operationalize the policy in six concrete moves. First, split Match blocks for human accounts versus CI upload accounts so machine-friendly budgets do not relax security for everyone. Second, when using internal-sftp with ForceCommand, verify chroot ownership and permissions because permission denials are often misread as authentication failures in noisy logs. Third, align MaxSessions with CI concurrency budgets so parallel uploads do not contend for the same narrow connection pool. Fourth, enforce StrictHostKeyChecking=yes with a dedicated UserKnownHostsFile fragment checked into secrets management to prevent host-key rotation from creating retry storms that look like attacks. Fifth, during large key rotations, freeze aggressive bans temporarily, raise outer thresholds, and require two-person review for firewall changes. Sixth, rehearse an incident in a staging remote Mac: deliberately use a wrong key, observe counters and logs, restore the correct key, and confirm recovery within ten minutes without ad-hoc whitelisting.
When you operate a remote Mac as a build artifact sink, compliance reviewers will ask for evidence chains. Pair session logs with artifact integrity checks so that a spike in SFTP failures can be tied to a specific workflow version. Export minimal telemetry to your SIEM without leaking private keys: counts, fingerprints of deploy keys, ban decisions, and correlation IDs for releases.
Developer experience still matters. If every minor host key rotation becomes a CI outage, teams will pressure you to disable StrictHostKeyChecking, which is worse than temporarily raising MaxAuthTries during a controlled rotation window. Prefer staged rotation with dual host key acceptance windows documented in the same ticket as sshd changes.
Testing should include negative paths. Simulate slowloris-style behavior in a lab, observe CPU and connection tables, and validate that LoginGraceTime changes produce expected disconnects without harming long-lived sftp sessions that upload large artifacts. Validate keepalive settings so middleboxes do not silently drop idle control channels while data channels still appear healthy.
Strong CTA and reading order
Read known_hosts pinning for Actions, then OIDC and deploy keys, then concurrent SFTP sessions, then ProxyJump bastions, optionally mesh ingress, and the homepage for hosted capacity.
FAQ, checklist, and why SFTPMAC
Read in this order: this article, then the known_hosts pinning guide for GitHub Actions, then OIDC and least-privilege upload accounts, then concurrent SFTP sessions and keepalive tuning, then bastion ProxyJump matrices, then the homepage for hosted remote Mac capacity. Pulling authentication limits into the same change ticket as topology and concurrency prevents the classic failure mode where security tightens sshd while CI widens parallelism without coordination.
FAQ: Is moving to a high port enough? No. Scanners enumerate ports. Combine keys-only authentication, sane MaxAuthTries, optional outer rate limits, and preferably private ingress. FAQ: Does MaxAuthTries interact with PAM? Behavior varies across distributions and Apple OpenSSH builds; always validate with controlled accounts after changes. FAQ: How does this relate to host keys? Host keys answer which machine you reached; MaxAuthTries limits how many authentication attempts occur in one connection. You need both.
In summary, public SFTP entry points in 2026 should document MaxAuthTries, LoginGraceTime, keys-only authentication, host identity checks, and session budgets on the same runbook page, then use outer rate limits and topology to absorb scanning storms. The limitation of self-managed remote Mac fleets is that you must continuously patch systems, maintain logs, maintain egress understanding for CI, and rehearse rotations. If your team prefers a managed Apple-native build and delivery surface with operational guardrails for SFTP and rsync, SFTPMAC hosted remote Mac reduces the hidden cost of balancing anti-scan controls against CI stability.
Additional nuance for multi-region teams: schedule CI retries with jitter so that simultaneous region failovers do not align into a single authentication spike. If you use self-hosted runners with static egress, document those IPs separately from GitHub-hosted pools so ban thresholds can differ. Where possible, dedicate upload accounts per environment so production keys never appear in staging workflows.
Finally, revisit assumptions quarterly. Cloud providers change NAT behavior, GitHub adjusts runner images, and Apple ships OpenSSH updates. A parameter set that was safe in January may be brittle in April. Keep a changelog entry whenever sshd, security groups, or workflow concurrency defaults move, and link that entry to postmortems when incidents occur.
Vendor hardening checklists often recommend aggressive MaxAuthTries defaults without mentioning that internal-sftp-only accounts may require slightly higher budgets when clients reconnect after VPN flaps. Document the rationale next to each number so future maintainers do not copy-paste smaller values from unrelated Linux web servers. When you onboard a new mobile team that uploads large ProRes proxies, revisit LoginGraceTime because their first-time host key prompts may be slower than backend engineers expect.
Automation can help but can also amplify mistakes. If a workflow uses a composite action that wraps ssh options, ensure every consumer inherits the same UserKnownHostsFile path and the same StrictHostKeyChecking mode. Silent drift between repositories is a common source of authentication storms that MaxAuthTries cannot distinguish from attacks. Centralize the ssh fragment as an artifact versioned alongside infrastructure-as-code for the bastion.
Observability hooks should include a counter for disconnect reasons if your logging pipeline can parse them. Sudden growth in disconnect reason related to grace time suggests tuning issues, while growth in pre-auth banner errors may indicate scanners or broken clients. Pair those signals with TCP retransmit metrics on the path to distinguish network brownouts from authentication policy effects.
Legal and procurement teams sometimes ask whether blocking countries at the firewall conflicts with employee travel. Operational clarity: separate employee VPN paths from CI egress paths so policy debates do not force globally permissive sshd settings. Where travel requires ad-hoc access, use short-lived certificates instead of permanently widening MaxAuthTries for all users.
When you evaluate hosted versus self-built remote Mac fleets, include on-call hours spent chasing false-positive bans and hours spent tuning sshd across macOS upgrades. A managed surface that already encodes best practices for SFTP delivery can shorten time-to-green for new repositories while preserving the same conceptual model of keys, sessions, and integrity checks you would have built yourself.
Print this checklist on one page for on-call: passwords disabled, Match users verified, MaxAuthTries per role, LoginGraceTime justified by RTT, MaxSessions aligned with CI, known_hosts pinned, outer bans labeled with owner team, and a rehearsed rollback path that does not require disabling host key checks under pressure.
Treat MaxAuthTries as a budget shared across humans and automation, not a magic constant; recompute it whenever matrix width, retry policy, or bastion depth changes, and attach the computation to the same pull request that edits sshd_config so reviewers see the arithmetic.