OPNsense 20.1.2 and newer
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.
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. 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.1.2, you can tune the algorithms used by SSH directly in the web admin:
- Starting from OPNsense 20.1.2 but not including 20.7 and newer, you need to apply a couple of official OPNsense patches (see below)
- For OPNsense 20.7 and newer, these settings will be included in the core by default. The settings were implemented in https://github.com/opnsense/core/issues/3975 and are added to the 20.7 milestone to be released soon.
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.
Until the new SSH algorithm settings are released in OPNsense 20.7, users can enable them by running these commands on their OPNsense box/vm:
opnsense-patch 5df590c opnsense-patch 1165119 service configd restart
As there is no ordering among the chosen algorithms, advanced users that tune these settings should pick their choices to be the most hard that their SSH clients support.
The new algorithm settings will be released with OPNsense 20.7 according to the above Github issue. If you have OPNsense 20.7 or newer, these settings should be available for you on the web interface out of the box.
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:
ssh -Q kex
ssh -Q cipher
ssh -Q mac
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.
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.