Mật khẩu SSH của bạn có bị lộ khi bạn cố kết nối với máy chủ sai không?


192

Khi bạn vô tình cố gắng kết nối với máy chủ sai với thông tin mật khẩu, quản trị viên có thể đọc và đăng nhập mật khẩu bạn đã sử dụng không?



41
Trong một máy khách ssh, trước tiên bạn xác thực máy chủ và làm như vậy bạn nói "Tôi tin rằng tôi có thể nói mật khẩu của mình với máy chủ này". Lần tới hãy chú ý hơn đến thông điệp mà bạn đã thấy trước tiên: "Tính xác thực của X không thể được thiết lập. Dấu vân tay của khóa RSA là Y Bạn có chắc Z không (có / không)" Câu hỏi khó chịu này sẽ không được hỏi nếu bạn cho rằng để tự động trả lời mỗi lần.
kubanchot

6
Bạn có thể đặt PasswordAuthentication nomặc định trong OpenSSH và chỉ bật nó (nếu / khi cần) cho các máy chủ đáng tin cậy. Kết hợp với kiểm tra khóa máy chủ nghiêm ngặt, điều này chủ yếu sẽ bảo vệ bạn khỏi việc tiết lộ mật khẩu của bạn, với chi phí thuận tiện.
hobbs

6
@kubanchot, nếu bạn muốn SSH vào "Internal-www.my-company.com" nhưng vô tình gõ vào "ssh www.my-company.com", lời nhắc đó sẽ không bảo vệ bạn - có khả năng cả hai máy chủ đều trong danh sách đáng tin cậy của bạn, chỉ có một trong số họ được điều hành bởi bạn và bên kia do bên thứ ba điều hành.
Đánh dấu

@hobbs ChallengeResponseAuthentication nocũng vậy, tôi nghĩ
ilkkachu

Câu trả lời:


215

Đặt đơn giản: có

Chi tiết hơn ...

Nếu bạn kết nối với máy của tôi thì bạn không biết liệu tôi đang chạy một sshmáy chủ bình thường hay máy chủ đã được sửa đổi để ghi lại mật khẩu được thông qua.

Hơn nữa, tôi không nhất thiết phải sửa đổi sshd, nhưng có thể viết mô-đun PAM (ví dụ: sử dụng pam_script), mật khẩu sẽ được chuyển qua mật khẩu của bạn.

Vì vậy, vâng. KHÔNG BAO GIỜ gửi mật khẩu của bạn đến một máy chủ không tin cậy. Chủ sở hữu của máy có thể dễ dàng cấu hình nó để ghi lại tất cả các mật khẩu đã thử.

(Trên thực tế, điều này không phổ biến trong thế giới infosec; thiết lập máy chủ honeypot để ghi lại mật khẩu đã thử)


13
Chính xác. Theo mặc định, tiêu chuẩn sshdnào không đăng nhập mật khẩu. (Nếu bạn nhập mật khẩu của mình làm tên đăng nhập thì nó sẽ được ghi lại, nhưng đó là một vấn đề khác). Tiêu chuẩn sshdlà một công cụ bảo mật và vì vậy sẽ không đăng nhập thông tin đăng nhập như thế này :-)
Stephen Harris

116
Một lý do khác để sử dụng các cặp khóa công khai / riêng tư ...
gerrit

3
Tôi đã tự hỏi về việc sử dụng mật khẩu của mình trong một thời gian và gần đây tôi nhận ra rằng cố gắng đăng nhập vào các máy chủ sai sẽ là một cách tốt để tiết lộ mật khẩu của tôi cho một quản trị viên máy chủ độc hại.
vfclists

10
@vfclists đăng nhập vào máy chủ sai cũng chính xác là lý do máy khách sshd của bạn lưu trữ dấu vân tay cho mỗi máy chủ. Khi bạn kết nối lần đầu tiên, bạn chấp nhận dấu vân tay đó, sau đó nếu nó không khớp, bạn sẽ nhận được một cảnh báo khổng lồ mà bạn nên chú ý.
quê hương

44
Lời khuyên tốt hơn: không bao giờ sử dụng mật khẩu auth cho ssh. Giao thức có pubkey auth vì những lý do rất tốt; sử dụng nó!
R ..

52

Đúng.

Mật khẩu được gửi sau khi kết nối được mã hóa được thiết lập, nhưng máy chủ từ xa sẽ lấy mật khẩu ở bản rõ.

Nếu bạn quan tâm đến điều đó, giải pháp tốt nhất và dễ nhất là sử dụng các khóa SSH.

Nếu bạn có máy không thể chấp nhận khóa, thì một giải pháp sẽ là tạo một công cụ lưu trữ mật khẩu của bạn một cách an toàn, sau đó sử dụng sshpassđể luôn gửi mật khẩu chính xác tùy thuộc vào máy chủ bạn đang kết nối.


Bây giờ, lý do mật khẩu được gửi trong bản rõ, là vì nó để lại tất cả các quyết định xử lý và lưu trữ nó đến đầu xa, và máy khách có thể hoàn toàn bị câm. Có một vài định dạng băm mật khẩu (lưu trữ) khác nhau được sử dụng trong các hệ thống Linux và BSD trong mười năm qua hoặc lâu hơn ( mật mã (3) ), không có định dạng nào yêu cầu hỗ trợ từ máy khách.

Mặc dù đó cũng là một phần vì lịch sử (tức là nó luôn như vậy). Có các giao thức xác thực phản hồi thử thách tốt hơn có thể được sử dụng ngay cả với mật khẩu. Ví dụ SRP , cung cấp cho các bên một bí mật chung trong quá trình xác thực. Nó đã được triển khai cho một số máy chủ SSH, nhưng bản vá cho OpenSSH là phiên bản cũ (rất).


