Skip to main content
If your database only accepts connections from inside your network, Ordyn can reach it through a bastion host (a jump server) over SSH. Ordyn logs into the bastion and forwards its database connection through it. The bastion connects to the database from inside your network, so the database itself stays private. Tunnels work with PostgreSQL and PlanetScale Postgres. PlanetScale’s Vitess (MySQL) engine can’t use a tunnel.

Permissions

For EC2 Instance Connect, the AWS role Ordyn assumes needs ec2-instance-connect:SendSSHPublicKey on the bastion instance, plus ec2-instance-connect:OpenTunnel on the endpoint when it sits behind an EC2 Instance Connect Endpoint.

EC2 Instance Connect

Push a one-time SSH key to the bastion and open a tunnel through an EC2 Instance Connect Endpoint, so no SSH key is stored.
  • Ordyn shows a policy scoped to your instance, OS user, endpoint and port when you set up the tunnel.
Permission catalog version 2026-10-16.1. See permission changes.

Choose how Ordyn reaches the bastion

Turn on SSH tunnel in the connection form, then pick an option under Connect via: Either way, the bastion’s SSH server must allow TCP forwarding (AllowTcpForwarding yes, the default in OpenSSH).

Choose how Ordyn logs in

EC2 Instance Connect is the usual choice for EC2 bastions: there is no password to rotate, and your AWS role decides exactly which instance and user Ordyn can log in as.

Set up a public bastion

1

Fill in the tunnel

Enter the SSH host, port, and username, and choose the login.
2

With EC2 Instance Connect: grant the role

Enter the bastion’s instance ID and region, and pick the AWS connection whose role Ordyn should use. The form shows an AWS CloudShell command to run once. It adds this inline policy to that role, letting it push keys to this instance only, as this user:
3

Test and trust the host key

Click Test Connection, check the bastion’s host key, and click Trust and test. See Host key check.

Set up a bastion behind an EC2 Instance Connect Endpoint

1

Fill in the tunnel

Under Connect via, choose EC2 Instance Connect Endpoint. Enter the endpoint ID (eice-...), the bastion’s instance ID and region, the SSH port and username, and pick the AWS connection whose role Ordyn should use. There is no host to enter: Ordyn looks up the endpoint and the bastion’s private IP address with that role.
2

Grant the role

The form shows an AWS CloudShell command to run once. It lets the role open tunnels through this endpoint to the bastion’s SSH port, for at most an hour each, and look up the endpoint and the bastion’s private IP. With EC2 Instance Connect login, the same policy also includes the key push shown above.
The tunnel permission is limited to this endpoint and the SSH port, not to the bastion itself: the role can open that port on any address the endpoint can reach. It isn’t pinned to the bastion’s private IP because that IP can change when the instance restarts. To narrow it further, add an ec2-instance-connect:privateIpAddress condition with the bastion’s IP (and update it if the IP changes), or use a dedicated endpoint whose security group only reaches the bastion.The two lookups can’t be limited to one resource in IAM, so the role can read metadata for every instance and endpoint it can see; they never change anything.
3

Allow SSH from the endpoint

The bastion’s security group must allow SSH (port 22, or your SSH port) from the endpoint’s security group. The bastion needs no inbound rule from the internet.This assumes the endpoint’s Preserve Client IP setting is off, which is the default. With it on, the bastion sees each client’s own IP address instead, and Ordyn’s servers don’t have fixed IP addresses to allow. Use an endpoint with Preserve Client IP off for Ordyn.
4

Test and trust the host key

Click Test Connection, check the bastion’s host key, and click Trust and test. See Host key check.

Connection limits

An endpoint allows 20 connections at once, shared with your engineers. Ordyn reuses its SSH connections across queries and normally keeps at most 3 open through an endpoint at a time, across all of its servers. In rare cases, such as an outage of Ordyn’s coordination service, it can briefly open more rather than fail your queries. If all three are busy for 45 seconds, the query fails with a message saying so. Each tunnel is closed once idle and replaced before the endpoint’s one-hour limit. If you need a different limit, contact us.

Host key check

Before Ordyn sends any SSH login credential, it shows you the bastion’s SSH host key. Reading the key opens a connection (through your EC2 Instance Connect Endpoint, if you use one) without logging in to the bastion. Compare the fingerprint with the bastion’s own key. On the bastion, run:
If they match, click Trust and test. From then on, Ordyn only connects to a bastion presenting that key. If you replace or re-key the bastion, the next test tells you the key changed and shows the new fingerprint to check and trust. A trusted key belongs to one bastion: the host and port, or for an endpoint, the endpoint, instance, region, and AWS connection. Changing any of these asks you to check the key again.

Editing a connection

When you edit a connection, its tunnel settings are filled in. Leave the SSH password blank to keep the saved one. Ordyn only reuses a saved password for the same bastion, username, and login; if you point the tunnel somewhere else, enter the password again. Turn SSH tunnel off and save to remove the tunnel.

TLS through the tunnel

The database connection keeps its TLS settings through the tunnel. With PostgreSQL’s verify-full, and always for PlanetScale, Ordyn checks the certificate against the database’s real hostname, not the tunnel’s local address.

Troubleshooting

The role of the chosen AWS connection is missing the permission the message names. Run the command the form shows, then test again. IAM changes can take a few seconds to apply.
Check the endpoint ID, and that the bastion’s region is set if it differs from your AWS connection’s region. A new endpoint takes a few minutes to become ready.
Start the instance. Ordyn looks up its private IP each time, so a restart with a new IP address is fine.
For a public bastion, check that its security group and firewall allow SSH from the internet. Behind an endpoint, check that the bastion’s security group allows SSH from the endpoint’s security group, and that the endpoint’s Preserve Client IP setting is off.
The bastion presented a key other than the one you trusted. If you replaced or re-keyed it, check the new fingerprint on the bastion and trust it. Otherwise, find out why before trusting it.
Ordyn’s queries through this endpoint are using every connection it may hold. Try again shortly.