nguy cơ sử dụng khóa công khai ssh

Tôi có máy chủ A và máy chủ B (sao lưu) và tôi đã tự hỏi, nếu ai đó xâm nhập vào máy chủ A, điều này có thể nguy hiểm khi xâm nhập vào máy chủ B nếu tôi đã cấu hình đăng nhập không mật khẩu bằng khóa công khai ssh không?

Tôi đang cố gắng thiết lập rsnapshot.

Cảm ơn

Có, đây là một trong những vấn đề với khóa SSH không mật khẩu. Nếu bạn lưu trữ khóa riêng trên máy chủ A cho phép bạn kết nối với máy chủ B, việc truy cập vào máy chủ A có hiệu quả truy cập vào máy chủ B. (Không phải điều ngược lại là không đúng - việc truy cập vào máy chủ B sẽ không dẫn đến Sự thỏa hiệp ngay lập tức của máy chủ A, giả sử bạn không cài đặt khóa SSH để cho phép đăng nhập không mật khẩu theo hướng đó.

Có một vài điều bạn có thể làm để giảm thiểu điều này:

• Nếu quy trình không cần phải hoàn toàn tự động, hãy thêm mật khẩu vào các khóa SSH của bạn. (Điều này có thể sẽ không hiệu quả với bạn, vì bạn lưu ý rằng nó là một bản sao lưu)
• Đối với thông tin đăng nhập không mật khẩu trong tài khoản của bạn cho nhiều máy, tôi khuyên bạn nên tạo khóa mật khẩu cho từng máy bạn nhập và sử dụng tác nhân SSH để lưu trữ khóa trong bộ nhớ trong khi bạn sử dụng. Chuyển tiếp tác nhân sẽ cho phép bạn "nhảy" từ máy chủ đến máy chủ mà không cần tạo khóa trên mỗi máy chủ từ xa.
• Đối với các khóa SSH tự động, không mật khẩu, tôi khuyên bạn nên hạn chế các lệnh mà khóa có thể chạy. Trong authorized_keystệp của bạn , tiền tố mỗi khóa của bạn với:
  command="<allowed command line here>",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty

8-9 năm trước tôi đã làm việc trong một môi trường người dùng chung với hàng trăm người dùng cục bộ và thông tin đăng nhập dựa trên khóa SSH đã bị vô hiệu hóa do không có cách nào để thực thi chính sách mật khẩu trên các khóa. Miễn là bạn đang kiểm soát hoàn toàn kịch bản, ngày nay các khóa SSH chắc chắn tốt hơn là chỉ sử dụng mật khẩu.

Có, hầu hết các hướng dẫn trên internet dừng lại ở việc ssh không mật khẩu hoạt động, thay vì làm cho nó hoạt động an toàn. Hướng dẫn này thực hiện tốt công việc hiển thị những gì có thể được thực hiện để giảm thiểu rủi ro. Về cơ bản (để trích dẫn bài viết):

• tạo một tài khoản vai trò mục đích duy nhất cho công việc: tức là người dùng dnssynctrên mỗi máy
• nếu khả thi, hãy tạo các tệp có thể ghi bởi người dùng đó, thay vì dựa vào root
• đối với những bit thực sự cần quyền truy cập đặc quyền, hãy tạo một tập lệnh để thực hiện và sử dụng sudo
• sử dụng command=và from=các tùy chọn trong authorized_keystệp để hạn chế các khóa không có cụm mật khẩu
• để thực hiện chuyển tập tin, hãy viết một tập lệnh để thực hiện bằng rsync, trên máy nhận , để truy cập từ xa có thể ở chế độ chỉ đọc
• nếu điều này có nghĩa là cần truy cập trở lại máy khởi tạo từ máy từ xa, hãy sử dụng ssh-agentthay vì tạo khóa không có cụm mật khẩu thứ hai

Có một vài vấn đề với các phím ssh:

Không có cách tập trung để thu hồi một chìa khóa.

Không có cách nào để thực thi chính sách mật khẩu trên các khóa (khóa riêng của bạn có được mã hóa không và nếu có thì nó có được mã hóa bằng mật khẩu tốt không?).

Đây là những vấn đề kerberos giải quyết. Mặc dù vậy, nó giới thiệu những thứ khác, cụ thể là nó phức tạp hơn để thực hiện và đòi hỏi một cơ sở hạ tầng quản lý người dùng thực sự để triển khai và quản lý.

Trong mọi trường hợp, mặc dù authorized_keys ssh cho phép morris-sâu tấn công loại, nó vẫn là tốt hơn so với các dịch vụ .r và telnet bằng dặm (năm ánh sáng)

Trong bất kỳ môi trường nào mà tôi có quyền kiểm soát, tôi luôn là người gắn bó thực sự với đặc quyền tối thiểu có thể cho các tài khoản dịch vụ.

Trong trường hợp này, tôi khuyên bạn nên đảm bảo rằng tài khoản người dùng trên máy chủ từ xa chỉ được phép chạy một tập hợp thực thi nhỏ, được xác định chặt chẽ. Bạn có thể sử dụng nhiều tài khoản ở phía xa và sudo để thực hiện việc này.

Ngay cả trong trường hợp này, bạn vẫn phải chịu các lỗi leo thang đặc quyền địa phương, vì vậy hãy tỉ mỉ và theo dõi các lỗi bảo mật chặt chẽ.