Why does Venafi require Multiplexing for SSH connections? and other Related Questions

Applies To:

All versions of Trust Protection Platform

Summary:

Venafi Trust Protection Platform requires SSH multiplexing to be enabled on target SSH servers and appliances, which is enabled by default by all major Linux and UNIX distributions. Usage of multiplexing (MaxSessions) allows for reduced overhead and cost on target systems. Multiplexing also significantly improves performance, especially over high latency lines. Venafi Trust Protection Platform does honor connection limits (maxlogins) for accounts to target hosts to support increased security controls and defaults to a value of 1.

More Information:

• What is SSH Multiplexing?
  Answer: SSH Multiplexing is the ability to have multiple open shell or file transfer sessions within a single network connection. Multiplexing is supported by all major Linux and UNIX distributions.
  
  
• What are the benefits of SSH Multiplexing?
  Answer: SSH authentication can be slow, especially over high latency lines. A high number of SSH connections can significantly increase overhead and cost on the client and server systems and unnecessarily clutter audit logs with redundant authentication processes. SSH Multiplexing addresses this by allowing multiple open shells, including SFTP and SCP to happen over an existing connection. This means that reducing the number of TLS handshakes has a significant improvement to the amount of time needed to complete tasks.
  
  
• Is SSH Multiplexing enabled by default?
  Answer: Yes, all major Linux and UNIX distributions enable SSH Multiplexing by default, with a shipping value of 10.
  
  
• When was SSH Multiplexing introduced?
  Answer: First introduced by OpenSSH on August 18, 2004 in version 3.9
  
  
• How is SSH Multiplexing controlled?
  Answer: In sshd_config file there is a parameter called MaxSessions which is typically defaulted to a value of 10. Setting the value to 1 will disable SSH Multiplexing and make the system incompatible with many SSH operations from Venafi Trust Protection Platform. Setting the value to 0 will disable all SSH connections. SSHD service restarts are required after changes are made.
  
  
• What is the difference between multiple sessions and multiple connections in SSH?
  Answer: SSH Multiplexing refers to the number concurrent sessions a single client can have within their own single SSH connection. Conversely, a Linux system can be configured to limit the global number connections or the total number of connections per client. Sometimes you will see connections and concurrent logins are used interchangeably in online forums and vendor documentation. 
  
  
• How are multiple SSH connections controlled?
  Answer: In /etc/security/limits.conf and /etc/security/limits.d/* files you can set maxlogins either on a per user basis or globally for the target system. Each connection represents a separately and independently authenticated connection that has its own MaxSessions value applied for multiplexing.
  
  
• Does Trust Protection Platform honor reducing multiple connections?
  Answer: Yes, on Device assets in the Policy Tree, you can configure the Concurrent Connection Limit, which defaults to 1 to tell the Venafi Trust Protection Platform how many Concurrent Logins it is allowed to have for a given host. The value is policyable so it doesn't need to be set on every configured device if changing from the default is needed. This setting does not affect multiplexing (MaxSessions).
  
  
  
• What are the SSH hardening guidelines for SSH Multiplexing?
  Answer: Most Vendor Hardening guidelines will either specify to leave MaxSessions to the default value or not mention the setting at all. Why? Because Multiplexing isn't considered a security control around SSH, it is a resource control to balance performance, resource consumption for a single user.  It has a limit in order to reduce risk of a Denial of Service Attack, which is why it is defaulted to 10 (as opposed to unlimited or 1,000).
  IBM best SSH practices documents an expected value of 100 and Suse documentation does not specify changing MaxSessions from the default value.
  
  
• What are the arguments for disabling multiplexing, and why are they lacking?
  Answer: Let's examine different reasons why people recommend modifying or disabling MaxSessions:
  
  1. Confusion: Many unofficial hardening guides or online discussion boards confuse MaxSessions and maxlogins. They are trying to limit the number of times a user can authenticate concurrently (maxlogins) because they expect that the account will only be used by a single client. Seeing authentication attempts from other clients is a sign that the account is compromised. However, because of confusion of terms, some organizations will inadvertently reduce MaxSessions, which does not produce any security improvement, and comes at the cost of performance.
  2. Resource Management: This is a perfectly legitimate reason to lower or raise the value of MaxSessions to a different value based on the expected usage patterns, the type of use, and the available resources of the system. For Example, a Proxy system or Jump server will typically have a higher value for MaxSessions than the default of 10. Resource Management is a valid reason for changing the value, but it is not a good reason for setting it to 1. Disabling Multiplexing will negatively affect resource utilization on the target SSH server, and cause performance degradation. 
     
  3. Auditing: Auditing is not a valid reason to disable SSH Multiplexing. It decreases performance, increases cost, and makes audit records more difficult to parse because the same user is doing multiple things from the same client to the same host. This is the exact scenario why Multiplexing was created and enabled by default. There is already an audit log when the connection was created, requiring additional authentications for additional work streams is misguided security enforcement that has impractical negative consequences on performance, costs, and operations.
  4. Session Hijacking: There are some claims on the internet that Multiplexing should be disabled because leaving it enabled increases the risk for someone to use an existing SSH connection in the event an SSH Client system is compromised. However, if a system is compromised a bad actor can simply create a new connection or wait for the system to create a connection and take over the single session. Disabling multiplexing does not provide any additional protection from session hijacking.

Conclusion:

Multiplexing in general is a great way in technology to allow multiple streams to use the same connection, and the same holds true for SSH multiplexing. It reduces overhead, increases throughput, without sacrificing security because it can only be used once a user is authenticated. Venafi Trust Protection Platform requiring multiplexing follows industry and security best practices.