วิธีการอนุญาตให้ ssh เพื่อรูทผู้ใช้จากเครือข่ายท้องถิ่น

ฉันได้ติดตั้ง Google-Authenticator บนเครื่อง CentOS 6.5 และกำหนดค่าผู้ใช้บางรายเพื่อให้ OTP

ในขณะที่แก้ไข/etc/ssh/sshd_configฉันเห็นคำสั่ง " PermitRootLogin" ซึ่งถูกใส่ความคิดเห็นโดยปริยาย

ฉันต้องการตั้งค่า " PermitRootLogin no" แต่ยังคงสามารถ ssh ไปยังเครื่องได้ในฐานะรูทจากเครือข่ายท้องถิ่นเท่านั้น

เป็นไปได้ไหม

linux ssh centos6

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

— SnakeDoc

@SnakeDoc: นั่นเป็นโรงเรียนแห่งความคิดหนึ่ง แต่ก็ไม่ชัดเจนและฉันจะโต้แย้งในทางตรงกันข้าม sudo เป็นพื้นผิวการโจมตีที่ซับซ้อนมากและไม่ใช่สิ่งที่ฉันต้องการติดตั้ง SSH pubkey auth เป็นพื้นผิวการโจมตีที่เล็กกว่ามาก สามารถบันทึกได้ แต่การบันทึกจะไม่มีประโยชน์มากเมื่อผู้ใช้ (รูท) สามารถแก้ไขหรือลบบันทึกได้ซึ่งเป็นกรณีนี้เสมอเว้นแต่คุณจะบันทึกลงในที่เก็บข้อมูลผนวกภายนอกเท่านั้น

— ..

@R .. หากคุณตั้งค่า sudoers อย่างถูกต้องโดยใช้หลักการของสิทธิ์น้อยที่สุดปัญหาเหล่านี้ที่คุณอธิบายไว้นั้นไม่ใช่ปัญหา ผู้ใช้ไม่ควรจะสามารถเข้าและsudo - suออกจากรูทหรือทำสิ่งที่ผู้ใช้ไม่ต้องการ (ใน sudoers คุณต้องใช้ White-list สำหรับคำสั่ง) หากคุณต้องการรูทคุณต้องอยู่ที่คอนโซล - เช่น ไม่ควรอนุญาตให้รูทผ่าน SSH ... คีย์หรือไม่

— SnakeDoc

@SnakeDoc: คุณเข้าใจผิด Sudo มีทั้งพื้นผิวของตัวเองที่ซับซ้อนโจมตีและพื้นฐานพื้นผิวการโจมตีที่ซับซ้อนที่เป็นธรรมชาติที่จะเป็นไบนารี SUID ในรูปแบบของทุกรัฐที่ได้รับการถ่ายทอดทั่ว execve ในบางกรณีข้อผิดพลาดในโปรแกรม suid เอง (suid) ไม่จำเป็นแม้แต่; ข้อบกพร่องในโครงสร้างพื้นฐานเช่นตัวเชื่อมโยงแบบไดนามิก (เช่น CVE-2010-3856) อาจเพียงพอ

— ..

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

— เป็นสุข

คำตอบ:

ใช้Matchพารามิเตอร์ config ใน/etc/ssh/sshd_config:

# general config
PermitRootLogin no 

# the following overrides the general config when conditions are met. 
Match Address  192.168.0.*
    PermitRootLogin yes

ดู man sshd_config

— สเวน
แหล่งที่มา

ทำไมฉันไม่คิดอย่างนั้นล่ะ ขอบคุณเพื่อน

— Itai Ganot

นอกจากนี้คุณยังสามารถ จำกัด ~root/.ssh/authorized_keysแหล่งสำหรับปุ่มตรวจสอบใน from="192.168.0.0/24 "คำนำหน้าสำคัญด้วย

— BillThor

ฉันจะเปลี่ยนเป็นอนุญาตที่อยู่ลิงก์ท้องถิ่นของ IPv6 วิธีการทำงานของ link-local address ใน IPv6 ทำให้เครือข่ายมีความทนทานต่อการกำหนดค่าผิดพลาด ซึ่งหมายความว่าหากคุณต้องการ ssh เพื่อแก้ไขการกำหนดค่าเครือข่ายที่ไม่ถูกต้องเป็นไปได้ว่าการใช้ที่อยู่ IPv6 link-local เป็นทางเลือกเดียวที่เหลืออยู่

— kasperd

FYI หากคุณใช้คำสั่งAllowUser เพิ่มเติมคุณต้องเพิ่ม (และตอบโต้ด้วยความเข้าใจผิด) ด้วยAllowUser root

— Robert Riedl

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

AllowUsers itai root@192.168.0.*

สิ่งนี้จะป้องกันไม่ให้ผู้ใช้อื่น ๆ (เช่นapache) เข้าสู่ระบบผ่าน SSH

ดูเพิ่มเติมAllowUsersคำหลักในsshd_config (5)คู่มือ

— Lekensteyn
แหล่งที่มา

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

— CVn

@ MichaelKjörlingนอกจากนี้ AllowGroups หมายความว่าคุณไม่จำเป็นต้องแก้ไขสิทธิ์สำหรับ sshd_config หากทีมของคุณขยายหรือย่อขนาด สิ่งนี้อาจอนุญาตให้มีประเภทการจัดการหรือการฝึกงานเพิ่มเติมได้

— Nzall

คะแนนที่ดีโปรดทราบว่าคุณสามารถรวมตัวเลือกมีAllowUsers itai root@192.168.0.*และAllowGroups ssh-usersคุณจะไม่ทำให้เกิดการล็อคโดยบังเอิญในกรณีที่ผู้ฝึกงานล้างกลุ่มโดยไม่ตั้งใจ :)

— Lekensteyn