This article explains how on JUNOS and JUNOS-EVO SSH access is denied due to large number of stale sessions with the error " sshd[pid]: error: no more sessions"
SSH configuration on JUNOS
system {
services {
ssh {
root-login deny;
protocol-version v2;
sftp-server;
connection-limit 40;
rate-limit 100;
}
SSH configuration on EVO
rate-limit 5;
SSH Multiplexing: Allows multiple SSH sessions to share a single underlying TCP connection.
SSH Non-Multiplexing: Each SSH session establishes a separate TCP connection.
The maximum SSH connection limit is configured to 40 sessions for both Junos and EVO platforms. The configured SSH rate limits are:
To check whether an SSH session is multiplexed or non-multiplexed, use the following shell command:
user@router-re0# run start shell command "ps -aux | grep ssh"
netops 31901 0.0 0.0 774536 12392 - S 06:04 0:00.01 sshd:netops@4,5,6,7,8,9,10,11 (sshd) <<< Multiplexed TCP session.
The issue arises when the SSH client abruptly terminates the SSH connection without sending a FIN message to properly close the TCP connection. This behavior results in multiple sshd processes becoming ZOMBIE processes, which remain active even after the idle-timeout setting has been configured.
“sshd[XXXX]: error: no more sessions”
This error indicates that SSH multiplexing is enabled on the Customer SSH client, and the number of sessions has exceeded the default limit for a single TCP connection, which is 10 sessions per connection.
“inetd[XXXX]: Number of ssh connections at max limit (40)”
This error indicates that the number of SSH connections has reached the maximum limit configured on the device, which is 40 sessions.
“xinetd[XXXX]: Deactivating service ssh due to excessive incoming connections. Restarting in 60 seconds.
xinetd[8282]: Activating service ssh”
This error indicates that the SSH rate limit—configured on Customer device at 5 connections/minute for EVO and 100 connections/minute—is exceeded. As a result, xinetd temporarily deactivates and then restarts the sshd service.
It is expected that the Customer SSH client should properly terminate its connections via TCP FIN packets and ensure efficient resource utilization. Failure to terminate connections correctly could lead to the system reaching its maximum connection limit, which may impact overall performance and accessibility
To mitigate this issue, the client’s reachability can be validated by configuring the following options.
set system services ssh client-alive-count-max [number]
set system services ssh client-alive-interval [time-second]
client-alive-count-max: Specifies how many "client-alive" messages can go unanswered before the connection is closed. (default = 3)
client-alive-interval: Specifies the time, in seconds, between each "client-alive" message. (default = 0)
Total time before termination = client-alive-interval × client-alive-count-max
Example:
set system services ssh client-alive-interval 60
set system services ssh client-alive-count-max 5
Total time before termination = 60 x 5 = 300 seconds: meaning that the ssh session will be terminated after 300 seconds.
This issue might be seen if the following conditions are met: