วิธีจำกัดสิทธิ์การเข้าถึง SSH ให้กับผู้ใช้เฉพาะในไดเร็กทอรีที่กำหนดบน Ubuntu 24.04 (คู่มือ SFTP Chroot)

การให้สิทธิ์ผู้รับเหมาในการอัปโหลดไฟล์เพียงไม่กี่ไฟล์ ไม่ได้หมายความว่าบุคคลนั้นจะได้รับสิทธิ์ในการเข้าถึงเทอร์มินัลและมองเห็นภาพรวมของเซิร์ฟเวอร์ทั้งหมดโดยอัตโนมัติ ใน Ubuntu 24.04 LTS นั้น OpenSSH สามารถจำกัดสิทธิ์บัญชีการถ่ายโอนไฟล์ให้อยู่ในไดเร็กทอรีที่เลือกได้โดยใช้ChrootDirectoryกฎและเซิร์ฟเวอร์ในตัวinternal-sftpข้อแตกต่างที่สำคัญคือ นี่เป็นการจำกัดเฉพาะ SFTP เท่านั้นไม่ใช่วิธีง่ายๆ ในการให้ Bash shell ที่ใช้งานได้เต็มรูปแบบแต่ถูกจำกัดสิทธิ์ไว้

คู่มือนี้จะอธิบายว่าการตั้งค่าต่างๆ นั้นปกป้องอะไรบ้าง จากนั้นจะแนะนำขั้นตอนการตั้งค่าแบบย้อนกลับได้ 8 ขั้นตอน สำหรับหลายบัญชี โดยแต่ละบัญชีจะมีไดเร็กทอรีเป็นของตัวเอง คำสั่งต่างๆ ใช้บัญชีตัวอย่างชื่อcontractorและโฮสต์ตัวอย่างชื่อserver.example.com; โปรดแทนที่ด้วยค่าของคุณเอง นี่เป็นเพียงตัวอย่างการกำหนดค่า ไม่ใช่ผลลัพธ์ที่ได้จากการทดสอบบนเซิร์ฟเวอร์จริง

คุณต้องการข้อจำกัดประเภทใดกันแน่?

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

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

เอกสาร OpenSSH ChrootDirectoryระบุMatchถึงเรื่องนี้ไว้ForceCommandในคู่มือ sshd_config อย่างเป็นทางการของ Ubuntu 24.04

ตั้งค่าระบบจำกัดการเข้าถึงเฉพาะ SFTP ใน 8 ขั้นตอน

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

1. ตรวจสอบ OpenSSH และเก็บเซสชันการกู้คืนไว้

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

sudo apt update
sudo apt install openssh-server
sudo systemctl status ssh
sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.pre-sftp

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

2. สร้างผู้ใช้เฉพาะและกลุ่มการเข้าถึง SFTP

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

sudo groupadd sftpclients
sudo adduser --home /upload --no-create-home --shell /usr/sbin/nologin contractor
sudo usermod -aG sftpclients contractor
id contractor

ขั้นตอน การadduserทำงานอาจขอให้คุณกำหนดรหัสผ่าน ในการติดตั้งที่ปิดใช้งานการตรวจสอบสิทธิ์ด้วยรหัสผ่าน SSH ให้สร้างและอนุญาตคีย์สาธารณะแทน อย่าเปิดใช้งานการเข้าสู่ระบบด้วยรหัสผ่านทั่วโลกเพียงเพื่อเป็นตัวอย่างnologinเชลล์เป็นมาตรการป้องกันอีกอย่างหนึ่ง แต่internal-sftpคำสั่งที่บังคับใช้คือสิ่งที่ทำให้การกำหนดค่านี้เป็นการถ่ายโอนข้อมูลเท่านั้น ทดสอบการผสมผสานนี้กับระบบการตรวจสอบสิทธิ์ของคุณเอง

3. สร้างไดเร็กทอรี chroot ที่เป็นของ root

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

sudo install -d -o root -g root -m 0755 /srv/sftp
sudo install -d -o root -g root -m 0755 /srv/sftp/contractor
namei -l /srv/sftp/contractor

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

4. เพิ่มไดเร็กทอรีย่อยที่สามารถเขียนได้ภายในเจลลี่

