Elglide
Book a demo

SSH bastion setup

Elglide connects to your source database by dialing outbound to your SSH bastion — a jump host you already control. We never accept inbound traffic; every session is initiated by us, closes when the extract finishes, and is scoped so it can reach only the one database host and port you allow. This is the lighter-weight alternative to a full Hybrid Agent: no software runs on your network, but rows do transit Elglide's cloud in flight.

Prefer not to run a bastion? Direct connection — IP allowlist is simpler if your database is already reachable from the internet. Need source data to never leave your network at all? See Hybrid Agent.

Architecture

One trust boundary: your firewall. Our connector dials outbound to your bastion; the bastion forwards that single connection to your source database. Unlike Hybrid Agent, the data itself crosses into Elglide's cloud over this tunnel — only the credentials and forwarding scope stay locked down.

Elglide SSH bastion architecture Elglide cloud on the left with the connector; your network on the right behind your firewall, containing the SSH bastion and source database. The connector dials outbound SSH to the bastion (dashed), which forwards the connection to the database (solid); extracted rows flow back to Elglide over the same tunnel — unlike Hybrid Agent mode, data does cross into Elglide's cloud. SSH bastion — Elglide dials outbound into your network Elglide cloud Your network 🔒 firewall inbound: SSH, our IPs only Connectoroutbound SSH dialer SSH bastionkey-only · permitlisten-scoped Source databasereachable only from the bastion 1. outbound SSH — per-extract session 2. forwarded via permitlisten rows return over the same tunnel SSH tunnel — closed after each extract database rows — do cross into Elglide's cloud
The connector opens a fresh outbound SSH session per extract; the bastion forwards it to your database and closes it when the run finishes.

When to use it

  • You already run a bastion/jump host, or your security policy requires all inbound access to funnel through one hardened entry point.
  • You're fine with source rows transiting Elglide's cloud in flight — if not, see Hybrid Agent, where data never leaves your network.
  • You don't want to run always-on Elglide software inside your network — a bastion is just an SSH endpoint, nothing to install or update on our side.

Setup

1. Bastion sizing

A small VM is fine — 1 vCPU, 1 GB RAM, your distro of choice. Each extract opens one SSH session and closes it on completion. We never keep persistent tunnels.

2. Allow inbound SSH from us

