https://opnsense.org | https://github.com/opnsense
OPNsense is an open source, easy-to-use and easy-to-build HardenedBSD based firewall and routing platform. OPNsense includes most of the features available in expensive commercial firewalls, and more in many cases. It brings the rich feature set of commercial offerings with the benefits of open and verifiable sources.
SSH hardening guide for OPNsense 20.7 and newer
Some of the SSH hardening recommendations from https://www.ssh-audit.com/hardening_guides.html can be set directly on the OPNsense web interface via the System -> Settings -> Administration -> Secure Shell form.
As of 2020-06-01, you can tune the following SSH settings:
- Enable/Disable the SSH server
- Limit the user group who can login over SSH
- Allow/Disallow root user login
- Allow/Disallow password login (set up user keys in
System -> Access -> Users -> Add/Edit user -> Authorized keys) - Configure an alternative SSH port
- Limit the interfaces the SSH server listens on
- Select the allowed key exchange algorithms (see how to enable the feature below)
- Select the allowed ciphers (see how to enable the feature below)
- Select the allowed MACs (see how to enable the feature below)
- Select the allowed host key algorithms (see how to enable the feature below)
OPNsense has included the basic SSH options on its web interface from the beginning, but you could not tune the SSH algorithms recommended by the ssh-audit tool easily. Previously various hacky solutions existed that involved modifying automatically generated core files or the original template files that might get lost over an upgrade.
Since OPNsense 20.7, you can tune the algorithms used by SSH directly in the web admin. The settings have been implemented in https://github.com/opnsense/core/issues/3975
The provided SSH algorithm selectors on the form are still not the final solution as the selected algorithms' applied order in the generated configuration is defined by their display order on the form (a limitation of the current UI kit). However, for an advanced user, these provide the possibility to select only the most hardened options as to their liking. OPNsense is probably not used as a jump-host by many users - if an administrator can connect with latest openssh release over the hardest supported algorithms, it should be fine.
OPNsense 20.7+
If you have OPNsense 20.7 or newer, these settings should be available for you on the web interface out of the box.
How to choose algoritms?
To find out what algorithms your ssh client supports, you can run these commands, this is similar to the way OPNsense gets the options to the algorithm chooser dropdowns:
- KexAlgorithms:
ssh -Q kex - Ciphers:
ssh -Q cipher - MACs:
ssh -Q mac - HostKeyAlgorithms:
ssh -Q key
A good starting point is to select the following options for maximum compatibility with the probability that your client won't use the strongest/fastest option. As the algorithms may differ in computation speed or in the provided level of security, and their applied order in the OPNsense SSH server's config is nondeterministic (limitation of the current UI kit, it can't take into account the order of the selection), what you'd preferably want is to choose the strongest algorithms that are supported on both ends of the connection, otherwise, you won't be able to SSH into OPNsense until you find the middle ground.
- Key exchange algorithms:
curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha256,sntrup761x25519-sha512@openssh.com - Ciphers:
chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr - MACs:
hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com - HostKeyAlgorithms:
ssh-ed25519,ssh-ed25519-cert-v01@openssh.com
The ordering of the above algorithms represent the best-choice-first mentality, so if you select only the *25519* options for KEX and HostKey, and the first ones for the others, it's the best trade-off between speed and security while forcing the SSH client to only use these. Otherwise, choose your own preferred algorithms depending on your use case or threat model.