3 hours ago
I need provider-authenticated verification of ssh.railway.com before my first Railway SSH connection. My client public key is already registered. The connection stops with "Host key verification failed" because I have not trusted a server host key yet.
Could a Railway support engineer please confirm the current product/security policy and provide:
- Current SHA256 SSH host-key fingerprints and key types (including all legitimate endpoint keys), with an official HTTPS publication or authenticated Railway source; public host-key / known_hosts entries would also help.
- Whether a host CA, signed host certificates, or an authenticated per-target host-key API is available, and the supported key rotation procedure.
I found this similar thread, whose responses are labelled Railway BOT:
https://station.railway.com/questions/need-official-ssh-railway-com-host-key-f-eed9db98
It says no independently authenticated host keys are published. Please have Railway staff confirm whether that statement is accurate today. If provider-authenticated SSH verification is unavailable, please clearly confirm that limitation and point to the supported alternative for a one-off PostgreSQL maintenance command inside the project private network, without public database exposure or weakening certificate verification.
I reviewed the official SSH documentation. I am seeking independent server identity verification rather than unauthenticated ssh-keyscan output or trust-on-first-use. No account-specific investigation is required, and no project identifiers, credentials, or logs are attached. Thank you.
2 Replies
3 hours ago
That's still accurate. We don't publish host-key fingerprints, known_hosts entries, an SSHFP record, a host CA, signed host certificates, or a per-target host-key API for ssh.railway.com, and there is no rotation procedure. The endpoint is served by multiple hosts, each with its own key, and those hosts change without notice. That means the endpoint can present different keys, and you decide how to handle host-key trust for it. Note that railway connect also tunnels over SSH when a database has no public TCP Proxy, so it doesn't avoid this.
For a one-off PostgreSQL maintenance command that never uses SSH, use a pre-deploy command on a service in the project. It runs inside your private network, has access to the service's variables (so it can use the private DATABASE_URL instead of a public URL), and runs between build and deploy. It must exit 0 on success, and the client it needs has to be installed in that service's image. A non-zero exit stops the deployment and is not retried. You can set a Pre-deploy Timeout so a hung command fails instead of holding the deployment. To keep it one-off, remove the command once it has run.
Status changed to Awaiting User Response Railway • about 3 hours ago
Railway
That's still accurate. We don't publish host-key fingerprints, known_hosts entries, an SSHFP record, a host CA, signed host certificates, or a per-target host-key API for `ssh.railway.com`, and there is no rotation procedure. The endpoint is served by multiple hosts, each with its own key, and those hosts change without notice. That means the endpoint can present different keys, and you decide how to handle host-key trust for it. Note that `railway connect` also tunnels over SSH when a database has no public TCP Proxy, so it doesn't avoid this. For a one-off PostgreSQL maintenance command that never uses SSH, use a [pre-deploy command](https://docs.railway.com/deployments/pre-deploy-command) on a service in the project. It runs inside your private network, has access to the service's variables (so it can use the private `DATABASE_URL` instead of a public URL), and runs between build and deploy. It must exit 0 on success, and the client it needs has to be installed in that service's image. A non-zero exit stops the deployment and is not retried. You can set a Pre-deploy Timeout so a hung command fails instead of holding the deployment. To keep it one-off, remove the command once it has run.
3 hours ago
Thank you. I still need confirmation from a Railway support engineer; the automated answer does not provide provider-authenticated server identity evidence. Could Railway staff please confirm this current limitation and point to official documentation for the supported private-network maintenance alternative? No account-specific investigation or credentials are needed. We will keep SSH access on hold while this is unresolved.
Status changed to Awaiting Railway Response Railway • about 3 hours ago