จำกัด การเข้าถึงที่เก็บ Debian ส่วนตัวอย่างปลอดภัย

9

ฉันกำลังมองหาวิธีที่จะ จำกัด การเข้าถึงที่เก็บ Debian ส่วนตัวและสามารถตรวจสอบได้โดยไม่ต้องโต้ตอบ (เช่นการใช้สคริปต์)

บทความที่มีประโยชน์มากที่สุดที่ฉันพบถ้าจริง ๆ แล้วจากเว็บไซต์การดูแล Debianแต่วิธีการรักษาความปลอดภัยใช้ ssh และคีย์สาธารณะ / ส่วนตัว มันใช้งานได้ดี แต่กุญแจสาธารณะของแต่ละโฮสต์จะต้องอยู่ในไฟล์ authorized_keys ระยะไกลเพื่อตรวจสอบสิทธิ์ มันไม่ได้พูดอะไรเกี่ยวกับการให้รหัสผ่านกับ ssh: // แต่ฉันคิดว่ามันควรจะเป็นไปได้

คุณเคยลองทางเลือกอื่น ๆ แล้วหรือไม่ (เช่น ftps)

ขอบคุณล่วงหน้า

— ซังกะตาย
แหล่งที่มา

ปัญหาที่ฉันมีกับบทความข้างต้นคือมันไม่เพียงให้การเข้าถึงที่เก็บ APT - มันให้การเข้าถึงเชลล์ไปยังเครื่องที่เก็บ APT ของฉัน นั่นเป็นความเสี่ยงที่ยอมรับไม่ได้

— BobDoolittle

5

ถ้าคุณเรียกใช้เสมอapt-getในเซิร์ฟเวอร์ของคุณด้วยมือ (ไม่อัตโนมัติapt-getคำสั่งเปิดตัวโดย crons) แล้วคุณอาจพิจารณาใช้การส่งต่อตัวแทน SSH วิธีนี้หลีกเลี่ยงการจัดการคู่พับลิก / ไพรเวตคีย์ต่อเซิร์ฟเวอร์ที่คุณจัดการและอาจปลอดภัยกว่าการทิ้งคีย์ส่วนตัวไว้ในทุก ๆ เซิร์ฟเวอร์

การกำหนดค่าเริ่มต้น - เชื่อมต่อกับเซิร์ฟเวอร์ที่คุณต้องการจัดการและเพิ่มสิ่งนี้ใน/etc/apt/sources.list(ตัวอย่างนี้สมมติว่าคุณต้องการให้เซิร์ฟเวอร์ของคุณเชื่อมต่อกับmanagerบัญชี):

    deb ssh://manager@my.repository.org/path other stuff

สร้างคู่ของคีย์ส่วนตัว / สาธารณะในคอมพิวเตอร์ของคุณเองด้วยการลงชื่อเข้าใช้ของคุณjohndoe(หากคอมพิวเตอร์ของคุณทำงานบนเดเบียน: ถ้าไม่คุณสามารถทำได้จากเดเบียนเซิร์ฟเวอร์เพื่อการจัดการ):
```
ssh-keygen
```
ตรวจสอบให้แน่ใจว่ามันได้รับการป้องกันโดย keyphrase ที่แข็งแกร่ง
คัดลอกกุญแจสาธารณะของคุณไปยังเซิร์ฟเวอร์ที่เก็บใน/home/manager/.ssh/authorized_keys:
```
ssh-copy-id manager@my.repository.org
```

หนึ่งครั้งต่อการจัดการเซสชั่น

เริ่มต้นเอเจนต์ ssh บนเครื่องของคุณโดยพิมพ์:
```
eval `ssh-agent`
```
เพิ่มรหัสของคุณให้กับตัวแทน (สิ่งนี้จะต้องมีวลีรหัสผ่านของคุณ):
```
ssh-add
```

การจัดการเซิร์ฟเวอร์

เชื่อมต่อกับเซิร์ฟเวอร์ที่คุณต้องการจัดการโดยใช้ssh -A( -Aเปิดใช้งานการส่งต่อตัวแทน):
```
ssh -A some.server.org
```
เปลี่ยนเป็นรูท (หากคุณต้องการใช้sudoคุณจำเป็นต้องกำหนดค่า/etc/sudoersมิฉะนั้นsudoจะทำให้การส่งต่อเอเจนต์ล้มเหลวโปรดอ่านสิ่งนี้ ):
```
su
```
ตอนนี้คุณควรจะสามารถเชื่อมต่อกับบัญชีผู้จัดการของที่เก็บโดยใช้ ssh โดยไม่ต้องพิมพ์รหัสผ่านของคุณอีกครั้งขอบคุณตัวแทนส่งต่อ ดังนั้นapt-getควรทำงานได้ดี:
```
apt-get udate
```

สิ้นสุดเซสชันการจัดการของคุณ

เมื่อคุณจัดการเซิร์ฟเวอร์เสร็จแล้วให้ลบกุญแจของคุณออกจากตัวแทน:
```
ssh-add -D
```

