สิทธิ์การเขียนของผู้ใช้ SFTP Chrooted

ฉันมีการตั้งค่าด้วยผู้ใช้ sftp เท่านั้น:

Match Group sftponly
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no

ฉันได้รับข้อความต่อไปนี้ใน secure.log ของฉัน:

fatal: bad ownership or modes for chroot directory

ด้วยคีย์เวิร์ดการจับคู่มีบางสิ่งที่เกี่ยวกับความปลอดภัยมาด้วย ... ไดเรกทอรีจะต้องเป็นของ root และไดเรกทอรีจะต้องเป็น chmod 755 (drwxr-xr-x) ดังนั้นจึงเป็นไปไม่ได้ที่ผู้ใช้จะมีสิทธิ์ในการเขียนไปยังโฟลเดอร์ถ้ามันสามารถเขียนได้เฉพาะผู้ใช้ root และตั้งค่าเป็นกลุ่มที่ไม่สามารถเขียนได้สำหรับกลุ่มเนื่องจากความปลอดภัยของ ssh

มีคนรู้เกี่ยวกับการทำงานที่ดี?

ฉันมีการตั้งค่าเดียวกันบนเซิร์ฟเวอร์ของเรา เราใช้การกำหนดค่า SSHD เดียวกัน โฮมไดเร็กตอรี่ของผู้ใช้เป็นเจ้าของโดยรูทและภายในมีโฟลเดอร์documentsและpublic_htmlเป็นของผู้ใช้ที่เกี่ยวข้อง จากนั้นผู้ใช้เข้าสู่ระบบโดยใช้ SFTP และเขียนลงในโฟลเดอร์เหล่านั้น (ไม่ใช่โดยตรงที่บ้าน) เนื่องจาก SSH ไม่ได้รับอนุญาตสำหรับพวกเขาจึงทำงานได้อย่างสมบูรณ์แบบ คุณสามารถปรับได้ว่าจะสร้างไดเรกทอรีใดสำหรับผู้ใช้ใหม่ใน / etc / skel / (อย่างน้อยใน openSUSE ฉันไม่คุ้นเคยกับ distros อื่น ๆ )

ความเป็นไปได้อีกอย่างก็คือACL ( เอกสาร openSUSE ) - มันสามารถเพิ่มสิทธิ์การเขียนสำหรับผู้ใช้ตามลำดับสำหรับโฮมไดเร็กตอรี่ของเขา

เราพบวิธีแก้ไขปัญหาเมื่อเร็ว ๆ นี้ซึ่งมีลักษณะเช่นนี้:

/ etc / SSH / sshd_config:

...

Subsystem sftp internal-sftp

Match Group sftponly
    ChrootDirectory /home
    AllowTCPForwarding no
    X11Forwarding no
    ForceCommand internal-sftp

สิทธิ์ไดเรกทอรี:

root@server:~ # chown root:root /home
root@server:~ # chmod 111 /home
root@server:~ # chmod 700 /home/*

ตอนนี้/homeตอบสนองความต้องการสำหรับการChrootDirectoryและไม่สามารถจดทะเบียนโดยผู้ใช้ที่ จำกัด แต่sftponlyผู้ใช้จะไม่สามารถเข้าสู่ระบบถ้าไดเรกทอรีบ้านของพวกเขามีการตั้งค่าได้ตามปกติ ( /home/$LOGNAME): ภายใต้สภาพแวดล้อม chrooted ไดเรกทอรีบ้านของพวกเขาไม่ได้อยู่ภายใน/homeแต่โดยตรงภายใต้ รูต ( /)

วิธีแก้ปัญหา 1

กำหนดที่อยู่อาศัยของผู้ใช้ที่ถูก จำกัด เป็นลักษณะที่ปรากฏภายใต้ chroot:

root@server:~ # usermod -d /username username

คำเตือน 1

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

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

วิธีแก้ปัญหา 2

นี่เป็นทางเลือกแทนอันก่อนหน้านี้ที่เราใช้:

root@server:~ # ln -s . /home/home

นั่นคือการสร้าง symlink ภายใน/homeเพื่อชื่อของตัวเอง ตอนนี้ภายใต้ chroot /home/usernameชี้ไปที่ไดเรกทอรีเดียวกันโดยไม่ต้อง chroot สำหรับผู้ใช้ที่ถูก จำกัด เข้าสู่ระบบด้วย SFTP /usernameมันจะปรากฏเป็น ไดเรกทอรีนี้เขียนได้สำหรับเจ้าของ (ผู้ใช้ที่ จำกัด ) ผู้ใช้ที่ถูก จำกัด ไม่สามารถแสดงรายการพาเรนต์หรือโฮมไดเร็กทอรีของพี่น้องใด ๆ ตามชื่อ

สิ่งเดียวที่พิเศษเกี่ยวกับsftponlyผู้ใช้คือการมีส่วนร่วมในsftponlyกลุ่ม เราพบว่าจัดการได้ง่ายกว่าวิธีแก้ปัญหา 1

ถ้ำ 2

1. คุณไม่สามารถมีชื่อผู้ใช้ 'บ้าน' กับไดเรกทอรีบ้าน /home/home
2. คุณต้องระวังด้วยสคริปต์ที่สำรวจ/homeลำดับชั้นและติดตาม symlinks

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

คุณควรสร้างโครงสร้างไดเรกทอรีต่อไปนี้:

/ home / ผู้ใช้

/ home / user / home / user <- dir จริงที่ผู้ใช้จะสามารถเข้าถึงได้

เลือก:

/home/user/.ssh/authorized_keys <- หากคุณต้องการพิสูจน์ตัวตนด้วยรหัสสาธารณะ

ในการอ้างอิงถึงส่วน 'สิทธิ์ไดเรกทอรี'ในคำตอบจาก @artm (ซึ่งฉันเพิ่งทดสอบ) .. ฉันพบ:

root@server:~ # chmod 111 /home <- Does not work

มันไม่อนุญาตให้การเชื่อมต่อ sftp ทำงานบนอูบุนตูที่มีการอนุญาตเฉพาะทุกอย่างเช่น 111

ฉันพบว่า:

root@server:~ # chmod 555 /home

ทำงานร่วมกับการเชื่อมต่อกับ SFTP ด้วยสิทธิ์ Read และ Execute เช่น 555 ไม่แน่ใจว่า debian กับรสชาติอื่น ๆ นั้นแตกต่างกันหรือไม่ แต่นั่นเป็นสิ่งที่ใช้ได้กับการติดตั้ง Ubuntu ของฉัน

เมื่อคุณสร้างผู้ใช้คุณต้องตั้งค่าความเป็นเจ้าของที่ใช้chownกับทุก dir สำหรับผู้ใช้ทุกคน

ตัวอย่างเช่น:

sudo chown usertest:groupsftp /home/rootsftp/usertest