Làm cách nào để lưu trữ khóa SSH?

67

Tôi đã bắt đầu sử dụng các khóa SSH thay vì mật khẩu chỉ gần đây (tất nhiên là nhờ GitHub), vì vậy hãy nhớ rằng tôi khá mới đối với toàn bộ khái niệm này. Hiện tại các khóa của tôi chỉ đơn giản nằm dưới ~ / .ssh, nhưng tôi không chắc liệu đây có phải là một thực hành tốt hay không. Ví dụ: nếu tôi có nhiều máy, tôi cần sao chép khóa riêng của mình, điều mà tôi nghĩ là không mong muốn. Hoặc, nếu ổ cứng của tôi bị hỏng, thì tôi sẽ mất các phím đó, điều mà tôi đoán là điều không mong muốn.

Vậy, những cách tốt nhất để lưu trữ khóa SSH một cách an toàn, thuận tiện và đáng tin cậy là gì?

Có vẻ như sử dụng thẻ thông minh là một tùy chọn (xem Thẻ thông minh để lưu trữ khóa gpg / ssh (Linux) - tôi cần gì? ), Đây có phải là cách tốt nhất không?

Cập nhật: Lý do cho câu hỏi là nhiều dịch vụ (như GitHub, AWS EC2) cung cấp hướng dẫn về cách thiết lập các khóa SSH để sử dụng dịch vụ, nhưng không có nền tảng (như, phải làm gì nếu bạn đã tạo khóa bởi ssh-keygen[1], các biện pháp bảo mật được khuyến nghị là gì). Và không rõ liệu thông tin đó thực tế không quan trọng hay bạn dự kiến sẽ biết nó 'theo mặc định'.

Để tổng hợp các câu trả lời cho đến thời điểm này (nhưng vui lòng đọc chúng và nếu bạn có điều gì đó cần thêm thì vui lòng làm): có vẻ như trong trường hợp này sẽ ổn nếu bạn chỉ để các khóa riêng của mình trong ~ / .ssh, miễn là bạn giữ họ khỏi những người khác; nhưng hãy chắc chắn rằng bạn có một cách khác để truy cập dịch vụ để tải lên hoặc tạo khóa mới nếu bạn mất một khóa (thường là như vậy).

[1] GitHub được sử dụng để cung cấp trợ giúp về cách quản lý nhiều khóa .

security ssh-keys

— Anton Strogonoff
nguồn

Liên kết đó dường như bị hỏng help.github.com/multipl-ssh-keys

— KJ Giá

@KJ Price, nhờ vào Wayback Machine của Internet Archive , trang vẫn có sẵn trực tuyến, mặc dù không phải ở liên kết ban đầu. Một bản sao của trang được lưu trữ vào ngày 2 tháng 9 năm 2011 có thể được tìm thấy tại nhiều khóa SSH .

— moonpoint

41

Ví dụ: nếu tôi có nhiều máy, tôi cần sao chép khóa riêng, điều mà tôi nghĩ là không mong muốn.

Không, thực sự bạn không. Nếu bạn có nhiều máy, bạn chỉ cần tạo một khóa riêng trên mỗi máy. Đối với mỗi khóa riêng, chỉ cần tải lên khóa chung tương ứng lên GitHub bằng cùng một quy trình.

Ngoài ra, nếu ổ cứng của tôi bị hỏng, tôi sẽ mất khóa riêng, điều này (tôi đoán vậy) là điều không mong muốn.

Không thực sự; nếu bạn mất khóa riêng, chỉ cần tạo một khóa mới và tải lên khóa chung tương ứng.

