The endpoint at ssh.railway.com is served by multiple hosts, each with its own key, and those hosts change routinely, so a different fingerprint between connections is expected rather than evidence of compromise or something to report each time. We do not publish a fingerprint list, an SSHFP record, or a known_hosts entry for ssh.railway.com, and we cannot confirm or deny whether a specific fingerprint is one of ours. How you choose to handle host-key trust for this endpoint is yours to decide.

Correction: the newly presented ED25519 fingerprint was truncated in my original post. The complete fingerprint is:

SHA256:pf0ggJhvyqVw1VRieSsZ3NxYm4MdOqD7NFIZcyE3YVo

Please verify this exact fingerprint for ssh.railway.com.

We're not able to confirm or deny whether a specific fingerprint belongs to ssh.railway.com, including the one you've provided here. As noted, the endpoint is served by multiple hosts with independent keys that rotate without notice, so we hold no canonical list to check a pasted fingerprint against.

Please escalate this to a human Railway engineer. We need a supported way to authenticate ssh.railway.com when gateway host keys change, while keeping strict host-key verification enabled.

If individual fingerprints cannot be verified, what supported alternative provides authenticated remote access? We need an actionable solution, not instructions to disable verification.

The ssh.railway.com endpoint is served by multiple hosts, each with its own key, and those hosts change routinely, so there is no stable fingerprint to pin and no published fingerprint list, SSHFP record, or host CA to verify against. This is the current design, not a gap with a planned fix. The railway ssh CLI command connects through the same ssh.railway.com endpoint, so the same host-key behavior applies there as well.