Learn DragonFlyBSD - SSH & Remote Access Hardening

#Introduction

In episode 12 you installed the pf and ipfw firewalls to guard the network gate. But there's one door that's almost always open on every server: SSH. Port 22 is the most common attack target on the internet — bots scan it, try passwords, and flood the logs. This episode turns SSH from a weak point into a strong one.

Imagine SSH as the office's back door, openable only with a special key (ed25519). This episode teaches you: replacing an easily copied key (a password) with one that's practically impossible to forge, closing access for high-risk accounts (root), then installing a watchman (fail2ban) who throws out people who knock too often.

#sshd_config Configuration

#Strengthening Authentication

The main configuration file is /etc/ssh/sshd_config. Hardening starts by disabling weak authentication and disabling root login:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no

PermitRootLogin no forces all logins to use a regular user (then doas/su for privileges). PasswordAuthentication no disables passwords — only public keys are accepted. This combination is what makes password brute-forcing pointless.

#ed25519 Keys

First, generate an ed25519 key on the client side:

ssh-keygen -t ed25519 -a 100
ssh-copy-id dewi@server

-t ed25519 picks the most modern key algorithm, -a 100 strengthens the KDF. ssh-copy-id copies your public key to ~/.ssh/authorized_keys on the server. Once you've verified the key works, only then enable PasswordAuthentication no.

#Restricting Access

Two settings narrow down who may enter:

MaxAuthTries 3
UseDNS no
AllowUsers dewi raka
AllowGroups wheel

MaxAuthTries 3 limits authentication attempts before the connection is dropped. UseDNS no disables the slow, unnecessary reverse-DNS lookup. AllowUsers and AllowGroups restrict which users/groups may log in — deny-by-default for SSH access.

#Restart & Verify

After changing the configuration, validate and restart:

sshd -t
service sshd restart

sshd -t checks the configuration syntax without loading it — a mandatory habit before restarting sshd on a production server.

#Tunneling

SSH can also be an encrypted pipe for other services. Port forwarding forwards a local port to a port on the other side:

ssh -L 8080:localhost:80 dewi@server
ssh -L 5432:db.internal:5432 dewi@server

The first command opens port 8080 on the local machine, forwarded to port 80 on the server — accessing an internal web app without opening a firewall port. The second line forwards to a third host (db.internal) — a real-world example of database access that's never exposed to the internet.

#fail2ban

Even with passwords disabled, bots can still flood logs and try other users. fail2ban watches the logs and blocks IPs that show suspicious patterns:

pkg install py311-fail2ban

Its configuration lives in /etc/fail2ban/. Enable a jail for sshd, and fail2ban will automatically block IPs that fail login too many times:

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 5

With pf as the firewall, fail2ban can block IPs directly in the pf ruleset — a very effective and lightweight combination.

#Closing

In this episode 13 you secured remote access to DragonFlyBSD: strengthening sshd_config with ed25519 keys, disabling root and password logins, generating keys with ssh-keygen, tunneling via port forwarding, and hardening with UseDNS no, MaxAuthTries, AllowUsers, and fail2ban.

Key takeaways:

• PermitRootLogin no + PasswordAuthentication no are the two lines with the biggest impact on SSH security.
• Generate ed25519 keys with ssh-keygen -t ed25519 -a 100 and install them with ssh-copy-id.
• UseDNS no, MaxAuthTries 3, AllowUsers, and AllowGroups narrow the attack surface.
• SSH tunneling (ssh -L) reaches internal services without opening firewall ports.
• fail2ban blocks malicious IPs; combine it with pf for the best results.

In the next episode, episode 14, we secure the encryption layer: TLS, OpenSSL & certificates. You'll generate keys, CSRs, and certs with openssl req and openssl verify, manage ca-certificates, get Let's Encrypt certificates with acme-client or acme.sh, and understand the basics of PKI.