SSH并发连接数受限于MaxStartups（未认证连接）、MaxSessions（单用户会话）、系统文件描述符上限、PAM限速及fail2ban封禁等多层机制，需协同调优而非仅修改单一配置。
SSH服务端并发连接数不是单靠一个配置项就能调大的，关键得区分“未认证连接”和“已认证会话”，否则改了MaxStartups却卡在MaxSessions或系统资源上，连接照样被拒绝。
MaxStartups 控制未认证连接洪水
这是防爆破的第一道闸门，管的是“刚连上来还没输密码/没过密钥验证”的连接。默认值10:30:60意思是：最多放行10个未认证连接；超过10个后，每新增30个就随机丢弃1个；达到60个直接全部拒绝。
- 想支持更多并发登录请求（比如批量脚本、CI/CD触发），把
MaxStartups设成100或50:100:200更稳妥，别直接写死单值——后者在高并发突增时容易丢连接 - 改完必须重启服务：
sudo systemctl restart sshd，否则不生效 - 注意日志位置：
/var/log/auth.log里搜sshd.*max startups能确认是否真被限流了
MaxSessions 管单个用户的多会话能力
这个参数不影响你能同时让多少人登录，而是控制“同一个用户登录后能开几个窗口、几个SFTP通道、几组端口转发”。默认10，对普通运维够用，但自动化工具或IDE远程开发常会超限。
- 如果用户抱怨
sftp连不上、ssh -L报错或终端突然断开，先检查这个值是否够用 - 设为
MaxSessions 32比盲目拉到100更合理——每个会话至少占2个文件描述符，叠加ulimit -n限制才不会翻车 - 它只对已成功认证的连接生效，和
MaxStartups是两套机制，不能互相替代
系统级资源才是真正的天花板
哪怕sshd_config全放开，ulimit、systemd和服务进程的文件描述符上限没调，新连接一样被内核拒绝，错误常表现为accept: Too many open files或静默失败。
- 查当前sshd进程限制：
cat /proc/$(pgrep -f "sshd -D")/limits | grep "Max open files" - 永久放宽：在
/etc/security/limits.conf加sshd hard nofile 65535，再确保/etc/pam.d/sshd含session required pam_limits.so - systemd用户还得改服务单元：
sudo systemctl edit sshd，写[Service]段加LimitNOFILE=65535
别漏掉PAM和fail2ban的隐性影响
有些环境看似没配连接数限制，但/etc/pam.d/sshd里一句auth [default=die] pam_faildelay.so delay=3000000会让连续失败认证拖慢节奏，间接压低有效并发吞吐；而fail2ban封IP后，同一来源的连接会被直接掐断，根本进不了MaxStartups计数。
- 排查时先临时停掉
fail2ban：sudo systemctl stop fail2ban，看问题是否消失 - PAM限速不显式报错，但
journalctl -u sshd -n 50里会看到大量Failed password后跟着延迟日志 - 这些机制和
sshd_config参数是叠加生效的，单独调大任一参数都不足以解决真实瓶颈
真正卡住并发的往往不是MaxStartups本身，而是它背后那层文件描述符、内存、甚至fail2ban的IP黑名单——得一层层往下挖，不能只盯着配置文件改数字。
