การรักษาความปลอดภัย SVN + SSH

ฉันใช้ snv + ssh กับการตรวจสอบตามคีย์ ตอนนี้เพื่อให้ผู้ใช้ svn ของฉันสามารถเข้าถึงพื้นที่เก็บข้อมูลผ่านการโค่นล้มฉันต้องตั้งค่าไฟล์ repo ให้สามารถอ่านและเขียนได้บนระบบไฟล์ให้กับผู้ใช้เหล่านั้น

ฉันต้องการป้องกันไม่ให้ผู้ใช้สามารถลบฐานข้อมูล repo เมื่อล็อกอินเข้าสู่เซิร์ฟเวอร์ผ่านทาง ssh แต่ยังสามารถเช็คเอาต์และส่งรหัสได้

คิดว่าฉันจะทำสิ่งนี้ได้อย่างไร

ในการเข้าถึง svn + ssh URL ไคลเอนต์ svn เรียกใช้อินสแตนซ์ svnserve โดยใช้ "ssh -q user @ host svnserve -t" และพูดคุยกับอินสแตนซ์นั้นผ่าน stdin / stdout

หากผู้ใช้ของคุณต้องการการเข้าถึง ssh ปกติคุณยังสามารถป้องกันพวกเขาจากการเข้าถึงพื้นที่เก็บข้อมูลโดย จำกัด การเข้าถึงผู้ใช้หนึ่งคน(chown -R svnserve: svnserve repo; chmod -R g-rwx, o-rwx repo)และแทนที่คำสั่ง svnserve โดย นี้setuid / setgid svnserve เสื้อคลุมโปรแกรม

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

หนังสือการโค่นล้มมีส่วนในการเลือกการกำหนดค่าเซิร์ฟเวอร์ซึ่งอาจช่วย จากส่วนนั้น (เน้นที่เหมือง):

หากคุณมีโครงสร้างพื้นฐานที่มีอยู่ซึ่งยึดตามบัญชี SSH เป็นอย่างมากและหากผู้ใช้ของคุณมีบัญชีระบบบนเครื่องเซิร์ฟเวอร์ของคุณแล้วก็เหมาะสมที่จะปรับใช้โซลูชัน svnserve-over-SSH มิฉะนั้นเราจะไม่แนะนำตัวเลือกนี้สู่สาธารณะอย่างกว้างขวาง โดยทั่วไปถือว่าปลอดภัยกว่าที่จะให้ผู้ใช้ของคุณเข้าถึงที่เก็บข้อมูลผ่านทางบัญชี (จินตภาพ) ที่จัดการโดย svnserve หรือ Apache แทนที่จะเป็นบัญชีระบบที่ถูกพัดเต็ม

ไซต์นี้มีลูกเล่นดีๆ: http://svn.apache.org/repos/asf/subversion/trunk/notes/ssh-tricks

หากไม่มีสิ่งใดที่เหมาะกับคุณอาจเป็นวิธีแก้ปัญหาที่สามารถทำเคล็ดลับได้หรือไม่ คุณสามารถสำรองข้อมูลของที่เก็บข้อมูลได้ทุกครั้งที่มีคนทำอะไรบางอย่างโดยเพิ่มสิ่งนี้ลงใน commit hooks: sudo rsync -a / my / repo / path / my / closed / path /

ฉันเห็นสองทิศทางที่เป็นไปได้ในการโจมตีปัญหานี้:

• ให้เข้าถึงเปลือก จำกัด เช่นผู้ใช้สามารถใช้ SVN กับบัญชีของพวกเขา (อาจจำเป็นต้องมีบัญชีอื่นถ้าเข้าถึงเปลือกยังเป็นสิ่งจำเป็นสำหรับวัตถุประสงค์อื่น ๆ ) - ฉันได้พบไม่กี่ ที่น่าสนใจอ้างอิง googling สำหรับsvnonly หมายเหตุ: ไม่ได้ลองด้วยตนเอง
• โยกย้ายไปยังการโค่นล้มมากกว่า https เพิ่มใบรับรองลูกค้า ฉันเคยเห็นคนพูดถึงเรื่องนี้ แต่ไม่เคยทำเอง ข้อเสีย: ต้องมีการแจกจ่ายใบรับรองไคลเอ็นต์เพิ่มเติมจากคีย์ ssh

ฉันเห็นด้วยกับ Greg และ Olaf - ไปเพื่อการเข้าถึง https ฉันใช้การตั้งค่าดังกล่าวค่อนข้างบางเวลาและไม่เห็นข้อเสียใด ๆ ของมัน

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