Tôi có nên tạo khóa ssh riêng mới trên mỗi hệ thống không?


10

Tôi cần kết nối với nhiều máy chủ từ nhiều thiết bị thông qua SSH. Tôi tự hỏi liệu tôi có nên tạo một tệp id_dsa mới trên mỗi thiết bị mà tôi đang kết nối hay không, nếu không có vấn đề sao chép cùng một tệp id_dsa vào mỗi thiết bị.

Chẳng hạn, tôi có hệ thống máy tính để bàn dựa trên Ubuntu chính của mình và MacBook Pro với ssh. Và tôi có một Netbook dựa trên Windows với Putty được cài đặt. Và tôi có một điện thoại Android với ConnectBot. Từ bất kỳ một trong những thiết bị này, tôi có thể cần SSH vào hàng tá máy chủ vật lý và ảo khác nhau.

Mỗi máy chủ cần cài đặt khóa công khai của tôi. Ngoài ra, tài khoản GitHub và Codaset của tôi yêu cầu khóa chung của tôi.

Để đơn giản hóa việc quản lý khóa, tôi nghĩ đến việc sử dụng cùng một khóa riêng trên tất cả các hệ thống này. Đây có phải là thông lệ chung, hay tốt hơn là có một khóa riêng trên mỗi hệ thống?

Câu trả lời:


3

Nếu bạn sử dụng cùng một khóa chung trên mỗi hệ thống và khóa riêng sẽ bị xâm phạm, thì bất kỳ hệ thống nào sử dụng khóa đó, loại bỏ các hạn chế khác, sẽ có thể truy cập được.

Tôi tin rằng bạn đang sử dụng mật khẩu được bảo vệ khóa riêng?

Trong thực tiễn quản lý của chúng tôi, chúng tôi có "vai trò" bảo mật thấp, trung bình và cao. Mỗi vai trò sử dụng một khóa khác nhau. Khóa riêng bảo mật cao không bao giờ được truyền đến các tài sản bên ngoài, được sử dụng trên máy tính xách tay có thể bị mất / đánh cắp, v.v. Khóa bảo mật trung bình và thấp có thể được triển khai trong phạm vi rộng hơn.

Tôi đề nghị kiểm tra các mẫu sử dụng của bạn và xem những gì tạo nên từ vai trò bảo mật. Thiệt hại được thực hiện bằng cách lấy khóa riêng của bạn là gì?

Bạn đã xem xét việc đặt khóa riêng SSH của mình lên một thiết bị phần cứng mà từ đó nó không thể bị đánh cắp, loại bỏ sự thỏa hiệp tiềm năng của khóa thành vấn đề không?

Cả hai mô-đun bảo mật phần cứng và thẻ thông minh đều có thể được sử dụng để lưu trữ khóa riêng SSH một cách an toàn, cho phép tất cả các hoạt động mã hóa được thực hiện trên thiết bị, thay vì trên hệ điều hành của bạn. Tuy nhiên, chúng không phải là thuốc chữa bách bệnh, vì chúng cũng yêu cầu các thiết bị phần cứng dự phòng, trong trường hợp có lỗi phần cứng.


Có, chìa khóa của tôi được bảo vệ bằng mật khẩu. Cảm ơn câu trả lời của bạn. Bạn đã giúp xác nhận mối quan tâm của tôi rằng nếu tôi sử dụng cùng một khóa trên tất cả các thiết bị của mình, thì điều đó có thể dẫn đến những vấn đề lớn hơn.
Tauren

2

Tuyệt đối bạn nên. Bạn luôn có thể thêm tất cả các khóa vào tệp ủy quyền của bạn. Tôi thích đề nghị của jeffatrackaid. Tuy nhiên, tôi sẽ sử dụng các khóa riêng khác nhau cho mỗi thiết bị - tại sao không. Mất Android của bạn. Đơn giản, loại bỏ khóa khỏi danh sách các khóa được ủy quyền. Nếu bạn không, bạn sẽ phải tạo lại cấp khóa đó một lần nữa.

Điều đó nói rằng, nó phụ thuộc vào cách bạn nhận thức rủi ro của những tài sản này. Rõ ràng là bạn không muốn mất chìa khóa, nhưng một số bạn có thể gặp rủi ro lớn hơn, ví dụ như github so với root cho vps của bạn, ví dụ.


FYI, authorized_keys2đã lỗi thời từ năm 2001 - OpenSSH hiện sử dụng authorized_keys(mặc dù vẫn đọc cả hai tệp để tương thích)
user1686

À, cảm ơn Tôi luôn luôn đưa ra quan điểm về việc vô hiệu hóa SSHv1 và các mật mã có độ bền thấp, v.v.

2

Bạn có nhớ khi Debian gặp vấn đề về entropy nhỏ đó khi tạo khóa SSH không? Đó là lúc tôi học tốt bài học của mình.

Tôi có (các) khóa riêng của mình cho nội dung của riêng tôi, chẳng hạn như truy cập vào máy chủ cá nhân của tôi. Tôi có khóa "Tất cả mục đích" đưa tôi vào hầu hết các hộp phát triển của mình, sau đó cắt khóa cho mỗi khách hàng mà tôi phục vụ.

Tôi cũng giữ một danh sách rất chi tiết về các phím trên máy nào, chỉ trong trường hợp tôi phải thay thế hoặc gỡ bỏ chúng một cách vội vàng.

Đối với mọi thứ nghiêm trọng khác, tôi chỉ cần sử dụng LDAP / PAM, trong trường hợp tôi phải loại bỏ người khác một cách vội vàng.

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.