Đối với những gì nó có giá trị, bạn có quyền sao chép khóa riêng là rất không mong muốn. Lý tưởng nhất, một khóa riêng phải được tạo trong một tệp ( ~/.ssh/id_rsaví dụ) và không bao giờ được rời khỏi tệp đó - nghĩa là không bao giờ được sao chép, di chuyển và đặc biệt là không được chuyển qua mạng. (ví dụ: tôi loại trừ chúng khỏi các bản sao lưu) Do bản chất của các giao thức xác thực không đối xứng, bạn chỉ cần lo lắng về việc giữ khóa riêng của mình khỏi tay người khác. Nếu bạn hơi quá nhiệt tình và bạn mất dấu vết của chính mình, nó thường không phải là một vấn đề lớn. (Điều này không bị nhầm lẫn với các khóa riêng mã hóa không đối xứng , ví dụ như khóa GPG, mà bạn có thể muốn giữ.)

— David Z
nguồn

14

Điều này chỉ hoạt động nếu bạn có một số phương pháp khác để truy cập các máy chủ mà khóa riêng cung cấp quyền truy cập. Bạn chỉ có thể tải lên khóa công khai mới nếu bạn có quyền truy cập sao lưu đó.

— TREE

2

@TREE: đúng, nhưng theo kinh nghiệm của tôi, thật hiếm khi tìm thấy một máy chủ không cung cấp một số phương thức truy cập thay thế (hoặc ít nhất là thêm một khóa công khai bổ sung mà không cần thông qua SSH).

— David Z

3

Cảm ơn, điều đó xóa mọi thứ lên rất nhiều. Thực sự, việc mất khóa SSH riêng không giống như một vấn đề, vì đối với tất cả các dịch vụ tôi đang sử dụng dường như luôn có một cách khác để truy cập dịch vụ để tải lên một dịch vụ mới.

— Anton Strogonoff

3

AWS không cung cấp bất kỳ hình thức truy cập nào khác ngoài khóa riêng. Bạn phải ngắt kết nối ổ đĩa và đánh lừa nó để có quyền truy cập khi bạn mất khóa riêng.

— Asad Saeeduddin

1

Lưu ý rằng bạn có thể đặt mật khẩu vào khóa riêng của mình nếu bạn muốn một lớp bảo mật khác.

— sudo

8

Tôi sẽ thêm rằng ~ / .ssh / có thể đọc được bởi trình duyệt của bạn nếu bạn đang sử dụng cùng một tài khoản người dùng để chạy cả hai.

Thử nó! Trỏ trình duyệt của bạn đến khóa riêng trong thư mục nhà của bạn. Nó vui.

Vì vậy, tôi khuyên bạn nên lưu trữ khóa ssh trong thư mục chính của tài khoản người dùng khác.

một từ trên khóa bảo vệ cụm mật khẩu

Ngày nay, việc bẻ khóa mật khẩu không ngẫu nhiên là siêu nhanh. Kiểm tra băm mèo
- (Mặc dù mật khẩu 12+ ngẫu nhiên và dài vẫn mất nhiều thời gian hợp lý để mạnh mẽ)
- Vì vậy, các khóa ssh được mã hóa AES là không thể bẻ khóa trong tương lai gần, miễn là bạn sử dụng các mật khẩu dài tốt. Xem khuyến nghị của github
Vì vậy, một số trang web có thể đoán lấy khóa của bạn với JavaScript. Và sau đó vũ phu dùng chìa khóa nhé.
Và các trình duyệt cũng có thể nhìn vào Clipboard của bạn w / JS. Vì vậy, việc sao chép các cụm mật khẩu rất dài cũng khiến bạn gặp rủi ro từ các cuộc tấn công javascript phức tạp hơn.

look_at_keys.html

 9 <HTML>
10 <HEAD>
11 <TITLE>look at keys</TITLE>
12 </HEAD>
13 <FRAMESET cols="20%, 80%">
14   <FRAMESET rows="100, 200">
15       <FRAME src="/Users/yourname/.ssh/stuff.pem">
16       <FRAME src="blah.html">
17   </FRAMESET>
18   <FRAME src="contents_of_frame3.html">
19 </FRAMESET>
20 </HTML>