บัญชีผู้ใช้นี้สามารถเขียนลงในไดเร็กทอรีย่อยได้โดยไม่ต้องได้รับอนุญาตให้แก้ไขไดเร็กทอรีรากของ chroot สร้างไดเร็กทอรี/srv/sftp/contractor/uploadสำหรับไฟล์จริงของบัญชีผู้ใช้ จากภายใน SFTP จะปรากฏเป็น/upload.

sudo install -d -o contractor -g contractor -m 0750 /srv/sftp/contractor/upload
sudo stat -c '%U:%G %a %n' /srv/sftp/contractor /srv/sftp/contractor/upload

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

5. เพิ่มกฎการจับคู่ (Match rule) ลงในไฟล์ sshd_config

เปิดไฟล์/etc/ssh/sshd_configและเพิ่มบล็อกต่อไปนี้ต่อท้าย หลังจากคำสั่งและMatchบล็อกที่มีอยู่แล้ว ใช้โปรแกรมแก้ไขข้อความ เช่นsudoeditหรือsudo nanoตรวจสอบMatchกฎที่มีอยู่ก่อน: หากมีบล็อกที่ตรงกันหลายบล็อกที่กำหนดคำหลักเดียวกัน OpenSSH จะใช้ตัวอย่างที่ตรงกันตัวแรก Ubuntu ยังประมวลผลไฟล์ภายใต้/etc/ssh/sshd_config.d/จากไฟล์ก่อนหน้าIncludeกฎในนั้นอาจส่งผลต่อลำดับความสำคัญ

Match Group sftpclients
    ChrootDirectory /srv/sftp/%u
    ForceCommand internal-sftp -d /upload
    PermitTTY no
    DisableForwarding yes

Match Groupกำหนดเป้าหมายไปยังสมาชิกของsftpclients. ChrootDirectoryจัดให้ผู้ใช้แต่ละรายอยู่ภายใต้/srv/sftp/USERNAME. ForceCommand internal-sftp -d /uploadเรียกใช้บริการ SFTP ในกระบวนการและเริ่มต้นภายในไดเร็กทอรีที่เขียนได้PermitTTY noป้องกันการจัดสรรเทอร์มินัล ในขณะที่DisableForwarding yesปิดใช้งานคุณสมบัติการส่งต่อ SSH สำหรับการเชื่อมต่อที่ตรงกัน

ให้คงคำสั่ง global Subsystem sftpที่ Ubuntu กำหนดไว้แล้ว เว้นแต่คุณจะมีเหตุผลอื่นที่ต้องเปลี่ยนแปลง คำสั่ง SFTP ภายในที่บังคับใช้ไม่จำเป็นต้องแทนที่บรรทัด global นั้น อย่าเพิ่ม global เพิ่มเติมMatch Allเพียงเพื่อปิดบล็อกโดยไม่เข้าใจว่ามันจะส่งผลกระทบอย่างไร

6. ตรวจสอบไวยากรณ์และการตั้งค่าที่ใช้งานได้ก่อนโหลดใหม่

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

sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T -C user=contractor,host=localhost,addr=192.0.2.10 | grep -E '^(chrootdirectory|forcecommand|permittty|disableforwarding) '
namei -l /srv/sftp/contractor

การกำหนดค่าที่มีประสิทธิภาพควรระบุเส้นทาง chroot ที่ต้องการ คำสั่ง SFTP ที่บังคับใช้ การจัดสรร TTY ที่ปิดใช้งาน และข้อจำกัดการส่งต่อ ที่อยู่ตัวอย่างนี้192.0.2.10ใช้สำหรับประกอบเอกสารเท่านั้น หากคุณมีMatchกฎที่ขึ้นอยู่กับที่อยู่ ให้แทนที่ด้วยที่อยู่ต้นทางของไคลเอ็นต์จริง-T -Cรูปแบบนี้มีเอกสารอยู่ใน คู่มือ sshd ของ Ubuntu 24.04

หากการตรวจสอบความถูกต้องล้มเหลว ให้แก้ไขการตั้งค่าก่อนที่จะโหลด SSH ใหม่ หากค่าที่ได้ไม่ตรงกับที่คาดไว้ ให้ตรวจสอบส่วนของโค้ดที่รวมอยู่และลำดับของบล็อกเงื่อนไขที่มีอยู่ ไม่ใช่แค่บรรทัดสุดท้ายที่คุณแก้ไขเท่านั้น

