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

Jump-Server on Backend Engineering Strategy Tools