TCP Stack Metrics in OpenSSH

[Damien Miller]

On Mon, 20 Dec 2021, rapier wrote:

> All,
> 
> Before I post a patch I thought I'd see if there was any interest.
> 
> As part of some work I'm doing I have implemented a method to have an SSH
> client report on both the local and remote TCP instrument metrics via the
> TCP_INFO struct. The goal is to provide network engineers and knowledgeable
> users a means to profile and diagnose their SSH connections.
> 
> Currently I have this working under Linux, FreeBSD, and NetBSD. OpenBSD
> doesn't seem to have the tcp_info struct (if I'm mistaken please let me know).
> Apple is just being annoying and redefined that struct in their own very
> special way that doesn't correspond that well.
> 
> Quick run down of the method. Every N seconds (default of 5) the client sends
> a SSH2_MSG_GLOBAL_REQUEST to the server with a custom type. If the server
> supports it then it dumps the TCP_INFO for the SSH TCP socket into a
> serialized object. The client receives this, extracts the information, and
> writes it to a file (default of ssh_stack_metrics.remote). The client then
> queries the socket on it's end and extracts the same information and write
> that to a different file (default of ssh_stack_metrics.local).
> 
> It handles different versions of the TCP_INFO struct, cases where the server
> doesn't understand the message request, and where TCP_INFO isn't available.
> 
> Upside: More information for diagnostics and performance metrics. Doesn't
> impact performance when not being used. Doesn't seem to impact performance
> when in use.
> 
> Downside: 1) The serialization is handled by the binn object serialization
> library from https://github.com/liteserver/binn. It's not an external
> dependency but it is code that needs to be included in the repo. 2) The timer
> is in main loop of client_loop in clientloop.c. In an interactive session
> where it's waiting for input the timer doesn't necessarily fire every N
> seconds as the loop pauses waiting for input. In most cases where people would
> use this that won't be a problem.
> 
> Anyway, if people want to see the patch, have any interest, or questions
> please let me know.

I don't know if this belongs in ssh itself, but it would be pretty easy
to turn into a ProxyCommand, perhaps one that used ProxyUseFdPass to
remove the overhead of copying data back and forth...

-d