Quản trị viên máy chủ đã gửi cho tôi một khóa riêng để sử dụng. Tại sao?


73

Tôi phải truy cập vào một máy chủ để liên kết các máy chủ dàn dựng và trực tiếp của một công ty vào vòng triển khai của chúng tôi. Một quản trị viên về phía họ thiết lập hai trường hợp và sau đó tạo một người dùng trên máy chủ để chúng tôi SSH vào. Điều này nhiều tôi đã quen.

Trong tâm trí tôi bây giờ điều gì sẽ xảy ra là tôi sẽ gửi cho họ khóa công khai của tôi có thể được đặt trong thư mục khóa được ủy quyền của họ. Tuy nhiên, thay vào đó họ đã gửi cho tôi một tên tệp id_rsamà bên trong tệp chứa -----BEGIN RSA PRIVATE KEY-----qua email. Điều này có bình thường không?

Tôi nhìn xung quanh và có thể tìm thấy hàng tấn tài nguyên khi tạo và thiết lập các khóa của riêng tôi từ đầu, nhưng không có gì về việc bắt đầu từ các khóa riêng của máy chủ. Tôi có nên sử dụng cái này để tạo một số khóa cho chính mình hay không?

Tôi sẽ hỏi quản trị viên hệ thống trực tiếp nhưng không muốn xuất hiện một thằng ngốc và lãng phí thời gian của mọi người ở giữa chúng ta. Tôi có nên bỏ qua khóa anh ấy gửi cho tôi và yêu cầu họ đưa khóa công khai của tôi vào thư mục được ủy quyền của họ không?


6
Tôi sẽ không gọi nó là bình thường hoặc lành mạnh, nhưng vì bạn có khóa riêng (giả sử họ đã thêm nó như được ủy quyền), bạn có thể sử dụng nó như bạn sẽ sử dụng bất kỳ khóa riêng nào khác. Bạn không cần khóa công khai tương ứng, nhưng nếu bạn muốn, bạn luôn có thể tạo nó: Askubfox.com/a/53555/158442
muru

34
Nhận -----BEGIN RSA PRIVATE KEY-----qua e-mail là điều đáng sợ tiếp theo sau khi thấy một người dùng có tên '); DROP DATABASE;--trong bảng tên người dùng của bạn.
Dmitry Grigoryev

62
@DmitryGrigoryev không có gì đáng sợ khi xem '); DROP DATABASE;--là tên người dùng trong bảng cơ sở dữ liệu của bạn - nó cho thấy bạn đã thoát chính xác đầu vào của người dùng
HorusKol 7/12/2016

19
Bạn chắc chắn không thể 'sử dụng nó như bạn sẽ sử dụng bất kỳ khóa riêng nào khác'. Cái này không riêng tư. Ergo nó không thể thực hiện được chức năng mà nó được tạo ra. Nó nên được ném đi và quản trị viên UNIX bị trừng phạt nghiêm trọng. @muru
user207421

7
Bất cứ ai có khóa riêng này đều có quyền truy cập vào các máy chủ mới. Có lẽ quản trị viên vẫn có quyền truy cập mà không cần khóa, vì họ có thể thiết lập máy chủ, do đó không có thêm mối đe dọa nào đối với quyền truy cập trái phép của anh ta. Tuy nhiên, vì đây là chìa khóa của bạn nên giờ đây anh ta có thể mạo danh bạn một cách đáng tin cậy. Cũng có khả năng ai đó không phải bạn đọc email, và sau đó họ cũng có thể mạo danh bạn.
dùng253751

Câu trả lời:


116

Trong tâm trí tôi bây giờ điều gì sẽ xảy ra là tôi sẽ gửi cho họ khóa công khai của tôi có thể được đặt trong thư mục khóa được ủy quyền của họ.

Những gì "trong tâm trí của bạn" như những gì nên xảy ra là chính xác.

Email không phải là một kênh liên lạc an toàn, vì vậy từ quan điểm bảo mật thích hợp, bạn (và họ) nên xem xét rằng khóa riêng bị xâm phạm.

Tùy thuộc vào kỹ năng kỹ thuật của bạn và cách bạn muốn trở thành ngoại giao, bạn có thể làm một số điều khác nhau. Tôi muốn giới thiệu một trong những điều sau đây:

  1. Tạo cặp khóa của riêng bạn và đính kèm khóa chung vào email bạn gửi cho họ, nói:

    Cảm ơn! Vì email không phải là phương thức phân phối an toàn cho khóa riêng, thay vào đó, bạn có thể vui lòng đặt khóa công khai của tôi không? Nó được đính kèm.

  2. Cảm ơn họ và hỏi họ xem họ có phản đối việc bạn cài đặt khóa riêng của bạn không, vì khóa riêng họ đã gửi nên được xem là bị xâm phạm sau khi được gửi qua email.

    Tạo khóa riêng của bạn, sử dụng khóa họ đã gửi cho bạn để đăng nhập lần đầu tiên và sử dụng quyền truy cập đó để chỉnh sửa authorized_keystệp để chứa khóa chung mới (và xóa khóa chung tương ứng với khóa riêng bị xâm nhập.)

