การตั้งค่าที่ชวนให้หลงเชื่อคือ AllowTcpForwarding no น่าเสียดายที่มันปิดการส่งต่อที่ พร็อกซี SSH SOCKS ภายในเครื่องต้องการ ด้วย การส่งต่อแบบไดนามิกไม่ใช่ช่องโหว่เพื่อหลีกเลี่ยงนโยบายของเซิร์ฟเวอร์

สำหรับบัญชีเฉพาะ OpenSSH แยกความสามารถหลายอย่างออกจากกัน ส่วนหนึ่งของนโยบายสามารถอนุญาตการส่งต่อภายในเครื่องพร้อมกับป้องกันเซสชัน shell และระบบย่อยได้:

Match User proxyuser
    AllowTcpForwarding local
    MaxSessions 0
    PermitTTY no
    X11Forwarding no
    AllowAgentForwarding no

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

การส่งต่ออย่างเดียวไม่ใช่ SOCKS อย่างเดียว

การส่งต่อภายในเครื่องแบบคงที่และการร้องขอ SOCKS อาจขอการเชื่อมต่อปลายทางชนิดเดียวกันจากเซิร์ฟเวอร์ในที่สุด การอนุญาตการส่งต่อภายในเครื่องไม่ได้ยืนยันว่าไคลเอนต์ใช้อินเทอร์เฟซ SOCKS ที่เจาะจง อย่าอธิบายว่าบัญชีนี้บังคับใช้การใช้เฉพาะ SOCKS

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

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

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

บทความที่เกี่ยวข้อง