What you are describing is known as SSH multiplexing.
I use that setup in a devops setting for caching my connections to any VMs.
In that way I reuse the same connection for up to 30 minutes/cache the connection without renegotiating the entire SSH connection (and authenticating the user) in each new command.
It gives me an huge boost in speed when sending (multiple) commands in a row to a VM/server.
The setup is done on the client side, and for a cache of 30 minutes, the setup can be done in
MaxSessions parameter, also in
ssh_config also defines how many multiplexed connections simultaneous connections are allowed; the default value is 10. If you need more simultaneous cached connections you might want to change it.
For instance, for a maximum of 20 cached connections:
For more information, see OpenSSH/Cookbook/Multiplexing
An advantage of SSH multiplexing is that the overhead of creating new
TCP connections is eliminated.
The second and later connections will reuse the established TCP connection >over and over and not need to create a new TCP connection for each new SSH connection.
Also see Using SSH Multiplexing
SSH multiplexing is the ability to carry multiple SSH sessions over a
single TCP connection
Without multiplexing, every time that command is executed your SSH
client must establish a new TCP connection and a new SSH session with
the remote host. With multiplexing, you can configure SSH to establish
a single TCP connection that is kept alive for a specific period of
time, and SSH sessions are established over that connection. This can
result in speed increases
that can add up when repeatedly running commands against remote SSH hosts.
Lastly, as the multiplexing keeps the TCP connection open between the client and the server, you will have the guarantee that you are talking with the same machine in the load balancer as long as the cache is open/active.