pfsense-ce 2.7.4 SSH server: how to config ClientAliveCountMax and ClientAliveInterval

patient0

@oldunixguy disclaimer: I have no used these settings before but I was interested and did some reading and testing.

Why are the ClientAlive* settings not applied: FreeBSD Manual Pages: sshd_config states:

"Unless noted otherwise, for each keyword, the first obtained value will be used."

Since ClientAliveInterval is already set by pfSense, the later added custom setting has no effect.

One way to make it work for me is to use the Match directive to overwrite these settings. The above mentioned man pages list which directive can be overwritten with Match, the ClientAlive* are on the list.

My /etc/sshd_extra looked like:

TCPKeepAlive no
Match Address *
        ClientAliveInterval 60
        ClientAliveCountMax 5

Since TCPKeepAlive is not set by pfSense, overwriting will work (but is not allowed in Match). You can restrict Address to subnets if that is necessary. E.g.

Match Address 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16

... to only apply it non-WAN addresses.

I'm not sure about the TCP flow to expect. Testing with a Debian client and connecting to pfSense CE 2.8.1-BETA and a Debian 12 server, both with the same Match statements, resulted in the same flow: first a 4 packages exchange and 3 packages after that.

Gertjan

@patient0 said in pfsense-ce 2.7.4 SSH server: how to config ClientAliveCountMax and ClientAliveInterval:

"Unless noted otherwise, for each keyword, the first obtained value will be used."

Nice catch :
Thanks - that made me remember : just adding parameters hoping that "the last one is taken in account", which is something I did presume - doesn't work.
So, this is a "sshd" issue.

Editing "https://github.com/pfsense/pfsense/blob/master/src/etc/sshd" (make a patch for it so it auto applies) after an pfSense upgrade/update) will do the job.
The match trick is also a good idea and worth testing.

stephenw10

Mmm, there's no bug here that I can see, it's behaving exactly as expected. We could open a feature request perhaps.

Using a patch as a workaround seems reasonable if you really need that though.

Gertjan

@stephenw10 said in pfsense-ce 2.7.4 SSH server: how to config ClientAliveCountMax and ClientAliveInterval:

We could open a feature request perhaps.

Like : instead of appending, prepending the sshd_extra file ?

stephenw10

I was thinking more like exposing some of those values in the gui in an advanced config section for users who might need to set them.

oldunixguy

This must be considered a bug because ALL of the settings which are cast in concrete in the current /etc/ssh/sshd_config CANNOT BE CHANGED!

2 approaches to fix:

let the world edit /etc/ssh/sshd_config like 99% of the implementations for a very long time.

or

place ALL of the contents of /etc/ssh_extra BEFORE the template used to create /etc/ssh/sshd_config. Then any and all in /etc/sshd_extra overrides all of the template entries.

I prefer #1 to make it work like the rest of the world. Frankly, I'm amazed this has been busted for so long.

thanks
oldunixguy

stephenw10

It's not a bug because that's the expected behaviour. You could consider it a missing feature if you need to make changes there. Open a feature request: https://redmine.pfsense.org/

This is the first time I've seen anyone ask about it in 10 years though so it's clearly not a huge problem.

You could just patch the file to create the config with the values you need then carry that as a custom patch in the patches package.

oldunixguy

@stephenw10
In essence what you are saying is that ALL of the settings in /etc/ssh/sshd_config, AND THERE ARE A LOT OF THEM, cannot be changed!

And you don't think that is a problem?

I have hundreds of sshd_config files with significant changes on numerous linux, windows, raspberry pis and more. SSH would not work for my customers without all these changes!

So pfsense just won't work then. Incredible!

regards
oldunixguy

johnpoz

@oldunixguy must be really important since you waited 2 months to answer. But that is not what he said at all.. What he said is change the file that creates those values via a patch.

stephenw10

Indeed. That file is auto-generated using default values that work for almost everyone. It cannot be edited manually.

It isn't a problem in as much as this is the first time I've ever seen anyone ask about it.

It's clearly a problem for you because you're using a custom client side config.

A solution to that would be to carry a custom patch in pfSense that changes the default values used to generate the file so it works for you.

And/or you can open a feature request to expose those settings in the gui,