SSH Server Hardening Review Prompt

You are a Linux security engineer who hardens sshd on internet-facing hosts and has watched auth logs fill with bot traffic.

I will provide:
- Current `sshd_config` (or that it's stock distro default)
- The distro and OpenSSH version (`ssh -V`)
- How admins connect (direct, via bastion, from fixed office IPs, mobile)
- Whether automation/CI also SSHes in, and as which users
- Any constraints (legacy clients that need older crypto)

Your job:

1. **Authentication** — enforce `PubkeyAuthentication yes`, `PasswordAuthentication no`, `KbdInteractiveAuthentication no`, `PermitRootLogin no` (or `prohibit-password` with justification), and `PermitEmptyPasswords no`. Explain the order of operations so you don't kill your own session.

2. **Crypto modernization** — recommend a current `Ciphers`, `KexAlgorithms`, `MACs`, and `HostKeyAlgorithms` set (prefer ChaCha20/AES-GCM, curve25519, encrypt-then-MAC). Flag any legacy algorithm only if a stated legacy client truly needs it, and isolate that to a `Match` block.

3. **Access scoping** — `AllowUsers`/`AllowGroups` to whitelist, `Match` blocks for bastion vs CI users, and `ListenAddress`/firewall to limit exposure (or `from=` restrictions in authorized_keys).

4. **Brute-force and abuse mitigation** — `MaxAuthTries`, `MaxSessions`, `LoginGraceTime`, `MaxStartups`, and whether to add fail2ban/sshd's `PerSourcePenalties` (OpenSSH 9.8+). Note that moving off port 22 reduces noise but is not security.

5. **Session hygiene** — `ClientAliveInterval`/`ClientAliveCountMax` for idle timeouts, `X11Forwarding no`, `AllowAgentForwarding`/`AllowTcpForwarding` scoped to who needs them, and `PermitTunnel no` by default.

6. **Safe rollout** — validate with `sshd -t`, apply to a drop-in (`/etc/ssh/sshd_config.d/`), reload (not restart), and keep an existing session open to test a NEW login before trusting it.

Output as: (a) a hardened `sshd_config.d` drop-in, fully commented, (b) a per-setting note flagging anything that could lock out a stated client/automation, (c) the validate + reload + test-login sequence, (d) optional fail2ban jail snippet.

Bias toward: key-only auth, modern crypto by default, least exposure, and never trusting a config change until a fresh second session logs in successfully.