the bastion host, one hardened door in

why one door beats fifty

if every server in your network accepts ssh connections straight from the internet, you don't have a network, you have fifty front doors and no idea who's jiggling the handles. a bastion host flips that. one hardened box sits between the outside world and everything internal. nothing else is reachable directly. you patch one thing well instead of patching fifty things badly.

what a bastion actually is

it's a small, boring, heavily watched server. its only job is to let authorized people jump from the outside into your internal network. it doesn't run your app, it doesn't hold your database, it doesn't do anything interesting. boring is the point. the less it does, the less there is to break.

keys only, no passwords, ever

passwords get guessed, phished, and reused across sites you've never heard of. ssh keys don't have that problem. lock the bastion down so password auth is off entirely.

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

put that in /etc/ssh/sshd_config on the bastion, restart sshd, and test with a second terminal open before you log out. nothing ruins a friday like locking yourself out of the only door.

proxyjump, the command that does the work

this is the piece from the checklist that ties it together:

ssh -J bastion internal-host

breaking it down: -J bastion tells ssh to first connect to your bastion host, then use that connection as a tunnel to reach internal-host, which never has to be exposed to the internet at all. your laptop authenticates to the bastion, the bastion forwards the encrypted tunnel through to the internal box, and you land on it as if you'd connected directly, except the internal machine's ssh port never touched a public ip.

you can make this permanent in your ssh config so you don't type it every time:

Host internal-host
    HostName 10.0.1.15
    ProxyJump bastion

now ssh internal-host just works, and the jump is invisible to you but still enforced.

log every session, no exceptions

a bastion without logging is just a really important box you're hoping nobody notices. turn on session recording so every command run through the bastion is captured. tools like auditd, ssh's own verbose logging, or a proper session recorder give you a trail. if something goes wrong later, "who did what and when" shouldn't require guesswork.

LogLevel VERBOSE

that single line in sshd_config logs the fingerprint of every key used to authenticate, which means you can tie every login back to a specific person, not just "someone with a key."

mfa on the bastion, not maybe

keys are strong, but a stolen laptop with an unlocked key file is still a stolen laptop. adding mfa, google authenticator pam module, duo, yubikey, whatever fits your setup, means a key alone isn't enough to get through the one door that matters. this is the single control most home labs and small teams skip, and it's the one that stops the "oops, synced my ssh keys to a cloud backup" disaster from becoming a full breach.

the takeaway

a bastion host isn't about fancy tooling, it's about reducing your attack surface to one well guarded point instead of scattering exposure across every machine you own. if you're running anything with internal servers right now, ask yourself honestly: how many of them accept ssh from the open internet? if the answer is more than one, that's your project for this weekend. build the bastion, lock it to keys, wire up mfa, turn on logging, and route everything else through it with proxyjump. one door. and it's watched.