Ai thực sự thấy mật khẩu SSH của bạn trên một VPN không đáng tin cậy?

Đưa một phiên SSH đi qua VPN mà bạn không tự vận hành, và mật khẩu vẫn thuộc về máy chủ SSH, không thuộc về mạng ở giữa. Nếu đường truyền tới một máy chủ đã xác minh được bảo vệ đúng cách, một quan sát viên thụ động trên đường đó không lấy được mật khẩu ở dạng đọc được. Nhưng thay đổi một điều kiện, và câu trả lời thay đổi: một máy chủ chưa xác minh, một danh sách mã hóa bị làm yếu, hoặc một máy trạm bị xâm phạm đều cho kết quả khác nhau. Thực hiện các kiểm tra dưới đây theo thứ tự, và coi mỗi bước là một điều kiện dừng.

Gọi tên người nhận trước khi gõ bất cứ thứ gì

Trường mật khẩu đi bên trong một thông điệp xác thực, và thông điệp đó đi bên trong đường truyền đã mã hóa. Tính bí mật là thuộc tính của đường truyền, nghĩa là nó phụ thuộc vào việc đã thương lượng được bảo vệ và đã thương lượng với đúng máy chủ mà bạn định tới. Chính nửa sau đó là phần người ta bỏ qua. Một kết nối được mã hóa tới kẻ mạo danh vừa bí mật vừa vô dụng cùng lúc. Việc đăng nhập VPN không chứng minh gì về máy chủ SSH, và uy tín của nhà cung cấp không thay thế cho việc kiểm tra khóa.

Giữ hai hướng tách biệt trong đầu. Khóa máy chủ trả lời bạn đã tới máy chủ nào. Xác thực bằng mật khẩu hay khóa trả lời máy chủ chấp nhận người dùng nào. Cải thiện cái thứ hai không bao giờ sửa được cái thứ nhất.

Kiểm tra danh tính máy chủ, bản ghi và thương lượng

Bắt đầu ở máy khách với bản ghi bạn đã có. Một dấu tay đã công bố được so với nguồn tin cậy, và một mục known_hosts vẫn còn khớp, cho bạn bằng chứng duy nhất quan trọng trước khi xác thực bắt đầu.

ssh-keygen -F ssh.internal.example.net -f ~/.ssh/known_hosts
ssh -o StrictHostKeyChecking=yes ssh.internal.example.net

Ở phía máy chủ, in ra các dấu tay bạn định công bố thay vì sao chép chúng từ trí nhớ. Phân phối chúng ngoài kênh chính là toàn bộ ý nghĩa; một dấu tay dán từ cùng kênh trò chuyện với tên máy chủ chỉ chứng minh cả hai đến từ cùng một nơi.

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
sudo sshd -T | grep -E 'hostkey|kexalgorithms|cipher'

Các thuật toán được thương lượng đến từ phần giao của hai bên. Nếu cấu hình máy khách ghim một trao đổi khóa lỗi thời để tới một thiết bị cũ, lựa chọn đó áp dụng cho mọi máy chủ mà nó nói chuyện, nên hãy giới hạn nó cho máy chủ đó thay vì toàn cục.

Đọc các phương thức mà máy chủ thực sự chấp nhận

Biết máy chủ cho phép những phương thức xác thực nào cho bạn biết mật khẩu dùng để làm gì. Một máy chủ chỉ chấp nhận khóa công khai thì không có trao đổi mật khẩu nào để bảo vệ, còn một máy chủ vẫn chấp nhận mật khẩu thì xứng đáng có một quyết định có chủ đích thay vì một giá trị mặc định thừa kế.

sudo sshd -T | grep -E 'passwordauthentication|pubkeyauthentication|permitrootlogin'

Chuyển một người dùng sang xác thực bằng khóa sẽ bỏ mật khẩu của người đó khỏi trao đổi ấy. Điều đó không làm một máy trạm bị xâm phạm trở nên an toàn, và không làm một phiên từ xa không đáng tin trở nên vô hại. Đó là những rủi ro khác nhau với các biện pháp khác nhau. Cũng hãy quyết định về chuyển tiếp tác nhân. Chuyển tiếp một tác nhân tới máy chủ không đáng tin trao cho máy chủ đó khả năng dùng khóa của bạn trong suốt phiên, và đó là mức phơi bày lớn hơn câu hỏi về mật khẩu đã khởi đầu mọi thứ.

Coi cảnh báo khóa máy chủ như một bước của sự cố

Khi máy khách cảnh báo rằng nhận dạng máy chủ đã thay đổi, hãy dừng lại và xác minh qua một kênh không đi qua cùng đường mạng. So dấu tay với bảng điều khiển máy chủ hoặc với người vận hành đã dựng lại nó. Xóa mục cũ để làm im cảnh báo là hành động duy nhất bạn nên từ chối. Nó vứt bỏ bằng chứng và biến một khả năng bị chặn giữa đường thành một lần đăng nhập bình thường.

Nếu máy chủ đã được dựng lại một cách hợp pháp, chỉ xóa mục lỗi thời sau khi dấu tay mới được xác nhận, rồi kết nối lại và kiểm tra thương lượng lần nữa. Ghi lại thay đổi kèm ngày và lý do, vì người tiếp theo sẽ thấy cùng cảnh báo đó và cần biết nó đã được giải quyết.

Điều hướng dẫn này không bao gồm

Một nhà vận hành VPN đang quan sát lưu lượng không giống phần mềm có quyền cục bộ trên máy của bạn. Xâm phạm điểm cuối, một tiện ích trình duyệt thù địch hay một trình ghi bàn phím nằm bên dưới mọi thứ SSH có thể thương lượng, và không đường hầm nào thay đổi điều đó. Nếu máy trạm đáng ngờ, hãy theo quy trình sự cố thay vì thử tính bí mật bằng cách kết nối lại qua một lối ra khác. Kết nối lại chứng minh đường mạng đã thay đổi và không chứng minh gì về điểm cuối.

Kết thúc bằng trường hợp bình thường: máy chủ đã xác minh, đường truyền được bảo vệ, phương thức xác thực bạn chọn có chủ đích, và không có chuyển tiếp nào bạn không cần. Tổ hợp đó là câu trả lời cho câu hỏi trong tiêu đề, và đó là bốn quyết định chứ không phải một.