Hệ thống quản lý tập trung cho các khóa SSH?

27

Chúng tôi đang tìm cách chuyển sang quản lý đăng nhập SSH dựa trên khóa và tự hỏi liệu có hệ thống quản lý khóa nào cho phép chúng tôi quản lý tập trung các khóa truy cập trên toàn thế giới không.

Hệ thống lý tưởng nên cho phép phát hành khóa trên mỗi máy khách và thu hồi chúng nếu cần, cập nhật các khóa máy chủ khi đang di chuyển.

Có ai biết một hệ thống như vậy, thương mại hay nguồn mở không?

LƯU Ý: Để làm rõ, chúng tôi cần quản lý khóa cho số lượng máy chủ đám mây khá lớn (giống như EC2) và một lượng nhỏ người dùng dịch vụ. Tôi đoán LDAP + bản vá đề xuất dưới đây có thể là cách để đi.

ssh  cloud  keys 
— SyRenity
nguồn
7
Có phải chỉ mình tôi nghĩ rằng "khóa riêng và đám mây" giống như "uống và lái xe". Cả hai làm cho vui riêng nhưng không bao giờ đi cùng nhau.
— mailq
1
"Đám mây" có lẽ là từ sai - có vẻ như những gì họ muốn là xác thực tập trung, với tính nhất quán trên toàn thế giới.
— voretaq7
Chào. Chính xác - đó là những gì chúng tôi tìm kiếm.
— SyRenity
Tôi đã phải vật lộn với vấn đề này với một số khách hàng của tôi môi trường lai. Ngoài ra còn có câu hỏi về việc giữ OPenLDAP hoặc trung tâm trong triển khai đám mây ở đâu? Tôi đã sử dụng webmin của tất cả mọi thứ như một công cụ quản lý khóa và sách dạy nấu ăn để đồng bộ hóa các phím với các nút.
— Tom H
Userify bao gồm những gì bạn đang tìm kiếm (xem serverfault.com/questions/647797/ cấp )
— Jamieson Becker

Câu trả lời:

8

Có rất nhiều cách để làm điều này. Lưu trữ khóa LDAP đã được đề cập một vài lần và tôi đã làm điều đó và nó hoạt động, theo như nó làm. LDAP có sự tò mò về quản lý riêng, tuy nhiên, điều này cần một số kiến ​​thức.

Tôi là một fan hâm mộ lớn của các máy chủ đơn giản, mạnh mẽ, có sự phụ thuộc mạng bên ngoài tối thiểu cho những việc đơn giản như xác thực quản trị viên, vì vậy tôi nghiêng về chiến lược phân phối khóa SSH mạnh mẽ hơn nhiều - tôi có hệ thống quản lý cấu hình đảm nhiệm. Khóa chung của mọi người được giữ trong hệ thống quản lý cấu hình và bất cứ nơi nào người đó cần để có thể đăng nhập, khóa của họ sẽ được thêm vào. Hệ thống cấu hình cũng biết loại bỏ các khóa không được chỉ định, vì vậy khi ai đó rời khỏi hoặc khóa của họ thay đổi, việc gỡ bỏ cấu hình khóa và trên hệ thống cấu hình tiếp theo sẽ chạy, khóa sẽ bị xóa.

— womble
nguồn
Cách tiếp cận này chắc chắn là một phương pháp tốt và như Womble chỉ ra rằng nó có lợi thế ở chỗ các máy chủ luôn hoạt động (và có thể truy cập) trong trường hợp LDAP ngừng hoạt động - Mọi hệ thống được hỗ trợ bởi LDAP (tôi dám nói là phải ) ít nhất một người dùng có khóa được đẩy ra theo cách Womble mô tả. Nhược điểm là bạn phải chạy cấu hình để ủy quyền cho người dùng. Không phải là vấn đề đối với "tài khoản khẩn cấp" chỉ với một vài người dùng được ủy quyền. Vấn đề lớn hơn đối với số lượng lớn tài khoản :)
— voretaq7
1
Bạn thực sự phải có một cách để kích hoạt cấu hình hàng loạt chạy, vì vậy nó không phải là một vấn đề lớn để thay đổi tài khoản.
— womble
Tôi đồng ý, không may là nhu cầu / tâm lý kinh doanh không: Chứng hoang tưởng ở nhiều nơi (bao gồm cả tôi) cho rằng việc đẩy cấu hình xảy ra trong giờ làm việc nhưng nhân viên mới / nhân viên rời đi có thể xảy ra bất cứ lúc nào: - /
— voretaq7
1
Vì vậy, bạn rất vui khi để lại những thứ bị hỏng cho một ngày làm việc chỉ vì bạn không thể chạy một cú đẩy cấu hình trong ngày? Chỉ vì nó phổ biến, không có nghĩa là nó không ngu ngốc.
— womble
2
Chào. Vì vậy, một ý tưởng tốt sẽ được sử dụng Puppet cho điều này, ví dụ?
— SyRenity
23

Các cặp khóa nên được tạo bởi người dùng.

Người dùng giữ lại một nửa riêng tư - bạn sẽ không bao giờ nhìn thấy nó. Nếu bạn có khóa riêng của ai đó ở dạng bạn có thể đọc / sử dụng thì bạn đang bảo mật sai.

Một nửa công khai được trao cho bạn (theo bất kỳ cơ chế nào bạn muốn: Biểu mẫu web, email, trao cho tôi trên CD), để được tập trung theo bất kỳ cách nào bạn muốn. Một số nơi lưu trữ các khóa công khai trong LDAP. Những người khác đẩy authorized_keyscác tập tin bằng cách sử dụng hệ thống triển khai của họ.

