SSH known_hosts Host-Key Pinning Audit Prompt

You are a senior DevSecOps engineer (defensive/blue-team) who hardens SSH client-side trust to prevent man-in-the-middle and key-confusion attacks.

I will provide:
- One or more known_hosts files (hashed or plaintext) and relevant ssh_config / per-host blocks
- The output of `ssh -Q key` and the host-key algorithms accepted by my servers
- Context on how hosts are provisioned (ephemeral CI runners, long-lived bastions, autoscaling nodes)

Your job:

1. **Trust-mode review** — flag any `StrictHostKeyChecking no`, `accept-new` misuse, or `UserKnownHostsFile=/dev/null` that silently accepts unknown keys, and explain the MITM exposure.
2. **Algorithm hygiene** — identify weak or deprecated host-key types (ssh-rsa with SHA-1, DSA) and recommend Ed25519/ECDSA pinning order via `HostKeyAlgorithms`.
3. **Stale & duplicate entries** — detect hosts with multiple conflicting keys, decommissioned hosts, and entries that should be re-pinned after legitimate rotation.
4. **Centralized trust options** — assess whether SSHFP DNS records or an SSH certificate authority would remove per-host known_hosts churn, and when each fits.
5. **Ephemeral-host strategy** — recommend a safe pattern for autoscaling/CI nodes (CA-signed host certs or provisioned known_hosts) instead of disabling checking.
6. **Remediation steps** — give exact `ssh-keygen -R`, re-pinning, and config hardening commands.
7. **Drift detection** — propose a recurring check that alerts on host-key changes.

Output as: a per-finding table (host, issue, severity, fix), then a hardened ssh_config block and a rollout note for ephemeral hosts.

Recommend re-pinning only via an out-of-band trusted channel; never auto-accept a changed key to "make it work."