1
Vấn đề với các giao thức phản hồi thử thách để xác thực mật khẩu là một số trong số chúng yêu cầu máy chủ lưu trữ mật khẩu ở dạng văn bản thuần túy. Nếu giao thức phản hồi thử thách không cho phép máy chủ lưu trữ mật khẩu băm, thì rất có thể nó yêu cầu một thuật toán băm rất cụ thể.
kasperd

8
Mật khẩu thường được gửi bằng văn bản rõ ràng trên mạng (tức là không thực sự rõ ràng, nhưng chỉ với sự bảo vệ rằng SSH | TLS | bất cứ kết nối nào cung cấp). Nếu một hệ thống gọi là cho mật khẩu để được băm client-side và băm để được gửi đi, máy chủ sẽ không có cách nào để lấy được mật khẩu thực tế, và thay vào đó sẽ cấp quyền truy cập cho bất cứ ai có thể cung cấp các hash mật khẩu , làm cho nói băm mật khẩu tương đương .
Blacklight Shining

1
@BlacklightShining Bằng chứng mật khẩu không có kiến ​​thức tồn tại, nhưng không được sử dụng trong SSH vì không có cách nào để sử dụng cơ sở dữ liệu mật khẩu tiêu chuẩn cho chúng và không có điểm nào thực sự để sử dụng chúng thay vì xác thực dựa trên khóa.
Random832

Tôi có thể thấy những mật khẩu được sử dụng để xác thực ở đâu? Họ không ở /var/log/auth.log, sau đó ở đâu?
ア レ ッ

OpenSSH sẽ không đăng nhập mật khẩu, thất bại hoặc cách khác. (Tôi không quen thuộc lắm với các máy chủ SSH khác.) Trong gần như tất cả các cài đặt hợp pháp, mọi giá trị mà nó có thể cung cấp sẽ lớn hơn rủi ro vốn có khi ghi lại mật khẩu một cách cố ý do một số người dùng hợp pháp cung cấp lỗi đánh máy hoặc đã thử một mật khẩu sai-nhưng-đúng-cho-một-thứ-một-mật-mật khác trong Cleartext. Nếu bạn có một lý do chính đáng để làm điều này, tuy nhiên, nó sẽ dễ dàng vá OpenSSH.
nhạcinmybrain

10

Để xây dựng dựa trên câu trả lời của Stephen Harris, đây là chế độ xem thời gian thực mà tôi đã xây dựng cho thấy kịch bản xác thực PAM đã sửa đổi có thể thu được khi kết nối với hộp qua ssh (một loại mật ong). Tôi sử dụng một phiên bản sửa đổi của thư viện PAM lib-storepw.

https://livesshattack.net

https://livesshattack.net/about


4
Câu trả lời chủ yếu là các liên kết được tán thành trong trường hợp liên kết không khả dụng (có vẻ như bạn duy trì trang web này một cách cá nhân, nhưng vẫn vậy). Bạn nên mô tả một chút về cách bạn quản lý điều này với tập lệnh xác thực của bạn cho người đọc.
Centimane

Nó không hoạt động nữa, tôi đã gửi một chuỗi lớn như mật khẩu, tôi nghĩ rằng nó có thể đã phá vỡ nó, xin lỗi: - /
scottydelta

@scottydelta Mặc dù tôi chưa xem xét về nó, nhưng có thể có giới hạn bộ đệm đối với kích thước mật khẩu của mô-đun PAM hoặc chính daemon SSH có thể chấp nhận trong nỗ lực xác thực. Trang web vẫn hoạt động như tôi dự định, mặc dù sẽ xử lý đến giới hạn bộ đệm được chấp nhận bởi sshd hoặc mô-đun PAM nếu đây thực sự là trường hợp.
Willie S.

Không quan tâm là nguồn cho lib-storepw đã sửa đổi của bạn có sẵn cho người khác sử dụng không?
Tim Fletcher

2

SSH là một giao thức đòi hỏi sự tin tưởng lẫn nhau. Đó là lý do tại sao máy khách OpenSSH duy trì tệp đã biết_hosts, để thực hiện sự tin cậy của nó đối với sơ đồ sử dụng đầu tiên.

Khi bạn cố gắng đăng nhập vào máy chủ SSH, bất kể ai đã cung cấp phần mềm hay dữ liệu nào được cấu hình để đăng nhập, bạn đang tham gia vào một số quy trình xác thực. Khi sử dụng xác thực mật khẩu, bạn đang truyền mật khẩu của mình đến máy chủ đó. Đây là một lý do tại sao mật mã bất đối xứng (khóa công khai, chứng chỉ) được khuyến nghị - mật mã khóa công khai giúp giảm đáng kể rủi ro tiết lộ thông tin đăng nhập của bạn. (Mặc dù điều đó có thể không bảo vệ bạn khỏi một cuộc tấn công MitM nếu sử dụng chuyển tiếp ssh-agent hoặc một số sơ đồ tương tự.)


SSH không yêu cầu sự tin tưởng lẫn nhau, hoặc ít nhất là không tin tưởng đối xứng. Điều quan trọng là phải chính xác: know_hosts là về tính xác thực, không phải niềm tin. Như bạn chỉ ra, đặt khóa công khai trên máy chủ ít tin cậy là an toàn. Thật vậy, sử dụng mật khẩu để đăng nhập cũng "an toàn", giả sử bạn không sử dụng lại mật khẩu đó. (Tất nhiên, nó chỉ an toàn như mức độ mà bạn tin tưởng máy chủ.) Ngay cả thông tin đăng nhập ssh được lưu trữ phụ thuộc vào sự tin cậy không đối xứng.
markhahn
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.