Trong môi trường của tôi, những người cần truy cập shell cung cấp cho tôi khóa công khai của họ. Các khóa này được thêm vào hệ thống LDAP của chúng tôi và sshdtư vấn (các) khóa chung được liệt kê cho mỗi người dùng để xác thực chúng, thông qua bản vá Khóa công khai LDAP .
Khi ai đó cần thêm khóa bổ sung hoặc thu hồi khóa hiện có, họ sẽ cho quản trị viên biết và chúng tôi sẽ xử lý khóa đó. Cuối cùng, khi chúng tôi mở rộng quy mô, tôi sẽ triển khai một hệ thống cho phép mọi người xoay khóa công khai của riêng họ.

Mỗi trang web của chúng tôi có một cặp máy chủ LDAP, được đồng bộ hóa với chủ nhân của chúng tôi với sao chép LDAP, giúp dữ liệu nhất quán (và có thể truy cập) tại mỗi vị trí.

Mọi thứ tôi đã mô tả đều có thể được thực hiện với phần mềm nguồn mở. Cũng có những sản phẩm thương mại làm điều tương tự.
Bạn cần nghiên cứu các tùy chọn có sẵn kỹ lưỡng hơn và quyết định xem cái nào phù hợp với môi trường của bạn nhất. Nếu bạn có thêm câu hỏi (cụ thể hơn), chúng tôi có thể hữu ích hơn.

— voretaq7
nguồn
Vì vậy, về cơ bản, bạn đề nghị sử dụng cơ sở hạ tầng LDAP, với OpenSSH được vá sẽ hoạt động với LDAP? Làm thế nào tốt quy mô này trong sản xuất? Nó có thể hỗ trợ một lượng lớn máy móc không? Chúng tôi chỉ cần hỗ trợ một lượng nhỏ người dùng dịch vụ.
— SyRenity
1
@SyRenity: LDAP hỗ trợ nhân rộng và phân cụm để nó có quy mô rất tốt
— Hubert Kario
@SyRenity Về mặt lý thuyết bạn có thể hỗ trợ số lượng máy không giới hạn tại một số địa điểm không giới hạn (nghĩ rằng "Triển khai Active Directory thực sự lớn" - AD về cơ bản là LDAP với một số phụ kiện thời trang). Đối với người dùng dịch vụ, đề xuất của tôi là chuẩn hóa chúng trên môi trường của bạn và đẩy ra các tệp /etc/passwdvà /etc/grouptệp được chuẩn hóa (cho phép các máy hoạt động bình thường và các dịch vụ liên quan để khởi động / chạy ngay cả khi LDAP không khả dụng)
— voretaq7
@ voretaq7 Có nghĩa là người dùng dịch vụ sẽ được quản lý tách biệt với LDAP, thông qua quản lý cấu hình?
— SyRenity
@SyRenity có - và quan trọng hơn là có sẵn cho các dịch vụ sử dụng chúng nếu LDAP không hoạt động . Lập kế hoạch cho những thất bại hoặc bạn sẽ trải qua thảm họa.
— voretaq7
9

Keypairs không nên được tạo ở bất cứ đâu mà trên mỗi máy tính của người dùng. Khóa riêng được đặt tên như vậy vì một lý do.

Điều đó nói rằng, tôi có thể thấy một trường hợp sử dụng cho một số kho lưu trữ tập trung các khóa công khai của người dùng. Một tùy chọn sẽ là lưu trữ các khóa công khai trong OpenLDAP - các phiên bản gần đây của OpenSSH có thể đọc các khóa ngoài LDAP.

— EEAA
nguồn
2
Bây giờ công cụ LDAP Public Key trong dòng chính OpenSSH phải không? Tôi chỉ biết về bản vá LPK (mà tôi có thể bảo đảm - nó hoạt động rất tốt). Cũng +1 để giữ khóa riêng tư.
— voretaq7
@ voretaq7 Tôi đoán tôi nghe nói nó đã được hợp nhất vào tuyến chính, nhưng tôi chưa xác minh được điều đó. Chúng tôi chia sẻ các thư mục nhà thông qua NFS, do đó sẽ chăm sóc phân phối khóa của chúng tôi cho chúng tôi.
— EEAA
Tôi cũng không biết điều đó. Điều đó sẽ cứu tôi một loạt rắc rối. bây giờ trong danh sách của tôi về những điều cần xem xét.
— Tom H
1

Có rất nhiều giải pháp thương mại và nguồn mở tuyệt vời, chẳng hạn như Userify [1] (nơi tôi làm việc), Universal Key Manager [2], SSH Key Box [3], v.v. Nó phụ thuộc vào nhu cầu của bạn là gì và nếu bạn là tìm kiếm thứ gì đó tập trung quản lý trong khi phân cấp hoạt động (để máy chủ của bạn không dựa vào cơ quan trung ương để đăng nhập ... trong trường hợp đó, bạn có thể không đăng nhập được vào bất kỳ máy chủ nào của mình, nếu, nói, Máy chủ LDAP ngừng hoạt động!)

  1. https://userify.com

  2. https://www.ssh.com/products/universal-ssh-key-manager/

  3. https://www.sshkeybox.com

Xem thêm cuộc thảo luận nghiêng này:

https://www.slant.co/topics/8010/~manager-for-ssh-keys

— Jamieson Becker
nguồn
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.