— HeyWatch This
nguồn

17

Để rõ ràng, chỉ vì trình duyệt có thể đọc khóa riêng của bạn, điều đó không có nghĩa là một trang web đang chạy trong trình duyệt có thể.

— Ajedi32

6

Nhưng, nếu bạn tiêm một quy trình trong quy trình của trình duyệt. Sau đó, bạn có thể kiểm soát trình duyệt là tốt. Vì vậy, lập luận này là hoàn toàn hợp lệ.

— BigSack

Nhưng sau đó, bạn phải hack quy trình đưa các quy trình vào sổ đăng ký quy trình của đơn vị xử lý trình duyệt của bạn.

— Trượt Kadda

8

Có một công cụ rất đẹp tên là KeePass2 ( http://keepass.info/ ) với phần mở rộng ( http://lechnology.com/software/keeagent/ )

Bạn có thể lưu trữ Mật khẩu, Khóa SSH và nhiều hơn nữa (trên trang KeePass chính thức là các tiện ích mở rộng hữu ích hơn rất nhiều)
Nếu bạn muốn đăng nhập tự động với Khóa SSH, bạn chỉ cần cài đặt PuTTY, Pageant và KeePass với KeeAgent. Nếu bạn định cấu hình chính xác, bạn không phải thiết lập Khóa trong PuTTY, Pagete hoặc FileZilla.

Tôi sử dụng nó cho mình và tôi khá hài lòng về nó. Tôi có hơn 30 VPS và Root Server với một số Khóa SSH khác nhau và điều duy nhất tôi phải làm là mở KeePass (Nó không phải là Mật khẩu chính của tôi) và sau đó tôi chỉ cần nhập vào bảng điều khiển mật khẩu của mình.

— CentrixDE
nguồn

3

Tôi khuyên bạn nên lưu trữ khóa riêng:

ngoại tuyến (không phải trên đám mây)
ở nhiều nơi
ngoài mọi thứ liên quan đến, ví dụ: khóa cho dữ liệu được mã hóa của bạn, hãy lưu trữ nó ở một nơi riêng biệt với dữ liệu

Tôi muốn nói, nơi tốt nhất sẽ là:

một ổ cứng ngoài
một phím flash
một máy tính không được cắm vào internet

Thậm chí tốt hơn, chỉ cần in nó ra, và đặt nó trong một an toàn chống cháy.

— blah
nguồn

4

An ninh / thực hành tốt nhất làm việc đi đôi với thực tiễn. Nếu một chiến lược bảo mật cản trở khả năng sử dụng một hệ thống, nó sẽ bị người dùng bỏ qua chứ không phải kẻ tấn công.

— zaTricky

1

Tôi có một tệp tar có cài đặt thư mục người dùng của tôi (.bashrc, .ssh / và các tệp cấu hình khác) mà tôi giữ ở nơi an toàn. Khi tôi nhận được một tài khoản shell mới ở bất cứ đâu, tôi giải nén tệp tar vào nó.

Bạn chỉ nên đặt khóa riêng của mình lên máy chủ mà bạn tin tưởng, nếu không, bạn nên tạo khóa riêng mới trên máy chủ chỉ cho máy chủ đó và cho phép nó truy cập vào những thứ bạn muốn nó có quyền truy cập.

Cá nhân, tôi cảm thấy thoải mái khi chỉ sao chép .ssh / nội dung của mình ở mọi nơi (điều đó cũng có nghĩa là khóa ssh thông thường sẽ có quyền truy cập ssh ngay lập tức, vì nó đã có trong tệp ủy quyền).

— EightBitTony
nguồn

Tôi đoán rằng, việc mã hóa ~ / .ssh được treo xung quanh trên thanh usb sẽ tiết kiệm được nhu cầu tạo và tải lên khóa mới trong trường hợp xảy ra lỗi phần cứng. Tuy nhiên, vì có rất ít máy chủ mà tôi sử dụng khóa SSH để truy cập (và rất ít máy tôi kết nối từ đó), việc tạo khóa mới sẽ không gây ra nhiều chi phí.

— Anton Strogonoff

2

Đó là ngựa cho các khóa học và phụ thuộc vào lý do tại sao bạn sử dụng các phím. Tôi không thấy vấn đề sao chép khóa riêng ssh qua liên kết SSH đã được mã hóa. Nhưng nếu bạn không tin tưởng vào máy mục tiêu và không biết ai có quyền truy cập root, bạn không nên đặt bất cứ thứ gì lên máy chủ mà bạn không đủ khả năng để mất.

— EightBitTony

Bạn không muốn đặt khóa riêng của mình trên máy chủ của người khác. Bất cứ ai có quyền truy cập Root trên máy chủ đó đều có thể đọc khóa riêng của bạn và sau đó họ có thể mạo danh bạn trên các hệ thống mà bạn truy cập bằng khóa riêng đó. Bạn chỉ nên đặt khóa công khai để truy cập vào máy chủ. Và đừng nghĩ rằng cụm mật khẩu sẽ giúp ích rất nhiều nếu bạn đang sử dụng nó trên một máy từ xa để giải mã khóa riêng.

— Codeguy007

Bạn có thể chuyển tiếp ssh-agent qua ssh. Bằng cách đó, bạn không cần lưu trữ khóa riêng trên máy chủ hoặc gửi cụm mật khẩu của mình qua mạng. stackoverflow.com/questions/12257968/

— Mạnh

1

Bạn có thể lưu trữ các khóa ssh của mình trong một thư mục riêng bên trong một phân vùng được mã hóa. Sau đó, bạn có thể sử dụng ssh trỏ đến thư mục đó với -i:

ssh -i identity_file me@example.com

Mô tả đầy đủ ( man ssh):

-i nhận dạng_file

Chọn một tệp mà từ đó nhận dạng (khóa riêng) để xác thực khóa chung được đọc. Mặc định là ~ / .ssh / nhận dạng cho giao thức phiên bản 1 và ~ / .ssh / id_dsa, ~ / .ssh / id_ecdsa, ~ / .ssh / id_ed25519 và ~ / .ssh / id_rsa cho phiên bản giao thức 2. Các tệp nhận dạng có thể cũng được chỉ định trên cơ sở từng máy chủ trong tệp cấu hình.
Có thể có nhiều tùy chọn -i (và nhiều danh tính được chỉ định trong tệp cấu hình). Nếu không có chứng chỉ nào được chỉ định rõ ràng bởi chỉ thị certFile, ssh cũng sẽ cố gắng tải thông tin chứng chỉ từ tên tệp thu được bằng cách thêm -cert.pub vào tên tệp.

Cách tiếp cận của tôi đối với bảo mật là tôi chia thông tin thành riêng tư và chung chung. Tôi không muốn mã hóa toàn bộ phân vùng nhà của mình, đó là lý do tại sao tôi sao chép các tệp bí mật (như các tệp trong ~/.ssh) vào một phân vùng được mã hóa.

Tôi nghĩ rằng điều này mang lại một số bảo mật khá hiệu quả, vì phần mềm độc hại sẽ không tìm thấy bất cứ thứ gì trong ~ / .ssh và có lẽ nó sẽ không quét toàn bộ hệ thống hoặc cấu hình shell của bạn để tìm vị trí đó.

-F configfile

đặt đường dẫn đến tập tin cấu hình.

PS Tôi sẽ tạo một bí danh alias ssh='ssh -i ... -F ...'và đưa nó vào hồ sơ của bạn.

PPS Tôi chưa kiểm tra điều này và tôi không biết các chương trình khác (như git) sẽ hoạt động như thế nào với các cài đặt ssh này.

— Nam Tư Nikitenko
nguồn