Tại sao xác thực mật khẩu SSH là một rủi ro bảo mật?

Hầu hết các hướng dẫn cho cấu hình OpenSSH khuyên nên vô hiệu hóa xác thực mật khẩu theo hướng xác thực dựa trên khóa. Nhưng theo tôi, xác thực mật khẩu có một lợi thế đáng kể: khả năng kết nối từ mọi nơi mà không cần chìa khóa. Nếu luôn được sử dụng với mật khẩu mạnh, đây không phải là rủi ro bảo mật. Hay nó nên?

Có pro và con cho xác thực dựa trên pw hoặc khóa.

Trong một số trường hợp, ví dụ, xác thực dựa trên khóa kém an toàn hơn xác thực mật khẩu. Trong các trường hợp khác, dựa trên pw của nó kém an toàn hơn. Trong một số trường hợp, một là thuận tiện hơn, trong những người khác, ít hơn.

Tất cả tập trung vào vấn đề này: Khi bạn thực hiện xác thực dựa trên khóa, bạn phải bảo mật khóa của mình bằng cụm mật khẩu. Trừ khi bạn có ssh-agent đang chạy (ssh-agent giải phóng bạn khỏi việc nhập cụm mật khẩu của bạn mỗi lần), bạn sẽ không đạt được gì về sự tiện lợi. Bảo mật là không thể tranh cãi: hiện tại vectơ tấn công đã chuyển từ máy chủ sang YOU, hoặc tài khoản của bạn hoặc máy cá nhân của bạn, (...) - những thứ đó có thể dễ dàng phá vỡ hơn.

Hãy suy nghĩ bên ngoài hộp khi quyết định này. Cho dù bạn có được hay mất về mặt bảo mật hay không phụ thuộc vào phần còn lại của môi trường và các biện pháp khác.

chỉnh sửa: Ồ, chỉ cần thấy rằng bạn đang nói về một máy chủ gia đình. Tôi đã ở trong tình huống tương tự, "mật khẩu" hoặc "thẻ nhớ USB có khóa trên đó" luôn ở bên tôi? Tôi đã đi trước nhưng đã thay đổi cổng nghe SSH thành một cái gì đó khác với 22. Điều đó ngăn chặn tất cả những đoạn script khập khiễng đó buộc toàn bộ phạm vi mạng.

Sử dụng các khóa ssh có một tính năng duy nhất so với đăng nhập mật khẩu: bạn có thể chỉ định các lệnh được phép. Điều này có thể được thực hiện bằng cách sửa đổi ~/.ssh/authorized_keystập tin tại máy chủ.

Ví dụ,

command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

