การเชื่อมต่อ ssh พร้อมกันบนเซิร์ฟเวอร์ควบคุมยังคงลดลง

ฉันประสบปัญหากับการตั้งค่าที่ฉันใช้สำหรับการบำรุงรักษาเซิร์ฟเวอร์ของลูกค้าจำนวนมากผ่าน SSH ระยะไกลเป็นครั้งคราว

กำลังติดตามการตั้งค่า:

1 เซิร์ฟเวอร์ควบคุม X เซิร์ฟเวอร์ของลูกค้าจำนวนตามอำเภอใจตั้งค่าให้มีบัญชี 'บริการ' เชื่อมต่อกับเซิร์ฟเวอร์ควบคุมของฉันผ่าน SSH

ฉันได้ตั้งค่าไคลเอนต์ให้เชื่อมต่อกับเซิร์ฟเวอร์ควบคุมโดยอัตโนมัติ ซึ่งมี IP คงที่ ผ่านบัญชีบริการโดยใช้ autoSSH หลังจากบูทเครื่อง นี่เป็นของฉัน /etc/ssh/ssh_config บนเครื่องของลูกค้า:

# นี่คือไฟล์การกำหนดค่าไคลเอนต์ ssh ทั้งระบบ ดู
# ssh_config(5) สำหรับข้อมูลเพิ่มเติม ไฟล์นี้มีค่าเริ่มต้นสำหรับ
# ผู้ใช้ และค่าสามารถเปลี่ยนแปลงได้ในไฟล์การกำหนดค่าต่อผู้ใช้
#หรือสั่งได้ที่

# ข้อมูลการกำหนดค่าแยกวิเคราะห์ดังนี้:
# 1. ตัวเลือกบรรทัดคำสั่ง
# 2 ไฟล์เฉพาะผู้ใช้
# 3 ไฟล์ทั้งระบบ
# ค่าการกำหนดค่าใด ๆ จะเปลี่ยนแปลงในครั้งแรกที่ตั้งค่าเท่านั้น
# ดังนั้น คำจำกัดความเฉพาะโฮสต์ควรอยู่ที่จุดเริ่มต้นของ
# ไฟล์การกำหนดค่าและค่าเริ่มต้นในตอนท้าย

# ค่าเริ่มต้นทั่วทั้งไซต์สำหรับตัวเลือกที่ใช้กันทั่วไป เพื่อความครอบคลุม
# รายการตัวเลือกที่มีอยู่ ความหมายและค่าเริ่มต้น โปรดดูที่
# ssh_config(5) หน้าคน

เจ้าภาพ *
#ตัวแทนส่งต่อเลขที่
#ForwardX11เบอร์
#ForwardX11เชื่อถือได้ใช่
# การตรวจสอบรหัสผ่านใช่
# หมายเลข HostbasedAuthentication
# GSSAPIAuthentication เลขที่
# GSSAPIDelegateCredentials เลขที่
# GSSAPIKeyExchange หมายเลข
# GSSAPITrustDNS หมายเลข
# หมายเลขแบทช์โหมด
# CheckHostIP ใช่
# AddressFamily ใด ๆ
# ConnectTimeout 0
# StrictHostKeyChecking ถาม
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# IdentityFile ~/.ssh/id_ecdsa
# IdentityFile ~/.ssh/id_ed25519
#ท่าเรือ22
#พิธีสาร2
# ยันต์ aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
# MACs hmac-md5,hmac-sha1,[email protected]
#เอสเคปชาร์~
#อุโมงค์หมายเลข
# TunnelDevice ใด ๆ: ใด ๆ
# ใบอนุญาตท้องถิ่นหมายเลขคำสั่ง
# VisualHostKey หมายเลข
# ProxyCommand ssh -q -W %h:%p gateway.example.com
# RekeyLimit 1G 1 ชม
    SendEnv LANG LC_*
    HashKnownHosts ใช่
    การตรวจสอบ GSSAPIA ใช่
    ServerAliveInterval 300

บนเซิร์ฟเวอร์ควบคุม ฉันใช้ sshd_config ต่อไปนี้:

# $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj ประสบการณ์ $

# นี่คือไฟล์การกำหนดค่าทั้งระบบของเซิร์ฟเวอร์ sshd ดู
# sshd_config(5) สำหรับข้อมูลเพิ่มเติม

# sshd นี้รวบรวมด้วย PATH=/usr/bin:/bin:/usr/sbin:/sbin

