sysadmins Linux หลายตัวทำงานเป็นรูต

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

คีย์สาธารณะ SSH ของทุกคนจะถูกใส่ใน ~ root / .ssh / authorized_keys2

• ข้อได้เปรียบ: ใช้งานง่ายการส่งต่อตัวแทน SSH ทำงานได้ง่ายค่าใช้จ่ายเล็กน้อย
• ข้อเสีย: การตรวจสอบที่ขาดหายไป (คุณไม่เคยรู้เลยว่า "ราก" ใดทำการเปลี่ยนแปลง) อุบัติเหตุมีแนวโน้มมากขึ้น

ใช้บัญชีส่วนตัวและsudo

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

• ข้อได้เปรียบ: การตรวจสอบที่ดีsudoทำให้เราไม่สามารถทำสิ่งที่งี่เง่าได้ง่ายเกินไป
• ข้อเสีย: ตัวแบ่งการส่งต่อตัวแทน SSH มันเป็นเรื่องยุ่งยากเพราะแทบจะทุกสิ่งสามารถทำได้โดยไม่ต้องรูท

ใช้ผู้ใช้ UID 0 หลายคน

นี่เป็นข้อเสนอที่ไม่เหมือนใครจากหนึ่งใน sysadmins เขาแนะนำให้สร้างผู้ใช้สามคนใน / etc / passwd ทั้งหมดมี UID 0 แต่ชื่อเข้าสู่ระบบที่แตกต่างกัน เขาอ้างว่าสิ่งนี้ไม่ได้ถูกห้ามจริงและอนุญาตให้ทุกคนเป็น UID 0 แต่ยังสามารถตรวจสอบได้

• ข้อได้เปรียบ: งานการส่งต่อตัวแทน SSH การตรวจสอบอาจทำงานได้ (ไม่ได้ทดสอบ) ไม่ยุ่งยากsudo
• ข้อเสีย: รู้สึกสกปรกสวย - หาเอกสารไม่พบในที่ที่อนุญาต

คุณจะแนะนำอะไร

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

การส่งต่อเอเจนต์แตกหักอย่างไร

นอกจากนี้หากเป็นเรื่องยุ่งยากที่จะใช้sudoหน้างานทุกงานคุณสามารถเรียกใช้ sudo shell ด้วยsudo -sหรือเปลี่ยนเป็นรูทเชลล์ด้วยsudo su -

สำหรับกลยุทธ์ที่แนะนำครั้งที่ 3 นอกเหนือจากการตรวจสอบuseradd -o -u userXXXตัวเลือกตามที่ @jlliagre แนะนำฉันไม่คุ้นเคยกับการเรียกใช้ผู้ใช้หลายคนพร้อมกันกับ uid เดียวกัน (ดังนั้นหากคุณดำเนินการต่อไปฉันจะสนใจถ้าคุณสามารถอัปเดตโพสต์ด้วยปัญหาใด ๆ (หรือความสำเร็จ) ที่เกิดขึ้น ... )

ฉันเดาว่าการสังเกตครั้งแรกของฉันเกี่ยวกับตัวเลือกแรก "คีย์สาธารณะ SSH ของทุกคนจะถูกใส่ไว้ใน ~ root / .ssh / authorized_keys2" นั่นคือถ้าคุณไม่เคยทำงานในระบบอื่นใดเลย

1. อย่างน้อยก็คุณจะต้องทำงานกับบัญชีผู้ใช้และsudo

ข้อสังเกตที่สองคือถ้าคุณทำงานบนระบบที่ต้องการ HIPAA, PCI-DSS หรือสิ่งอื่น ๆ เช่น CAPP และ EAL คุณจะต้องแก้ไขปัญหาของ sudo เพราะ;

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

ดังนั้น; ใช้บัญชีส่วนตัวและ sudo

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

ดังนั้นฉันสามารถส่งต่อเทคนิคบางอย่างที่ฉันใช้เพื่อแก้ไขสิ่งsudoที่คุณพูดถึง ปัญหาแรกคือหากการเข้าสู่ระบบรูทถูกบล็อกโดยใช้PermitRootLogin=noหรือคุณไม่มีรูทโดยใช้คีย์ ssh มันจะทำให้ไฟล์ของ PITA เป็นไฟล์ SCP

ปัญหาที่ 1 : คุณต้องการ scp ไฟล์จากด้านระยะไกล แต่พวกเขาต้องการการเข้าถึงราก แต่คุณไม่สามารถเข้าสู่กล่องระยะไกลในฐานะที่เป็นรากโดยตรง

Boring Solution : คัดลอกไฟล์ไปยังโฮมไดเร็กตอรี่, chown และ scp down

ssh userXXX@remotesystem, sudo su -etc, cp /etc/somefilesถึง/home/userXXX/somefiles, chown -R userXXX /home/userXXX/somefilesใช้ scp เพื่อดึงไฟล์จากระยะไกล

น่าเบื่อมากอย่างแน่นอน

Less Boring Solution : sftp รองรับการ-s sftp_serverตั้งค่าสถานะดังนั้นคุณสามารถทำสิ่งต่อไปนี้ (ถ้าคุณกำหนดค่า sudo โดยใช้รหัสผ่านน้อยกว่า /etc/sudoers);