Điểm mấu chốt: Bạn sẽ không trông như một thằng ngốc. Nhưng, quản trị viên khác có thể được tạo ra để trông giống như một thằng ngốc rất dễ dàng. Ngoại giao tốt có thể tránh điều đó.


Chỉnh sửa để phản hồi các bình luận từ MontyHarder:

Cả hai khóa hành động được đề xuất của tôi đều liên quan đến việc "sửa chữa mọi thứ mà không nói cho quản trị viên khác biết anh ta đã làm gì sai"; Tôi chỉ làm một cách tinh tế mà không ném anh ta dưới xe buýt.

Tuy nhiên, tôi sẽ nói thêm rằng tôi cũng sẽ theo dõi (một cách lịch sự) nếu những manh mối tinh tế không được chọn:

Xin chào, tôi thấy bạn đã không trả lời nhận xét của tôi về email là một kênh không an toàn. Tôi muốn tự tin rằng điều này sẽ không xảy ra lần nữa:

Bạn có hiểu tại sao tôi đưa ra quan điểm này về việc xử lý an toàn các khóa riêng không?

Tốt,

Toby


9
+1 Câu trả lời hay nhất. Và tôi thêm: hãy đặc biệt cẩn thận vì sysadmin này đã được chứng minh là không đủ năng lực. Tốt hơn là bạn nên che lưng khi (và không nếu ) anh ấy / cô ấy sẽ làm hỏng máy chủ mãi mãi.
dr01

2
Cảm ơn. Tôi đã sử dụng một số cụm từ tinh tế và gửi khóa công khai của mình. Mọi chuyện có vẻ đã được giải quyết nhưng tôi sẽ hủy cấp lại chìa khóa mà anh ấy đã gửi cho tôi ngay bây giờ.
Toby

27
Không phải là quản trị viên khác "có thể trông giống như một thằng ngốc". Đó là quản trị viên khác đã làm điều gì đó ngu ngốc. Tôi chỉ có thể nghĩ về một kịch bản theo đó một khóa riêng được chia sẻ giữa các máy và đó là nơi một nhóm máy chủ được truy cập thông qua cùng tên (độ phân giải DNS vòng tròn, v.v.) và phải xuất trình cùng Khóa máy chủ SSH để quy trình tự động sẽ chấp nhận rằng chúng là tên đó. Và trong trường hợp đó, cùng một người sẽ là quản trị viên của tất cả các máy chủ và sẽ xử lý các giao dịch chuyển mà không có bên ngoài tham gia.
Monty Harder

21
@zwol Trong công việc của tôi, chúng tôi có một triết lý "không có lỗi" để hiểu rằng chúng tôi sẽ phạm sai lầm, nhưng ưu tiên cao là không mắc lỗi tương tự hai lần. Nhưng để không mắc lỗi tương tự hai lần, bạn phải biết đó là một lỗi, đó là lý do tại sao tôi không thể bỏ phiếu cho các câu trả lời đề nghị OP chỉ sửa chữa mọi thứ mà không nói cho quản trị viên khác biết anh ta đã làm gì sai. Tôi đã chọn cách gọi sai lầm là 'ngu ngốc' thay vì gọi chính xác tên quản trị viên vì lý do bạn phác thảo. (Nhưng tôi không chắc chắn kết luận về cha mẹ của bạn nói lên một sự khác biệt có ý nghĩa.)
Monty Harder

8
@LightnessRacesinOrbit, tôi nghi ngờ bạn có thể có một sự hiểu biết không đầy đủ về ý nghĩa của "ngoại giao". Bạn đã thử xóa nó trong một từ điển tốt, chẳng hạn như Từ điển quốc tế mới thứ ba của Webster chưa?
tự đại diện

34

Tôi có nên bỏ qua khóa anh ấy gửi cho tôi và yêu cầu họ đưa khóa công khai của tôi vào thư mục được ủy quyền của họ không?

Vâng, đó chính xác là những gì bạn nên làm. Điểm chung với khóa riêng là chúng là riêng tư , nghĩa là chỉ bạn mới có khóa riêng. Vì bạn đã nhận được khóa đó từ quản trị viên, anh ta cũng có nó. Vì vậy, anh ta có thể mạo danh bạn bất cứ lúc nào anh ta muốn.

