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

oldunixguy

@stephenw10
This design has been used for years with our clients and and openssh servers.
The client is NOT configured for generating TCPKeepAlives nor ServerAliveInterval or CountMax. Instead the server is initiating the keep alives. In this test case the server is 192.168.0.1. In all the test cases you can see in the traces that the server initiates the keep alive probe. the client end is 192.168.0.100. The traces reflect the proper sequences but NOT the proper time intervals. The 3-packet versus 4-packet matter is yet to be studied by me and as an operational matter not that interesting. The time intervals are the important matter.
thanks
oldunixguy

stephenw10

Hmm, I would probably try removing the duplicate ClientAliveInterval value then. Just comment out the line:
https://github.com/pfsense/pfsense/blob/RELENG_2_7_2/src/etc/sshd#L82

Or just set it to 60 there directly as a test.

oldunixguy

Well, I'm back and the problem still exists. I just tested pfsense ce 2.8 and it does NOT work.

I enter the folloeing in /etc/sshd_extra
TCPKeepAlive no
ClientAliveInterval 60
ClientAliveCountMax 5

reboot

then examine the /etc/ssh/sshd_config

In it there is NO TCPKeepAlive at all, even commented.
There IS a ClientAliveInterval 30 BUT this is not correct value.
There is NO ClientAliveCountMax at all, even commented.

With other sshd implementations if there is not an entry for a value, say TCPKeepAlive, then an internal DEFAULT is used.

From previous report it seems the default TCPKeepAlive is "active".

So, the procedure to "alter" or "add" sshd config values here is BROKEN.

Could someone produce a bug report so this can get fixed?
thanks
oldunixguy

Gertjan

@oldunixguy

I created the file : /etc/sshd_extra and added :
#test line 1
#test line 2
TCPKeepAlive no
ClientAliveInterval 60
ClientAliveCountMax 5

Then I unchecked :

and saved, (the SSH connection stopped, that's normal) then checked it again, and Saved.

I entered SSH again, and :

[25.07-RC][root@pfSense.bhf.tld]/root: cat /etc/ssh/sshd_config
# This file is automatically generated at startup
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
....... (snipped) .....
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
# override default of no subsystems
Subsystem       sftp    /usr/libexec/sftp-server
#test line 1
#test line 2
TCPKeepAlive no
ClientAliveInterval 60
ClientAliveCountMax 5

so the 'extra' lines were added.

Btw : I do presume that 25.07 (pfSense Plus) and 2.8.0, pfSense CE, behave the same way ...

The script to include the "sshd_extra info" is still there in 'master' : https://github.com/pfsense/pfsense/blob/master/src/etc/sshd

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 match 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.