sftp  -s '/usr/bin/sudo /usr/libexec/openssh/sftp-server' \
userXXX@remotehost:/etc/resolv.conf 

(คุณสามารถใช้การแฮ็กนี้กับ sshfs ได้ แต่ฉันไม่แน่ใจว่ามันแนะนำ ... ;-)

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

วิธีการส่งต่อพอร์ตนินจา :

ล็อกอินเข้าสู่รีโมตโฮสต์ แต่ระบุว่ารีโมตพอร์ต 3022 (สามารถว่างได้และไม่สงวนไว้สำหรับผู้ดูแลระบบเช่น> 1024) เพื่อส่งต่อกลับไปยังพอร์ต 22 ที่ด้านโลคัล

 [localuser@localmachine ~]$ ssh userXXX@remotehost -R 3022:localhost:22
Last login: Mon May 21 05:46:07 2012 from 123.123.123.123
------------------------------------------------------------------------
This is a private system; blah blah blah
------------------------------------------------------------------------

รับรากในแบบปกติ ...

-bash-3.2$ sudo su -
[root@remotehost ~]# 

ตอนนี้คุณสามารถคัดลอกไฟล์ไปในอีกทางหนึ่งโดยหลีกเลี่ยงขั้นตอนที่น่าเบื่อในการทำสำเนากลางของไฟล์

[root@remotehost ~]#  scp -o NoHostAuthenticationForLocalhost=yes \
 -P3022 /etc/resolv.conf localuser@localhost:~
localuser@localhost's password: 
resolv.conf                                 100%  
[root@remotehost ~]#  

ปัญหาที่ 2: การส่งต่อตัวแทน SSH : ถ้าคุณโหลดรายละเอียดรากเช่นโดยการระบุเปลือกเข้าสู่ระบบเป็นตัวแปรสภาพแวดล้อมที่จำเป็นสำหรับตัวแทน SSH ส่งต่อเช่นSSH_AUTH_SOCKมีการตั้งค่าจึงส่งต่อตัวแทน SSH คือ "เสีย" sudo su -ภายใต้

คำตอบที่อบครึ่ง :

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

การทำเช่นนี้จะทำให้ได้รับโปรไฟล์ความฝันที่ไม่ควรนำมาใช้เพราะมันเป็นแฮ็คที่น่ารังเกียจแต่มีประโยชน์เมื่อคุณต้องการไฟล์ SCP จากโฮสต์ระยะไกลในฐานะรูทไปยังโฮสต์ระยะไกลอื่น ๆ

อย่างไรก็ตามคุณสามารถเปิดใช้งานให้ผู้ใช้ของคุณสามารถรักษาตัวแปร ENV ของพวกเขาโดยการตั้งค่าต่อไปนี้ใน sudoers;

 Defaults:userXXX    !env_reset

สิ่งนี้ช่วยให้คุณสร้างสภาพแวดล้อมการเข้าสู่ระบบไฮบริดที่น่ารังเกียจเช่นนั้น

เข้าสู่ระบบตามปกติ

[localuser@localmachine ~]$ ssh userXXX@remotehost 
Last login: Mon May 21 12:33:12 2012 from 123.123.123.123
------------------------------------------------------------------------
This is a private system; blah blah blah
------------------------------------------------------------------------
-bash-3.2$ env | grep SSH_AUTH
SSH_AUTH_SOCK=/tmp/ssh-qwO715/agent.1971

สร้างเปลือกทุบตีวิ่งที่และ/root/.profile /root/.bashrcแต่เก็บรักษาSSH_AUTH_SOCK

-bash-3.2$ sudo -E bash -l

ดังนั้นเชลล์นี้มีสิทธิ์รูทและรูท$PATH(แต่เป็นโฮมไดเรกทอรี borked ... )

bash-3.2# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=user_u:system_r:unconfined_t
bash-3.2# echo $PATH
/usr/kerberos/sbin:/usr/local/sbin:/usr/sbin:/sbin:/home/xtrabm/xtrabackup-manager:/usr/kerberos/bin:/opt/admin/bin:/usr/local/bin:/bin:/usr/bin:/opt/mx/bin

แต่คุณสามารถใช้การร้องขอนั้นเพื่อทำสิ่งต่าง ๆ ที่ต้องการรูท sudo จากระยะไกล แต่ยังสามารถเข้าถึงเอเจนต์ SSH ได้เช่นกัน

bash-3.2# scp /root/.ssh/authorized_keys ssh-agent-user@some-other-remote-host:~
/root/.ssh/authorized_keys              100%  126     0.1KB/s   00:00    
bash-3.2# 

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

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

ฉันมักจะใช้ 'su' มากกว่า sudo สำหรับการเข้าถึงรูท

ฉันใช้ (1) แต่ฉันพิมพ์

rm -rf / tmp *

ในหนึ่งวันที่โชคไม่ดีฉันเห็นได้ว่าแย่พอถ้าคุณมีผู้ดูแลมากกว่าหนึ่งคน