7. รีโหลด SSH และรักษาการเข้าถึงในฐานะผู้ดูแลระบบไว้

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

sudo systemctl reload ssh
sudo systemctl status ssh --no-pager

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

8. ทดสอบการอนุญาตการถ่ายโอนข้อมูลและการบล็อกการเข้าถึงเชลล์

จากคอมพิวเตอร์เครื่องอื่น ให้เชื่อมต่อในฐานะผู้ใช้ที่มีสิทธิ์จำกัด ใช้ชื่อโฮสต์จริงของเซิร์ฟเวอร์และไฟล์ทดสอบที่เหมาะสม ไดเร็กทอรี SFTP แรกควรเป็น/uploadและรูท chroot ควรปรากฏเป็น แทนที่จะเป็นพา ธ/ของโฮสต์/srv/sftp/contractor

sftp contractor@server.example.com
sftp> pwd
sftp> cd /
sftp> ls
sftp> cd /upload
sftp> put sample.txt
sftp> cd /etc
sftp> exit

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

ssh contractor@server.example.com

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

แล้วถ้าใช้คีย์สาธารณะ SSH ล่ะ?

การตรวจสอบสิทธิ์ด้วยคีย์สาธารณะใช้งานได้กับ SFTP jail แต่การวางโฮมระดับโฮสต์ของผู้ใช้ไว้ที่/uploadตำแหน่งนั้นหมายความว่า~/.ssh/authorized_keysเส้นทางเริ่มต้นอาจไม่มีอยู่ภายนอก jail ทางเลือกที่ใช้งานได้จริงคือการอนุญาตให้ SSH อ่านไฟล์คีย์ที่ควบคุมโดย root ก่อนที่จะเริ่ม chroot เพิ่มโค้ดนี้ไว้ในMatch Group sftpclientsบล็อกเดียวกันหากคุณเลือกใช้การจัดเก็บคีย์แบบรวมศูนย์:

    AuthorizedKeysFile /etc/ssh/authorized_keys/%u

จากนั้นสร้าง/etc/ssh/authorized_keys/contractorไฟล์ที่มีคีย์สาธารณะที่ได้รับอนุญาตของผู้รับเหมา โดยมีสิทธิ์การเป็นเจ้าของระดับรูท และไม่มีสิทธิ์การเขียนสำหรับกลุ่มหรือบุคคลทั่วไป ตัวอย่างเช่น หลังจากคัดลอกไฟล์คีย์สาธารณะที่ตรวจสอบแล้วอย่างปลอดภัยไปcontractor.pubยังไดเร็กทอรีจัดเตรียมสำหรับการดูแลระบบ:

sudo install -d -o root -g root -m 0755 /etc/ssh/authorized_keys
sudo install -o root -g root -m 0644 contractor.pub /etc/ssh/authorized_keys/contractor
sudo /usr/sbin/sshd -t

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

ข้อผิดพลาดทั่วไปและความหมายของข้อผิดพลาดเหล่านั้น

ตรวจสอบบันทึกด้วย คำสั่ง sudo journalctl -u ssh -n 80 --no-pager`scp` ข้อผิดพลาดที่เกิดขึ้นจะขึ้นอยู่กับการตั้งค่า PAM การกำหนดค่า SSH การเข้าถึงระบบไฟล์ และวิธีการตรวจสอบสิทธิ์ OpenSSH 9.0 และเวอร์ชันใหม่กว่าใช้ SFTP สำหรับscpการถ่ายโอนมาตรฐานเป็นค่าเริ่มต้น ในขณะที่โหมดดั้งเดิมต้องการเชลล์ ดังที่อธิบายไว้ในคู่มือ scp ของ Ubuntu 24.04

คุณสามารถจำกัดการใช้งาน SSH shell แบบโต้ตอบให้ใช้งานได้เฉพาะในโฟลเดอร์เดียวได้หรือไม่?

