10 days ago
Hello Railway team,
I need an authoritative way to verify the SSH host identity for:
ssh.railway.com:22
Our security policy requires StrictHostKeyChecking=yes and does not allow
trust-on-first-use, accept-new, StrictHostKeyChecking=no, or treating
ssh-keyscan output as an independent trust anchor.
We are using Railway CLI 5.37.4.
An existing ED25519 key for ssh.railway.com in our known_hosts has fingerprint:
SHA256:+S1xg92FrnHz6pY3bpkmh1OGtWQGNANXilPzlxA7B1g
A later Railway SSH connection presented a different ED25519 fingerprint:
SHA256:qhtrKqXZVXUQ56ZfVpSJZy+qbKKhSSL//eiGTq8DWiA
OpenSSH therefore correctly stopped with:
"Host key for ssh.railway.com has changed and you have requested strict
checking. Host key verification failed."
We did NOT bypass verification and have NOT trusted the newly observed key.
Could Railway please confirm:
-
What are the currently valid SSH host-key fingerprints for
ssh.railway.com?
-
Does ssh.railway.com use multiple gateways/backends that intentionally
present different host keys?
-
If multiple host keys are valid, is there a complete stable list that
should be pinned in known_hosts?
-
Are the keys global or can they vary by region, edge, project,
environment, service, or deployment?
-
Is there an official Railway-controlled HTTPS endpoint, documentation
page, API, DNS SSHFP record, or other authenticated channel where these
fingerprints can be verified out-of-band?
-
What is Railway's recommended procedure for environments that require
StrictHostKeyChecking=yes?
We specifically need an out-of-band Railway-authoritative source for the
expected fingerprint(s). Observing the key directly from ssh.railway.com is
not sufficient for our security requirement.
Thank you.
1 Replies
10 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 10 days ago
9 days ago
Hi @quiquekas82-glitch,
The behavior you are observing with ssh.railway.com is due to Railway's underlying architecture: ssh.railway.com routes traffic through a distributed load-balanced edge proxy cluster. Because individual SSH gateway proxies are ephemeral and auto-scaled across regions, different edge nodes terminate the SSH handshake with their own node-specific host keys.
Here are direct answers to your 6 questions and the recommended approach for strict compliance environments:
1 & 2. Multiple Gateways & Host Key Variations
Yes, ssh.railway.com uses multiple backend SSH proxies behind load balancers / Anycast IPs. Each proxy instance generates/presents its own SSH host key, which is why you see different fingerprints (e.g., SHA256:+S1x... vs SHA256:qhtr...) depending on which edge node receives your connection.
3 & 4. Host Key Scope & Pinning
Host keys vary by edge proxy instance, not per-project or per-deployment. Because Railway's edge nodes scale dynamically, there is currently no official static or pinned list of all host key fingerprints available for known_hosts.
5. Out-of-Band Verification & SSHFP
Railway does not currently publish DNS SSHFP records or maintain an official authenticated REST/GraphQL endpoint to verify SSH host key fingerprints out-of-band.
🛡️ Recommended Workarounds for StrictHostKeyChecking=yes Environments
If your security policy strictly forbids StrictHostKeyChecking=no or Accept-New globally, here are the standard patterns to handle this compliance requirement:
Option A: Scoped SSH Config (Recommended)
Isolate Railway's dynamic SSH proxies in your ~/.ssh/config so your global StrictHostKeyChecking=yes policy remains intact for all other production servers, while allowing Railway's SSH proxy pool to connect seamlessly:
Host ssh.railway.com
StrictHostKeyChecking accept-new
UserKnownHostsFile ~/.ssh/railway_known_hosts