SSH Jump Servers, explained

What problem does a jump server solve?

In a perfect world, every server would be locked down, never exposed directly to the public internet, and still easy for developers and automation systems to access. In reality, those goals often conflict.

A SSH jump server (sometimes called a bastion host) acts as a single, controlled entry point into your private infrastructure. Instead of exposing every VPS to the internet, you expose one hardened gateway.

How jump servers work (without the buzzwords)

Conceptually, it looks like this:

Your laptop → Jump Server → Your VPS

Your VPS does not accept SSH connections from the public internet. It only accepts connections from the jump server (typically over a private backend network).

This dramatically reduces the attack surface while keeping access flexible.

Using a jump server from the command line

Modern OpenSSH supports jump servers natively using the -J flag or your SSH config file.

ssh -J user@jump.arcustech.com user@yourvpsname

Or in ~/.ssh/config:

Host yourvpsname
  HostName 10.0.0.10
  User deploy
  ProxyJump user@jump.arcustech.com

Tip: yourvpsname can match the VPS name you use in the Arcustech Dashboard. It is just an SSH alias on your computer.

Once configured, connecting feels exactly like a normal SSH session. You can also layer on normal SSH habits, like restricting allowed keys, limiting users, and keeping logs.

Termius: SSH and SFTP without fighting your config

Tools like Termius can make jump servers easier to manage, especially if you have multiple environments or you are sharing access within a team.

• Visual host organization (staging vs production, client A vs client B)
• SSH key management and per-host identity selection
• Built-in jump host support
• SFTP access through the same gateway

The best part is that it reduces the “where is that SSH config again?” problem without changing the underlying security model.

Database access with tools like TablePlus

GUI database tools such as TablePlus work well with SSH jump servers, but the setup is slightly more explicit than some other tools.

TablePlus relies on a standard ~/.ssh/config file to define jump hosts and proxy behavior. Once the SSH path is defined there, TablePlus connects through that tunnel instead of managing the jump logic internally.

In practice, this means:

• You define the jump server and internal host relationship in ~/.ssh/config
• TablePlus is configured to use the matching SSH host entry
• No database ports need to be exposed publicly

Because TablePlus’ UI and SSH handling can change over time, we keep the step-by-step walkthrough in our Knowledge Base.

View TablePlus + SSH Jump Server setup guide

GitHub Actions and CI/CD pipelines

Jump servers also work well with CI/CD systems like GitHub Actions. The pattern is simple: the workflow connects to your jump server, and from there reaches internal hosts that are not exposed publicly.

The most common approach on GitHub-hosted runners is to load a deploy key into an SSH agent, then use OpenSSH’s built-in ProxyJump support to route through the jump server.

At a high level, your workflow usually does three things:

1. Add the private key (stored in GitHub Secrets) to an SSH agent on the runner.
2. Write a minimal ~/.ssh/config that defines your jump host and internal target via ProxyJump.
3. Run your deploy command over SSH (rsync, git pull, deploy script, etc.) against the internal host name.

Tip: use a dedicated deploy key with least-privilege access, and keep production access separate from human developer keys. If you already deploy with Ploi or Forge, you may still find a jump server useful for controlled human access and database tooling.

Where Arcustech fits in

Arcustech SSH Jump Servers provide the secure gateway. How you authenticate, deploy, and manage access remains under your control.

This aligns with how we build our platform: clear responsibility boundaries and predictable infrastructure behavior.

Learn more about our SSH Jump Server add-on.

Back to Articles