ไม่ใช่ด้วยการเปลี่ยนไดเร็กทอรีโฮมหรือตัวอย่าง SFTP เพียงอย่างเดียวข้างต้น OpenSSH ChrootDirectoryสามารถใช้สำหรับเซสชันเชลล์ได้เช่นกัน แต่สภาพแวดล้อมนั้นต้องมีเชลล์ที่ใช้งานได้ ไลบรารีที่ใช้ร่วมกัน และโหนดอุปกรณ์ที่จำเป็น รวมถึงการพึ่งพาคำสั่งใดๆ การสร้างสภาพแวดล้อมนั้นอย่างปลอดภัยต้องใช้มากกว่าการตั้งค่าเพียงบรรทัดเดียวในไฟล์sshd_config.php การสร้างการตั้งค่าที่เปราะบางหรือทำให้เข้าใจผิดนั้นทำได้ง่าย โดยเฉพาะอย่างยิ่งเมื่อเกี่ยวข้องกับคำสั่งเชลล์หรือการเมานต์ที่ไม่แน่นอน

หากผู้ใช้ต้องการคำสั่งแบบโต้ตอบจริงๆ ก่อนอื่นให้ระบุคำสั่งและไฟล์ที่ต้องการอย่างชัดเจน สำหรับชุดคำสั่งขนาดเล็ก ให้ใช้คำสั่งระยะไกลที่มีขอบเขตจำกัด หรือปลายทางแอปพลิเคชันเฉพาะ สำหรับสภาพแวดล้อมอิสระที่กว้างขึ้น ให้พิจารณาใช้คอนเทนเนอร์หรือเครื่องเสมือนที่มีการเมานต์ระบบไฟล์ การควบคุมสิทธิ์ และข้อจำกัดเครือข่ายอย่างชัดเจน การใช้ chroot เพียงอย่างเดียวไม่สามารถทดแทนการแยกส่วนระบบอย่างสมบูรณ์ได้ และทั้ง chroot และสิทธิ์การเข้าถึงไฟล์ของ Unix ก็ไม่สามารถป้องกันผู้ใช้ที่มีสิทธิ์พิเศษที่สามารถเปลี่ยนแปลงระบบพื้นฐานได้

รายการตรวจสอบด้านความปลอดภัยก่อนอนุญาตให้เข้าถึง

• บัญชีโอนเงินไม่ใช่บัญชีผู้ดูแลระบบ และเป็นของกลุ่มที่จำเป็นเท่านั้น
• ส่วนประกอบแต่ละส่วนที่นำไปสู่ระบบรักษาความปลอดภัยนั้นเป็นกรรมสิทธิ์ของ root และไม่สามารถเขียนทับได้โดยกลุ่มหรือบุคคลทั่วไป
• ตำแหน่งที่สามารถเขียนข้อมูลเพื่ออัปโหลดได้นั้นอยู่ภายในระบบรักษาความปลอดภัย (jail) ไม่ใช่ที่รูทของระบบรักษาความปลอดภัย (jail root)
• ผู้ใช้เป้าหมายตรงกับChrootDirectory, ForceCommand internal-sftp, และได้ปิดใช้งานการส่งต่อในการตั้งค่าที่มีผลบังคับใช้แล้ว
• การอัปโหลดผ่าน SFTP สำเร็จ แต่ความพยายามในการเข้าถึงไฟล์เฉพาะโฮสต์ล้มเหลว และการเข้าถึงเชลล์ SSH ปกติถูกบล็อก
• การสำรองข้อมูล การเก็บรักษา โควต้า การตรวจสอบ และการเพิกถอนบัญชี จะถูกจัดการแยกต่างหาก โดยระบบจำกัดการเข้าถึงไดเร็กทอรี (Directory Jail) จะไม่นำนโยบายเหล่านี้ไปใช้โดยอัตโนมัติ

สำหรับรายละเอียดทางเทคนิคเพิ่มเติม โปรดศึกษาเอกสารอ้างอิงการกำหนดค่า OpenSSH ของ Ubuntu 24.04และคู่มือเซิร์ฟเวอร์ SFTP ของ Ubuntuคำแนะนำเหล่านี้มีเป้าหมายสำหรับ Ubuntu 24.04 LTS การสร้างแพ็กเกจและโค้ด SSH ที่มีอยู่แล้วอาจเปลี่ยนแปลงพฤติกรรมที่แท้จริง ดังนั้นการกำหนดค่าและการทดสอบการเชื่อมต่อจริงบนเครื่องของคุณเองจึงเป็นสิ่งที่ถูกต้องที่สุด