Tại sao tôi nên sử dụng Xác thực khóa công khai cho SSH?

Tôi đang chạy một máy chủ SSH và tôi vẫn đang sử dụng xác thực mật khẩu đơn giản. Ở mọi nơi tôi đọc về bảo mật, tôi được khuyên nên sử dụng Xác thực khóa công khai. Nhưng tôi không có được lợi thế. Sử dụng chúng là, trong mắt tôi, hoặc là không an toàn hoặc rất nhiều công việc tiện dụng.

Tất nhiên, nếu ai đó cố gắng bắt buộc đăng nhập vào máy chủ SSH của tôi thì Khóa công khai mạnh hơn bất kỳ mật khẩu nào. Nhưng bên cạnh đó, nó hoàn toàn không an toàn.

Các cố vấn chủ yếu lập luận rằng bạn không cần phải nhớ mật khẩu. Làm thế nào là không an toàn? Vì vậy, nếu ai đó xâm nhập vào máy tính của tôi, anh ta không nhận được máy tính của tôi, nhưng máy chủ của tôi cũng vậy? Nếu tôi đang sử dụng SSH từ nhiều khách hàng khác nhau, tôi phải lưu trữ các khóa công khai một trong số chúng, điều này sẽ nhân lên khả năng chúng rơi vào tay kẻ xấu. Tôi có thể lưu chúng trên một thanh USB mà tôi mang theo, nhưng nó có thể bị mất và người tìm thấy có quyền truy cập vào máy chủ của tôi.

Có thể tôi được phục vụ tốt hơn với Xác thực hai yếu tố.

Có bất kỳ đối số tôi đang thiếu? Cách tốt nhất cho tôi là gì?

nếu ai đó xâm nhập vào máy tính của tôi, anh ta không nhận được máy tính của tôi, nhưng máy chủ của tôi cũng vậy?

Điều này có khả năng đúng dù sao với keylogger: ngay khi bạn đăng nhập vào máy chủ của mình từ máy tính bị xâm nhập, họ sẽ nhận được mật khẩu.

Nhưng có 3 lợi thế cho các phím:

1) Xác thực có thể lưu. Nhập cụm mật khẩu của bạn một lần, thực hiện nhiều lệnh ssh. Điều này rất hữu ích nếu bạn đang sử dụng thứ gì đó sử dụng ssh làm phương tiện giao thông, như scp, rsync hoặc git.

2) Xác thực mở rộng. Nhập cụm mật khẩu của bạn một lần, đăng nhập vào nhiều máy . Bạn càng có nhiều máy móc, điều này càng hữu ích. Nếu bạn có 100 máy, bạn sẽ làm gì? Bạn không thể sử dụng cùng một mật khẩu (trừ khi đó là trang trại nhân bản) và bạn không thể nhớ nhiều mật khẩu đó. Vì vậy, bạn phải sử dụng trình quản lý mật khẩu và bạn sẽ quay lại điểm thỏa hiệp duy nhất. Thực tế, mật khẩu chính là trình quản lý mật khẩu của bạn.

2b) Nó chia tỷ lệ theo cách khác nếu bạn có nhiều quản trị viên sử dụng cùng một hệ thống, bởi vì bạn có thể thu hồi các khóa từ người dùng A mà không phải thông báo cho B, C, D, E, F ... rằng mật khẩu đã thay đổi.

(Điều này cũng có thể được thực hiện với các tài khoản cá nhân và sudo, nhưng sau đó bạn phải cung cấp các tài khoản đó bằng cách nào đó)

3) Tự động hóa và ủy quyền một phần. Bạn có thể thiết lập SSH để chạy một lệnh cụ thể khi khóa kết nối . Điều này cho phép một quy trình tự động trên hệ thống A thực hiện điều gì đó trên hệ thống B mà không có sự tin tưởng hoàn toàn về mật khẩu giữa hai bên.

(Đây là một sự thay thế cho rlogin / rsh, không an toàn)

Chỉnh sửa: một lợi thế khác cho khóa công khai thay vì mật khẩu là tình huống phổ biến trong đó máy chủ bị xâm nhập thông qua lỗ hổng. Trong trường hợp này, đăng nhập bằng mật khẩu sẽ làm hỏng mật khẩu ngay lập tức. Đăng nhập bằng một khóa không! Tôi muốn nói rằng điều này là phổ biến hơn so với máy tính để bàn có nguồn gốc của quản trị viên bị xâm phạm.

Nếu bạn đang sử dụng mật khẩu tốt, điều này có thể đủ an toàn. Tôi thường giới hạn số lượng máy chủ có thể truy cập công khai ở mức tối thiểu và cho phép SSH từ (các) IP cụ thể bất cứ khi nào có thể.

Ngoài ra, bạn có thể bảo vệ các khóa của mình bằng cụm mật khẩu (mật khẩu). Vì vậy, cụm mật khẩu này phải được nhập bất cứ khi nào bạn cần đăng nhập vào (các) máy chủ của mình. Sau đó, không ai có thể sử dụng khóa của bạn trừ khi cụm mật khẩu đúng được cung cấp.

Có những bài viết tương tự:

1. Đăng từ serverfault .
2. Bài đăng từ stackexchange an ninh .
3. Bài đăng từ superuser .

