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


40

ในทีมของเราเรามี 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
  • ข้อเสีย: รู้สึกสกปรกสวย - หาเอกสารไม่พบในที่ที่อนุญาต

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


2
เกี่ยวกับคำสั่ง "ไม่พบเอกสารใด ๆ ตามที่อนุญาต" ดูที่การ-oตั้งค่าสถานะในuseraddหน้าคู่มือ การตั้งค่าสถานะนี้มีไว้เพื่ออนุญาตให้ผู้ใช้หลายคนแบ่งปัน uid เดียวกัน
jlliagre

6
คุณสามารถอธิบายสิ่งที่คุณหมายถึงโดย "ตัวแบ่งการส่งต่อตัวแทน SSH" ในตัวเลือกที่สอง? เราใช้สิ่งนี้ในงานของฉันและการส่งต่อตัวแทนของ ssh ใช้ได้ดี
Patrick

4
คุณควรแยกออกจากบัญชีที่ไม่ใช่รูทของคุณมากกว่าจากภายใน sudo
Random832

4
ผลสืบเนื่องของวิธี sudo: คุณไม่สามารถ SCP / FTP เป็นรูทได้อีกต่อไป การถ่ายโอนไฟล์ใด ๆ จะต้องย้ายไปที่โฮมไดเร็กตอรี่ของบุคคลนั้นก่อน นี่คือข้อดีและข้อเสียขึ้นอยู่กับมุมมอง
user606723

1
เหตุใดระบบหุ่นกระบอก / เชฟ / ansible จึงไม่ได้รับการพิจารณา
Alex Holst

คำตอบ:


64

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

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

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


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

17
ฉันขอแนะนำให้ปิดการใช้งานการเข้าสู่ระบบรูทผ่าน SSH เพื่อความปลอดภัย หากคุณจำเป็นต้องเข้าสู่ระบบด้วยรูทจริงๆให้ล็อกอินด้วยชื่อผู้ใช้ที่ไม่ใช่รูทและ su
Taz

+1 .. ฉันจะพูดมากกว่านี้ว่า "ตัวเลือกที่สองดีที่สุด" ฉันเป็นตัวเลือกที่สมเหตุสมผลเท่านั้น ตัวเลือกที่หนึ่งและสามช่วยลดความปลอดภัยของระบบจากการโจมตีภายนอกและความผิดพลาดอย่างมากมาย นอกจากนี้ # 2 เป็นวิธีการออกแบบระบบที่จะใช้เป็นหลัก
Ben Lee

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

9

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

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

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

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

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

ดังนั้น; ใช้บัญชีส่วนตัวและ 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# 

1
ฉันชอบแฮ็ก
sjbotha

2

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

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

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


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

8
ตัวเลือกที่สามเป็นเพียงความคิดที่ดีเลือด คุณกำลังทำลายความสัมพันธ์แบบ 1: 1 ระหว่าง UID และชื่อผู้ใช้และทุกอย่างในยูนิกซ์คาดว่าจะมีความสัมพันธ์นั้น เพียงเพราะไม่มีกฎชัดเจนที่จะไม่ทำไม่ได้หมายความว่าเป็นความคิดที่ดี
Shadur

ขออภัยตัวเลือกที่สามเป็นแนวคิดที่น่ากลัว การมีหลาย UID 0 คนที่เข้าสู่ระบบเป็นเพียงการขอปัญหาที่จะคูณ ตัวเลือกหมายเลข 2 เป็นสติเดียวเท่านั้น
Doug

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

@ แพทริคคุณเคยเห็นสิ่งนี้ในทางปฏิบัติหรือไม่? มากที่สุดเท่าที่ฉันทดสอบแล้วแอปพลิเคชันจะเลือกrootผู้ใช้หากrootผู้ใช้เป็นคนแรกใน/etc/passwdกับ UID 0 ฉันมักจะเห็นด้วยกับ jlliagre ข้อเสียเพียงอย่างเดียวที่ฉันเห็นคือผู้ใช้แต่ละคนเป็นrootผู้ใช้และบางครั้งอาจสับสนที่จะเข้าใจว่าใครทำอะไร
Martin

2

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

rm -rf / tmp *

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

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

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


2

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

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

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

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

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


1

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


1

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

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


0

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


0

บางทีฉันก็แปลก แต่วิธีการ (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 เป็นต้น

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


ฉันควรเพิ่มการจัดการการเชื่อมต่อ SSH ค่อนข้างพื้นฐานในบริบทนี้ ไม่ว่าคุณจะใช้วิธีใดอย่าอนุญาตให้ล็อกอินรูทผ่าน SSH ปล่อยให้ผู้ใช้แต่ละคนมีข้อมูลประจำตัวของตนเองและจัดการ sudo / nosudo / etc จากที่นั่น
Tuncay Göncüoğlu
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.