Giải pháp tốt nhất để quản lý mật khẩu root của hàng ngàn máy chủ


12

Tôi là quản trị viên hệ thống. Trong môi trường sản xuất tôi cần quản lý hàng ngàn máy chủ. Các đồng nghiệp của tôi và tôi sử dụng một máy chủ quản lý trung tâm và phân phối khóa chung của nó thông qua các máy chủ khác. Vì vậy, chúng ta có thể sử dụng máy chủ quản lý này để ssh đến các máy chủ khác.

Đôi khi chúng ta cần sử dụng mật khẩu root, ví dụ khi máy chủ ngừng hoạt động, chúng ta cần sử dụng iLO để xác định lý do.

Hiện tại, chúng tôi sử dụng một mật khẩu root được chia sẻ. Nó không an toàn. Tôi cũng đã xem xét một số giải pháp máy chủ duy nhất như OPIE(Mật khẩu một lần trong mọi thứ), nhưng vì chúng tôi có rất nhiều máy chủ, đây không phải là một ý tưởng hay.

BIÊN TẬP:

Những gì tôi muốn từ giải pháp quản lý mật khẩu là:

  1. Nó phải an toàn, vì vậy Mật khẩu một lần là một giải pháp tuyệt vời.
  2. Mật khẩu có thể được nhập dễ dàng, đôi khi chúng ta cần phải gắn màn hình vào máy chủ hoặc với iLO như tôi đã đề cập ở trên.
  3. Giải pháp sẽ hoạt động ngay cả khi máy chủ ngoại tuyến (không có bất kỳ kết nối mạng nào)

Vì vậy, không nên đặt mật khẩu gốc thành một chuỗi dài và ngẫu nhiên, mặc dù nó được tạo từ một số lệnh đã biết (như openssl passwd). Thật khó để nhớ và đôi khi rất khó để tạo ra (không có máy tính xách tay của tôi)


1
Bạn đã sử dụng một hệ thống quản lý cấu hình như con rối? Bạn đang dùng gì?
Zoredache

Con rối ++ cho việc này.
Tom O'Connor

Chúng tôi sử dụng
cengine

Câu trả lời:


5

Bạn có thể sử dụng con rối để thay đổi mật khẩu cho tất cả các máy chủ của mình. Bạn sẽ xác định rootbằng cách sử dụng userloại như vậy:

    user { 'root':
            ensure => present,
            password => '$1$blablah$blahblahblahblah',
    }

Để tạo mật khẩu được mã hóa:

openssl passwd -1 -salt "blah"

Tôi có thể đề nghị có thể thay đổi nó mỗi tháng hoặc lâu hơn --- có thể sử dụng sơ đồ mà các SA của bạn ghi nhớ. Bạn cũng có thể phân phối nó thông qua một phương pháp an toàn hoặc đặt nó an toàn.


3

Bạn luôn có thể đặt mật khẩu bị vô hiệu hóa. Điều này sẽ ngăn mọi truy cập mạng vào root và nếu bạn khởi động vào một chế độ người dùng, hầu hết các bản phân phối sẽ khởi động thẳng vào hệ vỏ.

Đây có lẽ không phải là vấn đề lớn về bảo mật như bạn nghĩ. Dù sao cũng không thể bỏ qua mật khẩu gốc, trừ khi bạn đã khóa grub bằng mật khẩu, hầu như ai cũng có thể đơn giản nói với grub để bắt đầu bash thay vì initrd.

Tất nhiên điều này có nghĩa là, thay vào đó bạn nên tìm ra cách để mật khẩu bảo vệ bộ tải khởi động của bạn.


0

Bạn có thể sử dụng mật khẩu một lần với quản lý trung tâm. Tôi biết rằng điều này không phù hợp với "phải hoạt động khi eth ngoại tuyến và máy chủ được truy cập bằng iLO".

Dù sao: Câu hỏi là, tần suất máy chủ ngoại tuyến.

Vì vậy, bạn có thể nghĩ về các thiết lập sau:

Sử dụng giải pháp OTP được quản lý tập trung như Privacyidea ( http://www.privacyidea.org ). Bạn có thể chỉ định một số mã thông báo OTP khác nhau cho người dùng root. Mỗi mã thông báo có mã PIN OTP khác nhau và là một thiết bị khác nhau. Do đó, tất cả các đồng nghiệp của bạn có thể đăng nhập với tư cách người dùng root nhưng trong nhật ký kiểm toán, bạn sẽ thấy mã thông báo nào được xác thực, do đó bạn có thể biết đồng nghiệp nào đã đăng nhập vào thời điểm nào.

Trên các máy chủ, bạn cần định cấu hình pam_radius để chuyển yêu cầu xác thực đến RADIUS và PrivacyIDEA.

Bummer. Bây giờ máy chủ của bạn được ngoại tuyến. Trong trường hợp này, bạn nên chơi với chồng pam của bạn. Tôi có thể nghĩ về một cái gì đó như:

auth sufficient pam_unix.so
auth required pam_radius.so use_first_pass

Vì vậy, bạn có thể đăng nhập bằng mật khẩu cố định ngoại tuyến và nếu không, mật khẩu sẽ được trao cho pam_radius và được xác thực là OTP đối với PrivacyIDEA.

Xem hướng dẫn này https://www.howtoforge.com/manage-two-factor-authentication-in-your-serverfarm-with-privacyidea .

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 cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.