ข้อดี

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

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

ขอขอบคุณ MiniQuark อีกครั้ง จริงๆแล้วการอัปเดตนั้นไม่ต้องใส่ข้อมูล แต่นี่เป็นวิธีการที่ยอดเยี่ยมที่ฉันสามารถใช้เพื่อการทดสอบได้

— ซังกะตาย

ด้วยความยินดี! :) ดีใจถ้ามันช่วย

— MiniQuark

4

วิธีหนึ่งในการทำเช่นนี้คือเพื่ออนุญาตให้ชุดของ IP บางรายการเข้าถึงที่เก็บข้อมูล สิ่งนี้ทำงานได้ดีมากสำหรับ LAN และ VPN

ง่ายและมีประสิทธิภาพ

— Antoine Benkemoun
แหล่งที่มา

1

ขอบคุณแอนทอน :) จริงๆแล้วที่เก็บที่ฉันมีตอนนี้สามารถเข้าถึงได้โดยใช้วิธีการนั้น (http ผ่านการเชื่อมต่อ OpenVPN) ฉัน จำกัด IP ที่เป็นของ VPN ข้อเสียเปรียบที่นี่คือทุกโฮสต์จะต้องเชื่อมต่อกับ VPN เพื่อเข้าถึง repo ซึ่งค่อนข้างน่ารำคาญเล็กน้อย (จัดการใบรับรอง / คีย์หลายรายการ) ขออภัยที่ไม่ได้ระบุว่าในคำถาม

— ซังกะตาย

จริงอยู่การจัดการ OpenVPN น่ารำคาญ แต่มันทำให้การจัดการความปลอดภัยกับที่เก็บของคุณง่ายมาก นอกจากนี้ผู้ใช้ไม่ต้องกังวลกับข้อมูลรับรองเพียงครั้งเดียวภายใน VPN

— Antoine Benkemoun

2

วิธีการแก้ปัญหา SSH + แป้นรัฐ / ภาคเอกชนไม่ได้ว่าไม่ดี:

เข้าสู่ระบบในฐานะ root บนเครื่องลูกค้า
พิมพ์ssh-keygenจากนั้นssh-copy-id your_login@your.repository.org
แก้ไข/etc/apt/sources.listและเพิ่มสิ่งที่ชอบ:
```
deb ssh://your_login@your.repository.org/path other stuff
```

ได้รับมันต้องให้คุณใส่กุญแจสาธารณะของแต่ละเซิร์ฟเวอร์ใน~/.ssh/authorized_keysไฟล์บนเซิร์ฟเวอร์ แต่มันไม่ซับซ้อน (ดูด้านบน) และมันช่วยให้คุณควบคุมเซิร์ฟเวอร์ที่คุณอนุญาตหรือไม่ตามเวลาที่กำหนด (คุณสามารถลบคีย์ที่ ทุกเวลาในauthorized_keys)

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

ขอบคุณ MiniQuark ใช่โซลูชันนี้ไม่ได้แย่ขนาดนั้น แต่ ssh-copy-id ไม่ทำงานหากการตรวจสอบรหัสผ่านถูกปิดใช้งานในเซิร์ฟเวอร์ openssh ฉันคิดว่าการกระจายไฟล์คีย์เดียวกันในแต่ละไคลเอนต์โดยใช้ที่เก็บเพื่อให้สามารถใช้งานได้ เพื่อความปลอดภัยเพิ่มเติมผู้ใช้ที่มีสิทธิ์น้อยที่สุดจะถูกใช้ เกือบจะเหมือนกับการแชร์ข้อมูลรับรอง ขณะนี้ฉันกำลังทดสอบวิธีนี้เพื่อตรวจสอบพฤติกรรม / การทำงาน

— ซังกะตาย

1

คุณสามารถตั้งค่าการเข้าถึง https ไปยังที่เก็บของคุณปลอดภัยโดยเข้าสู่ระบบ / รหัสผ่าน (การตรวจสอบเบื้องต้น) ปัญหาคือคุณต้องใส่ข้อมูลล็อกอิน / รหัสผ่านของ cleartext /etc/apt/sources.list(หมายเหตุ: มีโปรแกรมแก้ไขเพื่ออนุญาตให้ใส่ข้อมูล / รหัสผ่าน/root/.netrcแทน)

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

นี่อาจเป็นทางออกที่ดีที่สุด แต่ก็ไม่ใช่ netrc แต่ /etc/apt/auth.conf เอกสารที่นี่: manpages.debian.org/testing/apt/apt_auth.conf.5.en.html

— Nicholi

0

ลิงก์ในคำถามของคุณแสดงหลายวิธี คุณต้องการหมายเลข 2, https + การรับรองความถูกต้องเบื้องต้น

— จัสติน
แหล่งที่มา

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

— ซังกะตาย

chmod 600 /etc/apt/sources.list

— Justin