2 months ago
Hello Railway Support,
We use the official Railway CLI v5.30.1 on macOS. A dedicated personal Ed25519 public key is already registered successfully with the Railway account.
A later authorized, non-interactive Railway SSH command stopped during SSH host verification, before any remote command or authenticated request was executed. The Mac had no existing known_hosts entry for ssh.railway.com.
Our security policy does not permit trust-on-first-use, StrictHostKeyChecking=no, StrictHostKeyChecking=accept-new, or trusting unverified ssh-keyscan output.
Please provide Railway’s authoritative mechanism for verifying ssh.railway.com, including:
- The complete current SSH host-key fingerprints for every Railway SSH gateway or edge node that may answer for this hostname.
- Whether Railway supports an SSH host certificate or provider-published CA key that clients can trust instead of individual rotating host keys.
- Railway’s host-key rotation procedure and the official channel where changes are announced.
- The recommended secure known_hosts configuration when multiple valid Railway gateways can present different keys.
- Whether the Railway CLI plans to provide provider-verified host-key management.
We will keep Railway SSH disabled until an authoritative verification method is available.
Thank you.
1 Replies
2 months ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 2 months ago
14 days ago
I looked into this because there have been a couple of very similar Railway threads recently.
From Railway's own previous responses, I don't think there is currently an authoritative pinning mechanism that satisfies the policy you're describing.
Railway staff have confirmed that ssh.railway.com can present one of multiple valid host keys, that individual keys can change, and that Railway doesn't guarantee the lifetime of a specific key or publish a complete list of the currently valid fingerprints.
Railway has also previously stated that they don't currently publish SSHFP records or a documented host-key rotation policy for ssh.railway.com.
So as far as I can tell, the answers to your questions are basically:
- There isn't a Railway-published complete/current fingerprint list you can safely pin.
- I couldn't find a Railway-published SSH host CA/certificate trust anchor either.
- There isn't a documented public rotation procedure/channel for these keys.
- Because of that, there isn't really a
known_hostssetup that gives you strict out-of-band verification without using TOFU/accept-new. - The current Railway CLI uses the system OpenSSH client for
ssh.railway.com; I couldn't find any provider-verified host-key management in the current CLI/docs.
One recent Railway employee response was also pretty explicit that they don't plan to manually validate individual fingerprints each time they rotate.
So with a policy that forbids TOFU, accept-new, ssh-keyscan as the trust source, etc., I don't think Railway SSH currently meets that requirement.
I'd keep SSH disabled under that policy rather than weaken host verification.