Calculate maximum concurrent SSH sessions supportable under sshd MaxSessions and MaxStartups.
sshd's MaxSessions caps how many multiplexed shell/exec/subsystem sessions can share a single already-authenticated TCP connection, while MaxStartups caps how many unauthenticated connections may be in the login/handshake phase concurrently (beyond that, sshd starts randomly dropping new connections to protect against connection-flood attacks). The theoretical maximum multiplies the two, but the practically useful ceiling is bounded by how many TCP connections actually arrive concurrently — most environments never simultaneously hit both limits at once.
Session capacity
theoretical_max_sessions = MaxSessions × MaxStartups; memory = sessions × memory_per_session
Once unauthenticated connections reach MaxStartups, sshd begins probabilistically refusing new connection attempts (the drop probability ramps up between MaxStartups' three colon-separated values, e.g. 10:30:60, until it hits 100% at the third number) as a defense against connection-flood or brute-force attacks.
No — MaxSessions limits multiplexed sessions (multiple shells/commands) within one already-open SSH connection, not the number of distinct client connections. Two separate users each opening a fresh connection are governed by MaxStartups (pre-auth) and available system resources, not MaxSessions.
Both are set in /etc/ssh/sshd_config (`MaxSessions 10`, `MaxStartups 10:30:100`), and require `systemctl reload sshd` (or restart) to take effect on already-running daemons.