Connecting Through an SSH Bastion

Last updated August 13, 2026 · By the SaturnSQL team

An SSH bastion lets SaturnSQL reach a database that has no public endpoint at all, by routing the connection through a small SSH host inside (or peered with) your database's network. SaturnSQL never dials the database directly: it dials the bastion, and the bastion forwards the connection on.

1. Do you actually need one?

If your database already has a public endpoint, a bastion is more to maintain for no benefit: just allow SaturnSQL's static IP in your firewall or security group and connect directly. A bastion is for the other case: the database sits in a private subnet with no route to the internet, and your security team is not going to open one just for this. That is the normal, sensible setup for a data warehouse or production database, and a bastion lets SaturnSQL work with it exactly as it is.

2. Provision the bastion

The bastion needs to be able to reach the database, so it must sit in the same VPC as the database or in one peered with it (or reachable over a transit gateway/VPN — the requirement is a network path, not a specific AWS construct). A small, cheap instance is enough: it only relays a TCP connection, it does not run any queries itself.

• Inbound: 22/tcp from 100.49.19.161/32 only. Every SaturnSQL connection leaves from this one address, so there is nothing else to allow in.
• Outbound: the bastion's security group needs a rule letting it reach the database's port (5432 PostgreSQL, 3306 MySQL, 1433 SQL Server, 5439 Redshift), and the database's own security group needs an inbound rule allowing connections from the bastion.

3. Install SaturnSQL's key on the bastion

Save the connection once with Connect through an SSH bastion turned on and the bastion's host, port, and username filled in. SaturnSQL then mints a dedicated ed25519 keypair for that connection and shows you the public half under Public key for your bastion. Add it to the bastion user's authorized_keys, prefixed with restrict,port-forwarding so the key can open TCP forwards and do nothing else, even if something else about the bastion is later misconfigured:

This key is generated once per connection and reused; it is not a password you type in each time. If you ever need to replace it, that means removing the old line from authorized_keys and adding the new one, since SaturnSQL does not have any other way in.

4. Confirm the bastion's host key

SaturnSQL pins the bastion's SSH host key so a connection can't be silently redirected to a different machine later. Click Fetch host key in the connection form, then check the SHA256: fingerprint it shows against what the bastion itself reports:

Run that from a machine you trust, not from the bastion itself, and compare the ssh-ed25519 AAAA... value it prints to the one SaturnSQL fetched. If they match, save the connection and run Test Connection.

Redshift through a bastion

A bastion is the usual way to connect Redshift without ever setting the cluster to Publicly accessible. The cluster stays private the entire time; you use the same host you would use for a direct connection, ending in redshift.amazonaws.com (or redshift-serverless.amazonaws.com for Serverless) — it simply resolves to a private address now instead of a public one, and the bastion is what gets it the rest of the way. See Connecting Amazon Redshift for the port, database name, and SSL settings, which are unchanged by using a bastion.

Troubleshooting

A tunnelled connection can fail in two different places, and the error tells you which:

• SaturnSQL cannot reach your bastion. This is an SSH-level failure: the bastion host, port, or host key is wrong, the key in authorized_keys does not match, or the bastion's own security group is not allowing 100.49.19.161/32 on port 22. Test Connection will report this before it ever gets to the database.
• Your bastion cannot reach the database. SSH to the bastion succeeded, but the forwarded connection to the database times out or is refused. Check the database's own security group for an inbound rule allowing the bastion, that the bastion is actually in a VPC (or peered/routed) with a path to the database, and that you have the right port.

Still stuck? Send us the exact error text from the connection form and we will tell you which side it is coming from.