# กลยุทธ์ที่ใช้สำหรับตัวเลือกในค่าเริ่มต้น sshd_config ที่มาพร้อมกับ
# OpenSSH คือการระบุตัวเลือกด้วยค่าเริ่มต้นโดยที่
# เป็นไปได้ แต่ปล่อยให้พวกเขาแสดงความคิดเห็น ตัวเลือกที่ไม่มีข้อคิดเห็นจะแทนที่
#ค่าเริ่มต้น

พอร์ต --ซ่อน--
#AddressFamily ใด ๆ
#ฟังที่อยู่ 0.0.0.0
#ฟังที่อยู่ ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# ยันต์และกุญแจ
#RekeyLimit ไม่มีค่าเริ่มต้น

#บันทึก
#SyslogFacility AUTH
ข้อมูล #LogLevel

# การรับรองความถูกต้อง:

#LoginGraceTime 2 ม
#StrictModes ใช่
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication ใช่

# คาดว่า .ssh/authorized_keys2 จะถูกละเว้นโดยค่าเริ่มต้นในอนาคต
#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsไม่มีไฟล์

#AuthorizedKeysไม่มีคำสั่ง
#AuthorizedKeysCommandUser ไม่มีใคร

# เพื่อให้ใช้งานได้ คุณจะต้องมีคีย์โฮสต์ใน /etc/ssh/ssh_known_hosts
#HostbasedAuthentication เลขที่
# เปลี่ยนเป็น ใช่ หากคุณไม่เชื่อถือ ~/.ssh/known_hosts for
# การรับรองความถูกต้องตามโฮสต์
#IgnoreUserKnownHosts หมายเลข
# อย่าอ่านไฟล์ ~/.rhosts และ ~/.shosts ของผู้ใช้
#IgnoreRhosts ใช่

# หากต้องการปิดใช้งานรหัสผ่านข้อความธรรมดาแบบ Tunneled ให้เปลี่ยนเป็นไม่ที่นี่!
#PermitEmptyPasswords เลขที่

# เปลี่ยนเป็นใช่เพื่อเปิดใช้งานรหัสผ่านตอบกลับการท้าทาย (ระวังปัญหาเกี่ยวกับ
# โมดูลและเธรด PAM บางรายการ)
ChallengeResponseAuthentication เลขที่

# ตัวเลือก Kerberos
#KerberosAuthentication เลขที่
#KerberosOrLocalPasswd ใช่
#KerberosTicketCleanup ใช่
#KerberosGetAFSToken หมายเลข

# ตัวเลือก GSSAPI
#GSSAPIAuthentication เลขที่
#GSSAPICleanupCredentials ใช่
#GSSAPIStrictAcceptorตรวจสอบว่าใช่
#GSSAPIKeyExchange หมายเลข

# ตั้งค่านี้เป็น 'ใช่' เพื่อเปิดใช้งานการตรวจสอบ PAM การประมวลผลบัญชี
# และการประมวลผลเซสชัน หากเปิดใช้งาน การรับรองความถูกต้องของ PAM จะ
# ได้รับอนุญาตผ่าน ChallengeResponseAuthentication และ
# การตรวจสอบ PAM ผ่าน ChallengeResponseAuthentication อาจเลี่ยงผ่าน
# หากคุณต้องการให้บัญชี PAM และการตรวจสอบเซสชันทำงานโดยไม่ต้องใช้
# และ ChallengeResponseAuthentication เป็น 'ไม่'
ใช้ PAM ใช่

#AllowAgentForwarding ใช่
AllowTcpForwarding ใช่
GatewayPort ใช่
X11การส่งต่อใช่
#X11DisplayOffset 10
#X11UseLocalhost ใช่
#PermitTTY ใช่
เลขที่พิมพ์
#PrintLastLog ใช่
#TCPKeepAlive ใช่
#ใบอนุญาตผู้ใช้สิ่งแวดล้อม เลขที่
#การบีบอัดล่าช้า
ClientAliveInterval 30
ClientAliveCountสูงสุด 99999
#ใช้หมายเลข DNS
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#อุโมงค์อนุญาตหมายเลข
#ChrootDirectory ไม่มี
#เวอร์ชันภาคผนวกไม่มี

# ไม่มีเส้นทางแบนเนอร์เริ่มต้น
#ไม่มีแบนเนอร์

# อนุญาตให้ไคลเอนต์ส่งผ่านตัวแปรสภาพแวดล้อมของสถานที่
ยอมรับEnv LANG LC_*

# ลบล้างค่าเริ่มต้นที่ไม่มีระบบย่อย
ระบบย่อย sftp /usr/lib/openssh/sftp-server