sẽ chỉ cho phép lệnh `/usr/local/bin/your_backup_script.sh" với khóa cụ thể đó.

Bạn cũng có thể chỉ định các máy chủ được phép cho khóa:

from="yourclient,yourotherclient", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

Hoặc kết hợp cả hai:

from="yourbackupserver", command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

Với các khóa, bạn cũng có thể cấp quyền truy cập tạm thời cho một số người dùng (giả sử là chuyên gia tư vấn) cho máy chủ mà không tiết lộ mật khẩu cho tài khoản cụ thể đó. Sau khi tư vấn viên đã hoàn thành công việc của mình, khóa tạm thời có thể được gỡ bỏ.

Bạn có thể tận dụng tốt nhất cả hai thế giới bằng cách chỉ cho phép xác thực mật khẩu từ trong mạng của mình. Thêm phần sau vào cuối của bạn sshd_config:

PasswordAuthentication no
Match Address 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
    PasswordAuthentication yes

Bạn đã trả lời một phần cho câu hỏi của mình - kẻ tấn công có thể kết nối từ nhiều nơi hơn, anh ta càng có nhiều khả năng xâm nhập vào máy chủ của bạn bằng cách bruteforcing (xem xét DDoS).

Đồng thời so sánh độ dài của mật khẩu của bạn với kích thước khóa (thường là hàng nghìn bit).

Khi bạn đăng nhập bằng mật khẩu, bạn truyền mật khẩu của mình đến máy chủ. Điều này có nghĩa là nhà điều hành máy chủ có thể sửa đổi SSHD để có quyền truy cập vào mật khẩu của bạn. Với xác thực khóa chung, họ không thể lấy khóa riêng của bạn vì chỉ có khóa chung của bạn mỗi lần đến máy chủ.

Phím ssh ngăn người đàn ông ở giữa tấn công vào mật khẩu của bạn.

khi bạn cố gắng đăng nhập bằng một khóa, máy chủ sẽ tạo một thử thách dựa trên khóa chung của bạn và gửi nó đến máy khách của bạn. sẽ giải mã nó và xây dựng một phản hồi thích hợp để gửi.

Khóa riêng của bạn không bao giờ được gửi đến máy chủ và bất kỳ ai nghe vào đều không thể làm gì ngoại trừ việc chặn phiên duy nhất đó.

với một mật khẩu họ sẽ có thông tin của bạn.

Giải pháp của tôi là có một khóa ssh di động ở các định dạng phù hợp trên phân vùng được mã hóa trên khóa usb. điều này cho phép tôi:
dễ dàng rút lại khóa đó trong trường hợp bị mất.
hạn chế những máy chủ nào cho phép tôi truy cập
và vẫn mang theo nó

mặc dù cài đặt phần mềm gắn kết là một nỗi đau (truecrypt)

Đó là một sự đánh đổi, như @MartinVejmelka nói.

Lý do bạn sử dụng auth dựa trên khóa là vì khóa này vượt xa so với vũ phu hiện tại hoặc trong tương lai buộc bạn phải đến từ PC của chính mình hoặc có khóa trên thẻ nhớ USB hoặc tương tự.

Mật khẩu có các vấn đề sau:

• Nếu nó ngắn, nó có thể bị ép buộc
• Nếu nó dài thì dễ bị lãng quên
• Nó có thể là vai lướt

Một khóa là các đơn đặt hàng có độ lớn dài hơn và không được hiển thị tại bất kỳ điểm nào vì vậy nó tránh được ba vấn đề này.

Điểm tốt được đề cập ở đây rồi.

Điều tôi cho là rủi ro lớn nhất, do bạn đã quan tâm đến những điều cơ bản với mật khẩu mạnh, đó là rất nhiều máy tính đã cài đặt keylogger mà không cần người dùng nhận ra. Thậm chí có những người tạo ra toàn bộ trang web của các tiện ích hữu ích có chứa trojan, vì vậy nó có thể xảy ra với những người giỏi nhất trong chúng ta. Ví dụ, một keylogger sẽ gửi email chi tiết đăng nhập cho một hacker để có thể dễ dàng truy cập máy chủ.

Gần đây tôi đã được Norton cảnh báo về việc tải xuống trình cài đặt Zombee Mod (không phải jar, trình cài đặt) để thêm chuyến bay vào jar Minecraft. Tôi đã xem chi tiết và Norton liệt kê rất nhiều tiện ích trên trang này được đánh dấu là có chứa trojan. Tôi không biết điều này có đúng hay không, nhưng nó khá cụ thể với tên tệp. Nó cũng là một thực tế được biết rằng trojan được đưa vào (một số) warez trước khi chúng được phân phối.

Một lợi ích tiềm năng của SSH đối với mật khẩu là nếu bạn không chỉ định cụm mật khẩu SSH, thì bạn sẽ không bao giờ phải nhập lại mật khẩu ... máy tính của bạn thực sự được tin cậy trên máy chủ vì nó có khóa. Điều đó nói rằng, tôi thường luôn sử dụng cụm mật khẩu SSH để loại trừ lợi ích đó.

Tôi tìm thấy câu trả lời tốt nhất cho lý do tại sao hướng dẫn người dùng thường đề xuất SSH qua xác thực mật khẩu đến từ hướng dẫn Ubuntu cho SSHOpenSSHKeys. Tôi xin trích dẫn

Nếu bạn không nghĩ nó quan trọng, hãy thử đăng nhập tất cả các lần đăng nhập độc hại bạn nhận được cho tuần tiếp theo. Máy tính của tôi - một máy tính để bàn hoàn toàn bình thường - đã có hơn 4.000 lần thử đoán mật khẩu của tôi và gần 2.500 lần thử đột nhập chỉ trong tuần qua. Bạn nghĩ sẽ mất bao nhiêu nghìn lần đoán ngẫu nhiên trước khi kẻ tấn công tình cờ tìm thấy mật khẩu của bạn?

Về cơ bản, nếu bạn có một mật khẩu có độ dài cao, chắc chắn với dấu chấm câu, chữ hoa và chữ thường và số ... bạn có thể sẽ ổn với xác thực mật khẩu. Ngoài ra, nếu bạn có kế hoạch theo dõi nhật ký của mình và không thực hiện các công cụ "siêu an toàn" trên mạng dù sao ... tức là sử dụng nó cho máy chủ gia đình. Sau đó, bằng mọi cách, một mật khẩu hoạt động tốt.

Phương pháp xác thực Passwd thực sự không an toàn (imho). Với cơ chế này, mật khẩu sẽ được truyền đến máy chủ sshd (như @ramon đã nói). Điều này có nghĩa là một số cá nhân có thể sửa đổi máy chủ sshd để lấy lại mật khẩu. Với một cuộc tấn công Man-In-The-Middle, điều này rất dễ thực hiện trong một mạng cục bộ.

Bạn chỉ có thể vá máy chủ sshd bằng cách cài đặt bản vá này ( https://github.com/jtesta/ssh-mitm ). Sử dụng arpspoofvà iptablesđể đặt máy chủ vá của bạn giữa máy khách và máy chủ sshd xác thực.

Vui lòng tắt mật khẩu auth: mở tệp cấu hình /etc/ssh/ssh_configvà thêm dòng PasswordAuthentication no.

Bạn có thể bỏ qua với -o StrictHostKeyChecking=notùy chọn. Điều này rất hữu ích khi sử dụng ssh trong shell script.

ssh -o StrictHostKeyChecking=no -o ConnectTimeout=10 -o PasswordAuthentication=no -o ConnectionAttempts=5 xxUser@xxxHost