Một cách mà ủy quyền khóa công khai an toàn hơn là khi kẻ tấn công quản lý trung gian (MitM) giữa máy khách của bạn và máy chủ và bạn không nhận thấy khóa máy chủ thay đổi (có thể do bạn đã không thay đổi Không có khóa cũ, ví dụ vì đây là lần đầu tiên sử dụng máy khách cụ thể này).

(Điều tương tự cũng áp dụng khi kẻ tấn công quản lý để kiểm soát máy chủ và có những máy chủ khác có cùng thông tin đăng nhập.)

Với xác thực dựa trên mật khẩu tiêu chuẩn, bạn đang gửi mật khẩu (bên trong kết nối được mã hóa) bằng văn bản thuần túy, máy chủ chính hãng sẽ thường băm nó và so sánh kết quả với hàm băm được lưu trữ trong cơ sở dữ liệu mật khẩu của nó. Kẻ tấn công MitM thay vào đó có thể lấy mật khẩu này, mở kết nối đến máy chủ thực và đăng nhập vào đó ... và chuyển tiếp nội dung cho bạn (để bạn không nhận thấy bất cứ điều gì), hoặc chỉ làm những thứ xấu xa của riêng mình trên máy chủ của bạn .

Với xác thực khóa công khai, máy khách về cơ bản đang ký một số dữ liệu được cả máy chủ và máy khách biết để chứng minh rằng nó đang sở hữu khóa riêng và gửi chữ ký đến máy chủ. Dữ liệu đã ký này bao gồm một mã định danh phiên, phụ thuộc vào số ngẫu nhiên được chọn bởi cả máy khách và máy chủ và do đó khác nhau cho mỗi phiên. Nếu MitM mở kết nối SSH của riêng mình đến máy chủ thực, thì người đó sẽ có ID phiên khác và do đó chữ ký do khách hàng cung cấp sẽ không hoạt động ở đó.

Tất nhiên, như các câu trả lời khác đã nói, bạn cần bảo mật khóa riêng của mình, ví dụ được mã hóa bằng cụm mật khẩu hoặc có thể trên một thiết bị riêng biệt chỉ tạo chữ ký sau khi nhập mã PIN.

OpenSSH có thể giữ CA riêng của mình để quản lý khóa máy chủ và máy khách SSH và có thể sử dụng danh sách hủy bỏ trên chúng. Điều này có thể thêm vào bảo mật được cung cấp bởi xác thực dựa trên khóa.

Bạn đã đúng về yêu cầu "bạn không cần mật khẩu". Điều đó thực sự không an toàn về phía khách hàng.

Điều khiến cho việc chỉ cho phép các khóa công khai để đăng nhập an toàn hơn nhiều là thực tế là không có cách nào để bắt buộc truy cập vào máy chủ của bạn. Tất cả những gì kẻ tấn công có thể đạt được là đặt một số tải lên máy chủ của bạn - bạn có thể sử dụng fail2ban để kiểm tra điều đó.

Để bảo mật về phía máy khách, bạn phải bảo vệ khóa riêng bằng cụm từ tốt. Tất nhiên bây giờ kết nối với máy chủ là cồng kềnh hơn so với mật khẩu. Để khắc phục điều này, bạn có thể sử dụng tác nhân ssh để lưu trữ khóa riêng trong bộ nhớ nếu bạn có ý định kết nối với máy chủ nhiều lần liên tiếp. Đó là một thực hành tốt để giới hạn thời gian trong bao lâu một khóa sẽ được lưu trong bộ nhớ.

Có thể tôi được phục vụ tốt hơn với Xác thực hai yếu tố.

Một khả năng cho 2FA cho SSH (và một khả năng yêu cầu thiết lập / độ phức tạp tương đối ít) trên thực tế là sử dụng khóa chung và mật khẩu.

Tôi tin rằng một cái gì đó dọc theo dòng AuthenticationMethods publickey,keyboard-interactivecó thể được thêm vào /etc/ssh/sshd_configđể làm cho công việc đó.

Tổng quát hơn, vấn đề là mật khẩu (một mình) không phải là một phương pháp tuyệt vời để xác thực vì chúng thường có chất lượng đáng ngờ. Một 'đối số' rất đơn giản cho các khóa so với mật khẩu là một khóa thường sẽ có ít nhất 2048 bit và thường là nhiều hơn (đối với các khóa EC, đây sẽ là cường độ hiệu quả, thay vì kích thước thực tế). Những bit này cũng được tạo ra bởi một cơ chế bảo mật (hoặc thích hợp) về mật mã.

Mật khẩu thường ít hơn 2048 bit và thường không được lấy từ nguồn bảo mật bằng mật mã.

Bạn cũng có thể bảo mật các khóa của mình bằng mật khẩu, để bảo vệ chống lại các vấn đề liên quan đến việc mất chúng (mặc dù ai đó có thể thử và đánh cắp mật khẩu đó).

Về cơ bản, sự khác biệt có thể được thực hiện khá minh bạch giữa các khóa và mật khẩu, và sử dụng các khóa mua cho bạn một mật khẩu tốt hơn so với con người có thể giải quyết. Điều này không có nghĩa là chúng là thuốc chữa bách bệnh, nhưng trung bình, chúng cung cấp bảo mật nhiều hơn mật khẩu.