# ตัวอย่างของการตั้งค่าที่ลบล้างในแต่ละผู้ใช้
#Match ผู้ใช้ anoncvs
#X11หมายเลขการส่งต่อ
# AllowTcpForwarding เลขที่
#ใบอนุญาตTTYเลขที่
# เซิร์ฟเวอร์ ForceCommand cvs

เลขที่ยืนยันรหัสผ่าน
PermitRootLogin ใช่

โดยทั่วไปฉันคาดหวังให้เซิร์ฟเวอร์เปิดการเชื่อมต่อไว้เนื่องจากทั้งสองฝั่งมีการตั้งค่าการหมดเวลาเพียงพอ อย่างไรก็ตามการเชื่อมต่อแบบสุ่มลดลงเรื่อย ๆ ฉันตรวจสอบแล้ว /var/log/syslog และดูเหมือนว่า sshd สุ่มลดหนึ่งในการเชื่อมต่อที่ใช้งานอยู่เมื่อมีการเชื่อมต่อใหม่เข้ามา ดังนั้นฉันค่อนข้างแน่ใจว่าฉันถึงขีดจำกัดการเชื่อมต่อบางอย่างที่นี่:

26 พ.ย. 18:38:38 v2202102140578142103 systemd[1]: session-115234.scope: สำเร็จ
26 พฤศจิกายน 18:38:38 v2202102140578142103 systemd[1]: เริ่มเซสชัน 115376 ของบริการผู้ใช้
26 พ.ย. 18:38:47 น. v2202102140578142103 systemd[1]: session-115235.scope: สำเร็จ
26 พฤศจิกายน 18:38:47 v2202102140578142103 systemd[1]: เริ่มเซสชัน 115377 ของบริการผู้ใช้
26 พ.ย. 18:38:52 v2202102140578142103 systemd[1]: session-115236.scope: สำเร็จ
26 พฤศจิกายน 18:38:53 v2202102140578142103 systemd[1]: เริ่มเซสชัน 115378 ของบริการผู้ใช้
26 พ.ย. 18:39:08 น. v2202102140578142103 systemd[1]: session-115237.scope: สำเร็จ
26 พฤศจิกายน 18:39:08 v2202102140578142103 systemd[1]: เริ่มเซสชัน 115379 ของบริการผู้ใช้
26 พ.ย. 18:39:08 น. v2202102140578142103 systemd[1]: session-115238.scope: สำเร็จ
26 พฤศจิกายน 18:39:08 v2202102140578142103 systemd[1]: เริ่มเซสชัน 115380 ของบริการผู้ใช้
26 พ.ย. 18:39:09 น. v2202102140578142103 systemd[1]: session-115239.scope: สำเร็จ
26 พฤศจิกายน 18:39:09 v2202102140578142103 systemd[1]: เริ่มเซสชัน 115381 ของบริการผู้ใช้
26 พ.ย. 18:39:14 v2202102140578142103 systemd[1]: session-115240.scope: สำเร็จ
26 พฤศจิกายน 18:39:15 v2202102140578142103 systemd[1]: เริ่มเซสชัน 115382 ของบริการผู้ใช้
26 พ.ย. 18:39:31 v2202102140578142103 systemd[1]: session-115241.scope: สำเร็จ
26 พ.ย. 18:39:31 v2202102140578142103 systemd[1]: session-115242.scope: สำเร็จ
26 พ.ย. 18:39:31 v2202102140578142103 systemd[1]: เริ่มเซสชัน 115383 ของบริการผู้ใช้
26 พ.ย. 18:39:31 v2202102140578142103 systemd[1]: เริ่มเซสชัน 115384 ของบริการผู้ใช้
26 พ.ย. 18:39:32 v2202102140578142103 systemd[1]: session-115243.scope: สำเร็จ
26 พ.ย. 18:39:33 v2202102140578142103 systemd[1]: เริ่มเซสชัน 115385 ของบริการผู้ใช้

อาจเป็นสิ่งที่แก้ไขได้ง่ายสุด ๆ แต่ฉันไม่ใช่ผู้เชี่ยวชาญระบบเครือข่าย linux และฉันไม่สามารถค้นหาสิ่งที่มีประโยชน์ได้จากการค้นคว้าด้วยตัวเอง ดังนั้นหวังว่าจะมีใครบางคนสามารถชี้ให้ฉันเห็นถึงขีดจำกัดที่ฉันต้องเปลี่ยนแปลงเพื่อให้พฤติกรรมนี้หยุดลงได้

ขอบคุณล่วงหน้า!