So, as exposing the HTTPS administration page of pfSense to the big, bad, Internet is a big “no no”, the only proper way should be to set up SSH2 and allow port forwarding.

Now, there are already articles out there telling you that using username+passwords to secure SSH2 is not the way to go… Using certificates is. However, I wanted more… I wanted both… Why is it that pfSense will only allow one or the other when sshd already allows enforcement of both?

So, once again, rolling up my sleeves, I dived into the murky waters of the pfSense shell…

Trial and Error…

I initially stumbled upon /etc/ssh/sshd_config and tried to edit it, adding AuthenticationMethods publickey,password and also re-enabling ChallengeResponseAuthentication, PasswordAuthentication and UsePAM…

Unfortunately, simply restarting the SSH service (via the administration web UI) would see the sshd_config file get overwritten; there was a reason someone wrote, on the first line of sshd_config:

The Hunt Continues…

So sshd_config gets overwritten – but by what? Turns out that the answer is just one directory level above – /etc! Actually /etc/sshd holds the key (pardon the pun).

I originally “forced” the change to be “key + password” instead of “key only”, ensuring I had a backup first.

Screwing Up

Unfortunately, the first attempt at editing /etc/sshd turned out to be a minor disaster – SSH service would not restart via the administration web UI… And telnet did not appear to be an option (with people attempting to shout down anyone asking about telnet with cries of “Insecure!” – handily forgetting edge cases like this).

Recovering

It proved to be a wise choice to have a backup sshd_config; then, using Diagnostics > Command Prompt > Execute Shell Command from the web UI, I simply restored my back up sshd_config and the SSH service started just fine.

cp /etc/sshd.bak /etc/sshd

Lesson(s) Learned

Sidetracking a little bit, I learned that

• I could restart the SSH service from the command line/shell directly by simply calling /etc/sshd!
• restarting sshd via calling /etc/sshd does not kill your current SSH2 session (yay!)
  • so, checking for changes to /etc/sshd simply means running /etc/sshd again
  • it also means that you do not need to attempt to restart SSH from the administration web UI, which does/will kill your current SSH2 session

Making It Work…

So, having recovered the original file, I re-SSH’d into pfSense and took another crack at it. This time around, the edits were successful.

Making It Global…

Not content with this hack, I sought to edit the administration web UI’s PHP file, to create another option “key && password” (i.e. instead of just “key only” or “password or key”). This brought me to pfSense’s Git. A quick search on the configuration “node” in question brought up all relevant file(s):

• /usr/local/www/system_advanced_admin.php
• /etc/sshd

Reading off other setting examples on the same (PHP) “page”, I edited the form to support additional settings in a drop down list (instead of a “yes/no” check box). This required subsequent changes to /etc/sshd to match.

Both files are now working (and tested), and may be found here: pfSense_sshd_edits.

You can also find the changes in a pull request for the pfSense CE…

2018/04/10 Update: My pull request (PR) has been accepted; pfSense >=2.4.4 should see the new options.