Allow inbound TCP 22 (or whatever non-default port you've chosen for SSH) from our static egress IPs. That's the only inbound rule we need.

3. Generate the keypair (in our portal)

From Account → SSH Tunnels (sign-in required) click + New SSH tunnel. Fill in the bastion host, port, username, and key type (Ed25519 is preferred — modern, smaller, faster; pick RSA-4096 only if your bastion is older and rejects Ed25519). We generate the keypair on save and show you the public key.

4. Create the user & install the key by platform

Pick your bastion's OS. In every case: a dedicated, password-disabled user; a forced command that blocks interactive shells; and permitlisten scoping the key to your database's host:port only. Replace <your-public-key> with the key from step 3 and DB_HOST:DB_PORT with your source database's address as seen from the bastion.

Any distro works — this uses OpenSSH's built-in authorized_keys, no extra software.

  1. Create the user (no password, no sudo): 
    sudo useradd -m -s /bin/bash elglide
sudo passwd -l elglide          # disable password login; key auth only
sudo mkdir -p /home/elglide/.ssh
sudo chmod 700 /home/elglide/.ssh
sudo touch /home/elglide/.ssh/authorized_keys
sudo chmod 600 /home/elglide/.ssh/authorized_keys
sudo chown -R elglide:elglide /home/elglide/.ssh
  2. Install the key with the hardening directives: 
    echo 'command="echo not allowed",no-pty,no-X11-forwarding,no-agent-forwarding,no-user-rc,permitlisten="DB_HOST:DB_PORT" <your-public-key>' | sudo tee -a /home/elglide/.ssh/authorized_keys
command="echo not allowed" + no-pty block an interactive shell entirely. permitlisten restricts us to forwarding to that one host:port — we can't pivot to anything else on your network with this key.

macOS's built-in Remote Login (OpenSSH) works the same as Linux, using dscl instead of useradd.

  1. Enable Remote Login and create the user: 
    sudo systemsetup -setremotelogin on
sudo dscl . -create /Users/elglide
sudo dscl . -create /Users/elglide UserShell /usr/bin/false
sudo dscl . -create /Users/elglide NFSHomeDirectory /Users/elglide
sudo mkdir -p /Users/elglide/.ssh
sudo chmod 700 /Users/elglide/.ssh
  2. Install the key: 
    echo 'command="echo not allowed",no-pty,no-X11-forwarding,no-agent-forwarding,no-user-rc,permitlisten="DB_HOST:DB_PORT" <your-public-key>' | sudo tee -a /Users/elglide/.ssh/authorized_keys
sudo chmod 600 /Users/elglide/.ssh/authorized_keys
sudo chown -R elglide /Users/elglide/.ssh

Requires the optional OpenSSH Server feature.

  1. Install and start OpenSSH Server (if not already): 
    Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Start-Service sshd
Set-Service -Name sshd -StartupType Automatic
  2. Install the key. Where it goes depends on the bastion user's group:
  • If your bastion user is in the Administrators group, sshd typically reads C:\ProgramData\ssh\administrators_authorized_keys. This file is writable from any elevated PowerShell — no extra steps. Recommended: create a non-admin local user for the tunnel instead; it's safer and simpler.
  • For a non-admin user (or any user with an explicit Match User <name> block in sshd_config), sshd reads C:\Users\<name>\.ssh\authorized_keys. That file has a strict ACL: only the user themself and SYSTEM can read it. Admins cannot. Editing requires either logging in as that user, or temporarily taking ownership: 
# In an elevated PowerShell. Replace <bastion-user> with your tunnel user.
$path = "C:\Users\<bastion-user>\.ssh\authorized_keys"

# Take ownership + grant Admin write temporarily
takeown /F $path /A
icacls $path /grant Administrators:F

# Edit: remove any old elglide-tenant-<N> line, append the new key.
notepad $path

# Restore — critical. OpenSSH StrictModes rejects auth if Admins retains access.
icacls $path /setowner <bastion-user>
icacls $path /remove Administrators

# Sanity check: should return "Access is denied" from your Admin shell.
# That confirms the strict ACL is back.
icacls $path
If the last icacls check prints the ACL instead of denying access, Administrators still has access and sshd will refuse the key on the next auth attempt. Re-run the remove line.

5. Configure the source DB connection

From Connections (sign-in required) → Edit / Create. Pick SSH Tunnel in the Connectivity section and select the tunnel you just made. Click Diagnose to run the 4-step test (network → SSH → database → permissions).

6. Replacing the public key (rotation)

We rotate keys periodically (or on demand) — Account → SSH Tunnels → the rotate icon. Choose Rotate the shared key to swap one key across every Connection that uses this tunnel, or Detach a specific source to give just one Connection its own fresh keypair while the others keep their existing one.

After clicking, we show you the new public key + the install line. Until you replace the old line in authorized_keys on the bastion (or the Windows equivalent from the Windows tab in step 4), every sync that uses this tunnel will fail with Permission denied (publickey).

Every key we issue ends with a comment of the form elglide-tenant-<N>, where <N> is your tenant id (visible in the portal). That comment is how you identify which line to replace.

Replace <bastion-user> with the user you created in step 4, <your-new-public-key> with the freshly shown key, and DB_HOST:DB_PORT with your source database's internal address: 

sudo -u <bastion-user> sed -i '/elglide-tenant-<N>/d' ~<bastion-user>/.ssh/authorized_keys
echo 'command="echo not allowed",no-pty,no-X11-forwarding,no-agent-forwarding,no-user-rc,permitlisten="DB_HOST:DB_PORT" <your-new-public-key>' | sudo -u <bastion-user> tee -a ~<bastion-user>/.ssh/authorized_keys
sudo -u <bastion-user> chmod 600 ~<bastion-user>/.ssh/authorized_keys

Then re-run the Diagnose modal on the Connection — the SSH step should turn green within seconds. No bastion restart needed; sshd re-reads authorized_keys on every connection.

Troubleshooting

Diagnose step shows… Most likely cause Fix
✗ Network reachability — TCP refused Inbound firewall blocks our IPs Allow our static IPs on the bastion's SSH port
✗ Network reachability — timeout Wrong bastion hostname or no public DNS Use the bastion's public IP or a resolvable DNS name
✗ SSH tunnel — Permission denied (publickey) Public key not installed, wrong username, or authorized_keys file permissions wrong Verify the user exists, the public key matches, and file perms are 600 (the dir 700)
✗ SSH tunnel — open failed: permitlisten permitlisten doesn't include the DB host:port Update authorized_keys to add the right DB_HOST:DB_PORT
✗ Database access — login failed DB credentials are wrong (everything before this passed, so the bastion is fine) Update the username/password on the Connection
✗ Permissions check — SELECT denied The DB user can connect but lacks SELECT on INFORMATION_SCHEMA / information_schema Grant SELECT on the metadata views (or use a role with schema-discovery privileges)
✗ SSH tunnel — Permission denied (publickey) after a rotation Old elglide-tenant-<N> line still in authorized_keys; sshd is matching the old key, not the new one Delete the old line; keep only the freshly-shown one. Step 6 above.
✗ SSH tunnel — Permission denied (publickey) on a Windows bastion Wrong authorized_keys file edited (per-user vs admin), OR icacls never revoked Administrators access after takeown Confirm which file your sshd reads (see the Windows tab in step 4), and verify the final ACL is "denied" to Administrators

Still stuck? Open the failed step in the Diagnose modal and click Show details — the technical detail there includes the exact driver error, which is what to share when filing a support ticket.