Ssh on Backend Engineering Strategy Tools

BIFROST — Raspberry Pi jump node

Fri, 05 Jun 2026 00:00:00 +0000

The homelab needed a permanent always-on entry point — something low power, always reachable, a stable first hop. A first-gen Raspberry Pi in the rack fills that role. BIFROST.

Hardware

Raspberry Pi 1 Model B running Raspbian, mounted in the rack with a 3D printed 1U mount. Draws under 2W at idle. Nothing runs on it except sshd.

How it works

ssh -p 22222 user@bifrost.mjnet.info

The chain:

bifrost.mjnet.info — Route53 CNAME pointing to router.mjnet.info
router.mjnet.info — HEIMDAL (SYS-009), kept current via DDNS
OPNsense port forward: external TCP 22222 → Pi:22
OPNsense DNS override: bifrost.mjnet.info → Pi’s internal IP

The DNS override means the same hostname resolves to the internal IP when used inside the network — no split config needed in ~/.ssh/config.

OPNsense config

Port forward (Firewall → NAT → Port Forward):

Interface: WAN
Protocol: TCP
Destination port: 22222
Redirect target: Pi internal IP, port 22

DNS override (Services → Unbound DNS → Host Overrides):

Host: bifrost
Domain: mjnet.info
IP: Pi internal IP

SSH config

Add to ~/.ssh/config on any client:

Host bifrost
 HostName bifrost.mjnet.info
 Port 22222
 User pi

Then ssh bifrost from anywhere.

If a more robust solution becomes necessary later (no open ports, survives CGNAT), the options doc covers Tailscale, Cloudflare Tunnel, and WireGuard.

Bastion / jump server

Fri, 22 May 2026 00:00:00 +0000

A bastion host (jump server) is a single, hardened machine exposed to the outside that acts as the entry point into a private network. You SSH into the bastion, then hop from there to internal hosts — or configure your SSH client to do it transparently in one step.

The pattern is simple: minimise the network attack surface to one well-monitored machine, harden that machine specifically, and keep everything else off the public internet.

Basic jump: manual two-hop

# Step 1: SSH into the bastion
ssh user@bastion.example.com

# Step 2: from bastion, SSH into internal host
ssh user@192.168.1.100

Works, but requires your private key to be on the bastion — which you want to avoid.

ProxyJump (recommended)

ProxyJump tells SSH to tunnel through the bastion transparently. Your key never leaves your local machine.

# One-liner
ssh -J user@bastion.example.com user@192.168.1.100

# Or in ~/.ssh/config
Host internal
 HostName 192.168.1.100
 User user
 ProxyJump bastion

Host bastion
 HostName bastion.example.com
 User user
 IdentityFile ~/.ssh/id_ed25519

After this, ssh internal works as a single command with no key on the bastion.

Agent forwarding vs ProxyJump

Agent forwarding (-A, ForwardAgent yes) forwards your SSH agent socket through the bastion so you can authenticate onward with your local key. Older approach — it works but the agent socket is briefly accessible on the bastion host, which is a lateral movement risk if the bastion is compromised.

ProxyJump is strictly better for the common case: the connection to the internal host is established from your machine through an SSH tunnel, not from the bastion itself. No agent socket on the bastion.

Use ProxyJump unless you specifically need agent forwarding for something else.

Hardening basics

A bastion is only useful if it’s actually hardened. Minimum:

# /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no
AuthorizedKeysFile .ssh/authorized_keys
AllowUsers jumpuser

Key-only authentication — no passwords
Dedicated user with no shell access to the bastion itself (optional: ForceCommand to restrict what they can do)
Non-standard port reduces log noise, not actual security
fail2ban or equivalent for rate-limiting auth attempts
Minimal installed software — the bastion should do one thing
Regular log review (/var/log/auth.log)

Restricting to jump-only

If you want users to be able to jump through the bastion but not get a shell on it:

# In authorized_keys, prefix the key with:
restrict,port-forwarding ssh-ed25519 AAAA...

Or use AllowTcpForwarding yes with ForceCommand /usr/sbin/nologin — though the interaction between these options is subtle; test carefully.

For making the bastion reachable from outside without a public IP → Tunnels
For exposing internal web services via public URLs → Tunneled reverse proxy platforms

SSH

Mon, 01 Jan 2024 00:00:00 +0000

SSH (Secure Shell) is the standard protocol for encrypted remote access to Linux and Unix systems. It replaced telnet and rsh by wrapping the session in a cryptographic tunnel — authentication, commands, and data transfer all protected against interception and tampering.

Public key authentication

The default auth mechanism for any serious setup. You generate a key pair: a private key that never leaves your machine, and a public key that goes on the remote host.

ssh-keygen -t ed25519 -C "your@email.com"
ssh-copy-id user@host # appends public key to ~/.ssh/authorized_keys on remote

Prefer ed25519 over the older rsa — smaller keys, faster, stronger. Keep your private key protected with a passphrase; use ssh-agent to avoid typing it repeatedly.

Key deployment at scale

When you have many hosts, distributing public keys manually doesn’t scale. A typical pattern: submit your public key to a central approval system, which then deploys it to the relevant hosts via automation (Ansible, Puppet, etc.).

This keeps a clear audit trail — keys are approved, recorded, and can be revoked centrally without touching individual authorized_keys files.

Certificate authentication

At larger scale, even centralised key distribution gets unwieldy. SSH certificates solve this properly: instead of deploying individual public keys, you run an SSH Certificate Authority (CA). Hosts and users trust the CA, not each other’s individual keys.

Generate a key pair locally
Submit the public key to the SSH CA (backed by your identity provider — FreeIPA, Vault, etc.)
The CA issues a signed certificate with a short TTL
SSH to any host — the host trusts the CA, so the certificate is accepted without any pre-deployed keys

Short-lived certificates (hours, not days) dramatically reduce the blast radius of a compromised credential. No revocation lists to maintain.

SSH config

~/.ssh/config avoids repetitive flags on every connection:

Host bastion
 HostName bastion.example.com
 User deploy
 IdentityFile ~/.ssh/id_ed25519
 ForwardAgent yes

Host internal-*
 ProxyJump bastion
 User deploy

ProxyJump (formerly -J) lets you reach hosts that aren’t directly accessible — you SSH through the bastion transparently.

Port forwarding

SSH can tunnel TCP traffic, useful for reaching services on private networks:

# Local forward: reach remote Postgres via localhost:5432
ssh -L 5432:db.internal:5432 bastion

# Dynamic forward: SOCKS proxy through the bastion
ssh -D 1080 bastion

Hardening basics

Key settings in /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers deploy ansible

Disable password auth entirely once keys are in place. Restrict which users can log in. Run sshd -t to validate config before reloading.

Ssh on Backend Engineering Strategy Tools

BIFROST — Raspberry Pi jump node

Hardware

How it works

OPNsense config

SSH config

Bastion / jump server

Basic jump: manual two-hop

ProxyJump (recommended)

Agent forwarding vs ProxyJump

Hardening basics

Restricting to jump-only

Related

SSH

Public key authentication

Key deployment at scale

Certificate authentication

SSH config

Port forwarding

Hardening basics

Resources