MaxSessions, MaxStartups หรือการลงทะเบียนอุปกรณ์: จะเลือกขีดจำกัด SSH แบบไหน

บริการอุโมงค์ที่สัญญาว่าจะให้หนึ่งอุปกรณ์ต่อผู้สมัครใช้บริการหนึ่งรายมักไม่ได้คำสัญญานั้นจาก MaxSessions และการทดสอบครั้งแรกก็มักพิสูจน์เรื่องนี้ ผู้สมัครใช้บริการเปิดโปรเซส ssh ตัวที่สอง เซสชันแรกยังทำงานอยู่ และอุโมงค์ทั้งสองก็ส่งทราฟฟิก ตัวเลือกการกำหนดค่าแต่ละตัวนับสิ่งที่แตกต่างกัน และไม่มีตัวใดนับอุปกรณ์ การตั้งชื่อคำสัญญาก่อนคือสิ่งที่ทำให้การเลือกระหว่างตัวเลือกเหล่านี้ชัดเจน

แต่ละตัวเลือกนับอะไรจริง ๆ

MaxSessions จำกัดจำนวนเซสชันที่เปิดอยู่ซึ่งเชื่อมต่อเครือข่ายที่ยืนยันตัวตนแล้วหนึ่งรายการพาไป เซสชันในที่นี้หมายถึงเชลล์ คำขอ exec ระบบย่อยอย่าง SFTP หรือช่องสัญญาณที่คล้ายกันซึ่งมัลติเพล็กซ์อยู่ในทรานสปอร์ต SSH เดียว การเรียก ssh ครั้งที่สองจะเปิดทรานสปอร์ตที่สอง ยืนยันตัวตนอีกครั้ง และได้โควตาของตัวเอง จำนวนเซสชันของการเชื่อมต่อแรกไม่มีความหมายสำหรับมัน

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

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

จุดที่ MaxSessions เลิกเป็นโควตา

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

การส่งต่อเป็นเรื่องเซอร์ไพรส์แยกต่างหาก การส่งต่อ TCP ไม่ต้องใช้ช่องสัญญาณเซสชัน ดังนั้น MaxSessions 0 สามารถห้ามเชลล์และระบบย่อยได้ในขณะที่ยังอนุญาตอุโมงค์ -L และ -R บริการที่ส่งต่อเท่านั้นและถือจำนวนเซสชันเป็นโควตาอุโมงค์ของตนไม่ได้วัดอะไรเลย พฤติกรรมนั้นมีเอกสารอยู่ในข้อมูลอ้างอิงการกำหนดค่าเซิร์ฟเวอร์ OpenSSH และควรค่าที่จะอ่านก่อนออกแบบโดยอิงชื่อตัวเลือก

ดัมป์การกำหนดค่าที่มีผลจริงแทนไฟล์ที่คุณคิดว่าโหลดอยู่ การรวมเข้าและไดเรกทอรี drop-in มักหมายความว่าค่าที่บังคับใช้ไม่ใช่ค่าที่คุณแก้ไข

MaxStartups ปกป้องเดมอน ไม่ใช่ผู้สมัครใช้บริการ

รูปแบบสามส่วนของ MaxStartups อธิบายว่าการเชื่อมต่อที่ยังไม่ยืนยันตัวตนมีได้กี่รายการก่อนที่เดมอนจะเริ่มทิ้งเปอร์เซ็นต์ของรายการใหม่ รูปแบบเริ่มต้นของมันมีอยู่เพราะการเชื่อมต่อ SSH ที่ยังไม่ยืนยันตัวตนนั้นเปิดถูกและดูแลแพง นั่นคือการควบคุมป้องกันทรัพยากรสำหรับเซิร์ฟเวอร์ และมันมีผลกับทุกคนพร้อมกัน

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

เมื่อการเข้าสู่ระบบถูกปฏิเสธเป็นระลอก ให้ดูในบันทึกของเดมอนที่ข้อความก่อนการยืนยันตัวตนก่อนแตะตัวเลือกใด ๆ ข้อความระบุว่ามาตรการใดทำงาน และมาตรการเหล่านี้ไม่สามารถใช้แทนกันได้

สล็อตต่อผู้ใช้ต้องใช้สถานะร่วม

นโยบายหนึ่งทรานสปอร์ตที่ใช้งานจริงต้องมีการจองที่เก็บไว้ที่ใดที่หนึ่งนอก sshd ขั้นตอนการรับเข้าต้องจองสล็อตของบัญชีอย่างเป็นอะตอม ปล่อยเมื่อการเชื่อมต่อปิด ให้หมดอายุเมื่อไคลเอนต์หายไปโดยไม่ปิด และตัดสินว่าความพยายามใหม่จะถูกปฏิเสธหรือแทนที่อันเก่า การตัดสินใจสุดท้ายนั้นเป็นการตัดสินใจของผลิตภัณฑ์ ไม่ใช่รายละเอียดทางเทคนิค เพราะการแทนที่อุโมงค์ที่ใช้งานอยู่จะตัดการเชื่อมต่อของใครบางคน

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

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

ทดสอบนโยบายด้วยการเชื่อมต่อจริงสองรายการ

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

อ่านขีดจำกัดที่มีผลก่อน แล้วจึงเปิดการเชื่อมต่อที่นโยบายควรปฏิเสธ ทั้งสองครึ่งของการทดสอบนั้นสำคัญ และไม่มีครึ่งใดแทนอีกครึ่งได้

sshd -T | grep -iE "maxsessions|maxstartups|allowtcpforwarding|permitopen"
ss -tn state established '( sport = :22 )' | head
ssh -N -L 8080:127.0.0.1:80 [email protected]

เรียกใช้คำสั่งอุโมงค์สองครั้งในสองเทอร์มินัลและนับการเชื่อมต่อที่สร้างขึ้นบนพอร์ต 22 หากทั้งสองส่งทราฟฟิกในขณะที่นโยบายของคุณอ้างว่ามีทรานสปอร์ตที่ใช้งานอยู่หนึ่งรายการ นโยบายนั้นเป็นเอกสารไม่ใช่การบังคับใช้ แก้ไขช่องว่างนั้นในชั้นการรับเข้า ไม่ใช่ด้วยการลด MaxSessions แล้วหวังว่าทรานสปอร์ตที่สองจะสังเกตเห็น