(2) มีโครงสร้างที่มากขึ้น - และคุณสามารถกลายเป็นรากเต็มได้ผ่าน sudo su - อุบัติเหตุยังคงเป็นไปได้

(3) ฉันจะไม่สัมผัสกับเสาเรือ ฉันใช้มันใน Suns เพื่อให้มีบัญชี root ที่ไม่ใช่แบร์โบน (ถ้าฉันจำได้ถูกต้อง) แต่ก็ไม่เคยแข็งแกร่ง - บวกฉันสงสัยว่ามันจะตรวจสอบได้มาก

ตอบอย่างแน่นอน 2.

1. หมายความว่าคุณกำลังช่วยให้เข้าถึง SSH rootเป็น หากเครื่องนี้หันหน้าไปทางสาธารณะนี่เป็นเพียงความคิดที่แย่มาก ย้อนกลับไปเมื่อฉันใช้ SSH ที่พอร์ต 22 VPS ของฉันมีความพยายามหลายชั่วโมงทุกชั่วโมงเพื่อตรวจสอบว่าเป็นรูท ฉันมี IDS พื้นฐานตั้งค่าให้บันทึกและห้าม IP ที่พยายามล้มเหลวหลายครั้ง แต่พวกเขายังคงมา โชคดีที่ฉันปิดใช้งานการเข้าถึง SSH ในฐานะผู้ใช้รูททันทีที่ฉันมีบัญชีและ sudo ที่กำหนดค่าไว้ นอกจากนี้คุณแทบไม่มีหลักฐานการตรวจสอบในการทำเช่นนี้

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

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

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

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

ในสมัยก่อนไม่มี sudo อยู่ ดังนั้นการมีผู้ใช้ UID 0 หลายคนจึงเป็นทางเลือกเดียวเท่านั้น แต่มันก็ยังไม่ดีโดยเฉพาะอย่างยิ่งกับการบันทึกตาม UID เพื่อรับชื่อผู้ใช้

ทุกวันนี้ sudo เป็นทางออกที่เหมาะสมเท่านั้น ลืมสิ่งอื่นใด

มันเป็นเอกสารที่ได้รับอนุญาตตามความเป็นจริง BSD unices มีบัญชี toor เป็นเวลานานและผู้ใช้ bashroot มีแนวโน้มที่จะได้รับการยอมรับในระบบที่ csh เป็นมาตรฐาน (การทุจริตต่อหน้าที่ได้รับการยอมรับ)

บางทีฉันก็แปลก แต่วิธีการ (3) เป็นสิ่งที่ปรากฏในใจของฉันก่อนเช่นกัน ข้อดี: คุณมีชื่อผู้ใช้ทุกคนในบันทึกและจะรู้ว่าใครทำอะไรในฐานะรูท จุดด้อย: พวกเขาต้องการที่จะหยั่งรากตลอดเวลาดังนั้นความผิดพลาดอาจเป็นความหายนะ

ฉันอยากจะถามว่าทำไมคุณต้องมีผู้ดูแลระบบทั้งหมดเพื่อเข้าถึงรูท ทั้งหมด 3 วิธีที่คุณนำเสนอมีข้อเสียอย่างหนึ่งที่แตกต่าง: ครั้งหนึ่งเคยเป็นผู้ดูแลระบบทำงานsudo bash -lหรือsudo su -หรือเช่นคุณจะสูญเสียความสามารถในการติดตามใครทำอะไรและหลังจากนั้นความผิดพลาดจะเป็นความหายนะ ยิ่งกว่านั้นในกรณีที่มีพฤติกรรมที่ไม่เหมาะสมเกิดขึ้นสิ่งนี้อาจยิ่งแย่ลงไปอีก

แต่คุณอาจต้องการพิจารณาวิธีอื่น:

• สร้างผู้ใช้ผู้ดูแลระบบของคุณเป็นผู้ใช้ปกติ
• ตัดสินใจว่าใครต้องทำงานอะไรบ้าง (การจัดการ apache / postfix management เป็นต้น)
• เพิ่มผู้ใช้ไปยังกลุ่มที่เกี่ยวข้อง (เช่นเพิ่ม "martin" เป็น "postfix" และ "mail", "amavis" หากคุณใช้เป็นต้น)
• แก้ไขการอนุญาต (chmod -R g + w postfix: postfix / etc / postfix)
• ให้พลัง sudo เท่านั้น: (visudo -> ให้มาร์ตินใช้ /etc/init.d/postfix, / usr / bin / postsuper ฯลฯ )

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

ตรรกะเดียวกันสามารถนำไปใช้กับระบบย่อยอื่น ๆ เช่น apache, mysql เป็นต้น

แน่นอนว่านี่เป็นทฤษฎีที่บริสุทธิ์ ณ จุดนี้และอาจตั้งค่าได้ยาก มันดูเหมือนเป็นวิธีที่ดีกว่าที่จะไปสรรพสินค้าใหญ่ อย่างน้อยสำหรับฉัน หากใครลองทำเช่นนี้โปรดแจ้งให้เราทราบว่ามันไปได้อย่างไร