SSH administration

SSH on OPNsense is the out-of-band management channel that saves you when the GUI is broken, when the certificate has expired, when the management VLAN has a routing problem, or when you need to capture packets from the console. It is also a direct root shell on the firewall. Securing SSH is not optional.

This lesson covers how to configure SSH for key-only authentication, restrict it to a management network, choose modern cipher and key exchange algorithms, and apply the operational discipline that keeps SSH a safe channel.

Disable password authentication

The single most important SSH hardening is to disable password authentication entirely. With password auth enabled, every Internet-facing SSH service is a credential-stuffing target. With key-only auth enabled, an attacker without the private key cannot log in regardless of password reuse or breach database exposure.

OPNsense exposes the relevant setting under System → Settings → Administration → Secure Shell. The relevant options:

• Login with password: disabled.
• Login with SSH key: enabled (when keys are configured for the user).
• Permit root login: “No” or “Prohibit password”. “Yes” is acceptable only if key-only is enforced for root.

The configuration change takes effect on the next SSH service restart. The GUI shows a “restart SSH” button after the apply.

The verification after disabling password auth is to attempt an SSH login with a password from a test workstation. The expected result is Permission denied (publickey) — the server is telling the client that password auth is no longer offered. Any other error message indicates that the configuration did not take effect.

Issue and configure operator keys

The operator workflow for key-based SSH:

1. Generate a key on the operator workstation. ssh-keygen -t ed25519 -C "operator@workstation". Ed25519 is the right default — fast, short, modern, with no parameter choices to get wrong. RSA 4096 is acceptable for legacy interop; everything smaller is not.
2. Add the public key to the OPNsense account. Under System → Access → Users, edit the operator account and paste the public key (the contents of ~/.ssh/id_ed25519.pub) into the “Authorized keys” field.
3. Test the connection from the operator workstation. ssh operator@fw.example.com. The first connection prompts to trust the host key; subsequent connections use the cached host key.

A few production details:

• One key per workstation, not per operator. If an operator uses two workstations, they have two keys. Revoking a key revokes a specific workstation, not the operator access everywhere. This matches the principle that authentication credentials should be scoped to the device that holds them.
• Use a hardware-backed key where possible. YubiKey, Titan, and similar devices store the private key in hardware and require a physical touch for each authentication. SSH supports this via the FIDO2 key type (ssh-keygen -t ed25519-sk).
• Passphrase the private key. A passphrase on the private key prevents use of the key if the workstation is stolen. ssh-agent caches the decrypted key for the session so the operator does not retype the passphrase on every connection.

$ ssh-keygen -t ed25519 -C operator@jump01

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/operator/.ssh/id_ed25519): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/operator/.ssh/id_ed25519
Your public key has been saved in /home/operator/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:abc123def456... operator@jump01
The key's randomart image is:
+--[ED25519 256]--+
|        .o=*+    |
|       .o+o..    |
|        oo...    |
|       .o...     |
|      oSo.       |
|     .o.=        |
|    ..oo.+       |
|   .. .o+        |
|    ..o+ .       |
+----[SHA256]-----+

Restrict SSH to a management network

SSH should never be reachable from the WAN. The same logic as the GUI applies: SSH is a direct root shell, and an exposed SSH service is an attack vector. The production pattern is the same three layers:

1. Listen interface: bind SSH to a specific interface under System → Settings → Administration. The default is “All”. Production is “LAN” or “Management VLAN” or both.
2. PF rule on the WAN: block TCP 22 to the firewall IP. Defence in depth.
3. Source restrictions: if SSH is reachable from the management VLAN, restrict by source IP using an alias of operator jump hosts.

The sockstat -l -P tcp | grep ':22 ' verification confirms the listen interface. The pfctl -s rules | grep ':22 ' verification confirms the WAN rule.

Secure defaults for ciphers, KEX, and MAC

Modern OpenSSH has sensible defaults, but OPNsense configuration is conservative. The hardening is to disable anything older than the modern set:

• Ciphers: chacha20-poly1305@openssh.com, aes256-gcm@openssh.com, aes128-gcm@openssh.com. Disable aes128-cbc, aes256-cbc, and any *-etm MAC variants that exist for them.
• Key exchange: curve25519-sha256, curve25519-sha256@libssh.org, diffie-hellman-group16-sha512, diffie-hellman-group18-sha512. Disable diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1 — both are weak by modern standards.
• MACs: hmac-sha2-512-etm@openssh.com, hmac-sha2-256-etm@openssh.com. Disable hmac-sha1-* and hmac-md5-*.
• Host key algorithms: ssh-ed25519. rsa-sha2-256 and rsa-sha2-512 are acceptable for interop with older clients. Disable ssh-rsa (the SHA-1 variant) and any older DSA host keys.

OPNsense exposes these via the GUI under System → Settings → Administration → Secure Shell → Advanced. The changes take effect on the next SSH service restart.

The verification is to run ssh -vvv operator@fw.example.com on a test workstation and confirm the negotiated cipher, KEX, and MAC match the secure list. The verbose output shows the offered algorithms and the negotiated one; if the negotiated algorithm is not on the secure list, the hardening is incomplete.

Operational patterns

Three patterns make SSH manageable in production.

Use a jump host

Operators connect to a single hardened jump host that has SSH access to every firewall in the estate. The jump host has the operator keys, audit logging, and a session recording capability. Operator workstations connect only to the jump host. This reduces the number of hosts with SSH keys to one per operator and centralises the audit trail.

The firewall configuration for jump-host access is to permit SSH only from the jump host IP (an alias) and deny SSH from all other sources on the management VLAN.

Rotate keys on operator departure

When an operator leaves, their SSH key must be removed from every account on every firewall. The audit trail is last output, the SSH auth log, and the list of authorized keys per account. The discipline is the same as password rotation: removing access is part of the offboarding checklist.

Audit SSH access

The SSH auth log records every connection attempt, success, and failure. The OPNsense GUI exposes this under System → Access → Logs. The production discipline is to review the log for:

• Failed attempts from unexpected source IPs.
• Successful logins outside business hours.
• Logins for accounts that should not be active.
• Logins immediately after key changes (a window where old keys may still be cached).

Summary

• Disable password authentication. Key-only is the production default.
• Bind SSH to a management interface. Block SSH from the WAN in PF.
• Use Ed25519 keys (or RSA 4096) with passphrases. One key per workstation.
• Harden the cipher, KEX, and MAC lists to the modern set.
• Use a jump host, rotate keys on departure, audit the SSH auth log.