Learn NetBSD - SSH & Remote Access Hardening

#Introduction

In episode 12 we built the npf firewall guarding the network door. But one door must remain open if we want to manage the server remotely: SSH. In this episode we'll secure SSH and remote access on NetBSD — tuning sshd_config for ed25519 keys, disabling root and password login, using tunneling, and protecting against brute force attacks with fail2ban.

#Starting Point

After a NetBSD installation, OpenSSH is already part of the base system and sshd is enabled. From episode 6 we know how to enable it:

Make sure sshd is enabled in /etc/rc.conf

sshd=YES

Start the service if it isn't running yet:

Starting the sshd service

service sshd start

Status confirmation

service sshd status
sshd is running as pid 1234.

Now let's lock the gate.

#Creating an ed25519 Key

Key-based authentication is far more secure than passwords — and ed25519 is a modern key type that's both secure and fast. On the client side (your machine), create a key pair:

Creating an ed25519 key on the client machine

ssh-keygen -t ed25519 -C "arman@nbsd11"

Example ssh-keygen output

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/arman/.ssh/id_ed25519):

The public key (id_ed25519.pub) is what gets registered on the server. Copy it to the NetBSD server:

Copying the public key to the server

ssh-copy-id arman@192.168.1.50

Example ssh-copy-id output

/usr/bin/ssh-copy-id: INFO: Number of key(s) added: 1

If ssh-copy-id isn't available, add it manually:

Adding the public key manually

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "ssh-ed25519 AAAA... arman@nbsd11" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Test logging in with the key:

Logging in with the ed25519 key

ssh arman@192.168.1.50

Example login session

Enter passphrase for key '/home/arman/.ssh/id_ed25519':
NetBSD/nbsd11 (console) login:

Warning

Make sure key-based login works before disabling passwords. If the key fails, you could lock yourself out of your own server. Test from a separate session first before changing the configuration.

#Locking Down sshd_config

The main OpenSSH configuration is in /etc/ssh/sshd_config. Let's secure it line by line:

In sshd_config

PermitRootLogin no

In sshd_config

PasswordAuthentication no

#3. Limit Which Users Can Log In

In sshd_config

AllowUsers arman devops

#4. Limit Attempts and Time

In sshd_config

MaxAuthTries 3
LoginGraceTime 30

#5. Turn Off Reverse DNS Lookup

In sshd_config

UseDNS no

UseDNS no avoids login delays when the server attempts reverse DNS resolution — combined with a firewall, this makes connections feel much faster.

#The Final Result

sshd_config contents (security section)

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers arman devops
MaxAuthTries 3
LoginGraceTime 30
UseDNS no

After changing, apply the configuration:

Verify then reload sshd

sshd -t
service sshd restart

Clean sshd -t output

sshd -t (no output means valid)

Always test with sshd -t before reloading — a single typo can lock you out.

#SSH Tunneling

SSH isn't just for logging in; it can also create encrypted tunnels. This is very useful for securely accessing internal services.

#Local Forwarding (Port Tunneling)

Forwarding a local port to a service inside the server's network:

Tunneling a local port to a remote service

ssh -L 8080:localhost:80 arman@192.168.1.50

Example tunnel usage

# Open a browser on the local machine to http://localhost:8080
# and access is forwarded to port 80 on the remote server

#Dynamic Forwarding (SOCKS Proxy)

Creating a local SOCKS proxy that routes all traffic through the server:

Creating a SOCKS proxy over SSH

ssh -D 1080 arman@192.168.1.50

Example usage

# Set the browser/proxy to socks5://localhost:1080
# Traffic is encrypted up to the server

#Brute Force Protection: fail2ban

Even with passwords disabled, there's still a chance of attacks against other services that use passwords. fail2ban scans logs and blocks IP addresses that fail too many times. Install from pkgsrc:

Installing fail2ban from pkgsrc

cd /usr/pkgsrc/security/py-fail2ban
make install clean

The basic jail configuration for sshd lives in /usr/pkg/etc/fail2ban/jail.local:

Contents of jail.local

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/authlog
maxretry = 5
bantime = 3600

Enable and start the service:

Enabling fail2ban

echo 'fail2ban=YES' >> /etc/rc.conf
service fail2ban start

Jail status confirmation

fail2ban-client status sshd

With maxretry 5, an IP that fails 5 logins is banned for 1 hour. fail2ban can be integrated with npf to block at the firewall level.

#Remote Access Best Practices

Rule	Reason
ed25519 keys only, no passwords	Passwords can be guessed/stolen
Root may not log in via SSH	Force login as a user, then `doas`/`sudo`
Restrict with `AllowUsers`	Principle of least privilege
Use default or custom port	A custom port doesn't add security, but reduces noise
Keep `MaxAuthTries` low	Slow down brute force
fail2ban active	Block attacking IPs

#Closing

In this episode 13, you've secured NetBSD remote access: creating ed25519 keys, tuning sshd_config to disable root and password login, using SSH tunneling, and protecting the server from brute force with fail2ban.

Key takeaways:

ed25519 key-based authentication replaces passwords — test it first before disabling passwords.
In sshd_config: PermitRootLogin no, PasswordAuthentication no, AllowUsers, MaxAuthTries, and UseDNS no.
Always run sshd -t before reloading.
Use tunneling (-L/-D) for secure access to internal services.
fail2ban blocks attacking IPs — enable it and monitor its jails.

In the next episode, episode 14, we'll secure encrypted communication: TLS, OpenSSL, and certificates — creating keys and CSRs, self-signed certificates, managing trust with ca-certificates, and automating certificates with Let's Encrypt. See you in episode 14!