Cho dù khóa được gửi cho bạn qua kênh an toàn hay không đều không liên quan: ngay cả khi bạn đã nhận được khóa riêng của mình, điều đó sẽ không thay đổi bất cứ điều gì. Mặc dù tôi đồng ý với các ý kiến ​​rằng e-mail khóa mật mã nhạy cảm là anh đào trên bánh: quản trị viên của bạn thậm chí không giả vờ có một loại chính sách bảo mật nào đó.


6
Và vì OP không có cách nào để biết máy của quản trị viên an toàn đến mức nào (từ câu chuyện, có lẽ rất không an toàn), anh ta nên cho rằng khóa riêng là (hoặc sẽ) bị rò rỉ cho người khác. Gửi một khóa riêng qua email chỉ là một thực tế thưởng cho sự không biết gì về infosec.
dr01

1
Bạn có thể cho rằng một quản trị viên có khả năng tạo người dùng sẽ không cần khóa riêng của bạn để mạo danh bạn.
Tối đa

3
@MaxRied Điều đó có thể khó thực hiện với nhật ký bảo mật thích hợp. Với khóa riêng của bạn, anh ta thậm chí không cần phải giả lập nhật ký. Nó giống như có khả năng thiết lập lại mật khẩu của bạn so với biết mật khẩu của bạn.
Dmitry Grigoryev

@DmitryGrigoryev Anh ấy luôn có thể thêm một khóa khác vào tệp ủy quyền của bạn ...
Max Ried

4
@MaxRied Tôi đã đề cập đến /var/log/securehoặc tương tự , tôi khá chắc chắn rằng trò lừa không gian sẽ không đánh lừa điều này.
Dmitry Grigoryev

14

Đối với tôi, có vẻ như quản trị viên đã tạo một cặp khóa riêng / chung cho bạn, đã thêm khóa chung vào ủy quyền và gửi cho bạn khóa riêng. Bằng cách này, bạn chỉ phải sử dụng khóa riêng này cho các phiên ssh của mình với máy chủ. Không cần phải tự tạo một cặp khóa hoặc gửi cho quản trị viên một khóa chung tới khóa riêng của bạn có thể bị hỏng (luôn nghĩ trường hợp xấu nhất: P).

Tuy nhiên, tôi sẽ không tin tưởng khóa riêng được gửi cho bạn qua thư không được mã hóa.

Cách tiếp cận của tôi sẽ là: sử dụng khóa riêng để đăng nhập một lần, thêm khóa công khai của riêng bạn vào ủy quyền trên máy chủ (thay thế khóa chung gốc) và vứt khóa riêng tư email này. Sau đó, bạn có thể cảm ơn quản trị viên rằng anh ấy / cô ấy đã cung cấp cho bạn khóa riêng nhưng bạn muốn thông tin / khóa đó không được gửi qua email (/ cả).


3
@Toby Lý do duy nhất tôi có thể tưởng tượng khi họ gửi khóa riêng là họ không hiểu các công cụ họ đang sử dụng. Và bạn có thể sử dụng -itrên dòng lệnh để chọn khóa riêng nào sẽ sử dụng.
kasperd

18
@kasperd Lý do tôi có thể tưởng tượng là một sysadmin đã làm việc quá sức, người đã quyết định rằng rủi ro của việc gửi khóa riêng qua email sẽ lớn hơn bởi những rắc rối khi cố gắng giải thích cho những người dùng kém hiểu biết về cách tạo một cặp khóa và gửi khóa công khai trở lại.
mattdm

1
Điểm tuyệt vời mà bạn có thể tự khắc phục điều này. Tốt hơn là tự làm điều đó ngay lập tức hơn là chờ quản trị viên cài đặt khóa chung cho một khóa mới. Tránh sử dụng khóa riêng không còn bí mật sẽ không giúp được gì; nó chỉ cung cấp cho bất kỳ kẻ nghe trộm tiềm năng nào lâu hơn để sử dụng nó trước khi bạn có thể vào và gỡ bỏ nó authorized_keys(sau khi thêm + kiểm tra chính bạn).
Peter Cordes

4
@mattdm Điều đó ... hoàn toàn hợp lý, nhưng đáng sợ. Một người không thể tạo cặp khóa và gửi cho tôi khóa công khai có lẽ sẽ không làm tốt hơn với khóa riêng tôi đưa cho anh ta.
Monty Harder

1
@mattdm, đủ công bằng nhưng vì tôi là người yêu cầu anh ấy làm tất cả những điều này nên tôi thấy khó tin rằng anh ấy nghĩ tôi không biết cách kết nối với ssh. Nếu bất cứ điều gì các bước anh ấy thực hiện là khó hiểu hơn vì tôi chỉ biết cách sử dụng khóa chung chung cơ bản. : x
Toby
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.