Ssh có gửi mật khẩu qua mạng không?

8

Về cơ bản toàn bộ câu hỏi nằm trong tiêu đề: Ssh có gửi mật khẩu qua mạng không? Tất nhiên, giả sử rằng đăng nhập thông qua tên người dùng và mật khẩu được sử dụng.

Tôi đang hỏi bởi vì nếu ssh không gửi mật khẩu qua mạng, một người đàn ông ở giữa không thể lấy được mật khẩu của người dùng ngay cả khi người dùng thêm máy chủ bị cáo buộc vào tệp know_hosts của họ.

Có người nói nó phải như vậy, vì vậy tôi đã viết ra một ví dụ phản biện trong một bình luận. Vì câu hỏi làm thế nào nó có thể hoạt động liên tục được đưa ra liên tục, tôi đang sao chép nhận xét đó ở đây.

Máy chủ có thể cho khách hàng biết nên sử dụng hàm băm nào. [Cùng một mật khẩu được sử dụng để băm mật khẩu trong tệp bóng của máy chủ.] Sau đó, khách hàng có thể tính toán hàm băm trong tệp bóng của máy chủ nhưng hãy gọi mật khẩu trên máy chủ ψ '. Vì vậy, cả máy chủ và máy khách đều biết. Sau đó, khách hàng có thể chọn một muối ngẫu nhiên σ một gửi (băm (ψ.σ), σ) (trong đó .là toán tử ghép) đến máy chủ. Sau đó, máy chủ băm'.σ và kiểm tra xem phần tử đầu tiên của bộ dữ liệu mà nó nhận được từ máy khách có khớp với hàm băm đó không. Nếu có, khách hàng biết mật khẩu.

— UTF-8
nguồn

Làm thế nào khác nó có thể làm việc?

— Các cuộc đua nhẹ nhàng trong quỹ đạo

@LightnessRacesinOrbit Tôi đã thêm nó vào câu hỏi.

— UTF-8

@ UTF-8, tôi cũng đã đề cập rằng xác thực khóa công khai không yêu cầu gửi mật khẩu văn bản gốc và cả những thứ như SRP tồn tại. Tôi nghĩ rõ ràng từ ngữ cảnh rằng "phải" không phải là một tuyên bố chính xác, mà là một tham chiếu đến cách thức triển khai thông thường, hiện tại hoạt động. Những gì có thể được thực hiện, dường như một câu hỏi khác nhau.

— ilkkachu

FYI, có những giao thức bảo mật thực sự làm bằng chứng không có kiến thức như vậy, vì chúng được gọi trong giới bảo mật. Xem câu hỏi liên quan này . Có giao thức Mật khẩu từ xa an toàn (SRM) (hơi tinh ranh) và OPAQUE mới hơn. Câu hỏi liên kết đến bài viết này của Matthew Green đưa ra một mô tả hay.

— JanKanis

SSH gửi mật khẩu như hiện tại đến máy chủ cũng có một số lợi thế. SSH (thường) sử dụng PAM, trình quản lý xác thực có thể cắm, để thực hiện xác minh mật khẩu thực tế. PAM cũng được sử dụng để đăng nhập máy tính để bàn thông thường, vì vậy rõ ràng nó không biết gì về mạng. PAM không chỉ kiểm tra mật khẩu, nó còn có thể xử lý những việc như thiết lập phiên, mở khóa đĩa được mã hóa và quản lý mật khẩu, xử lý hết hạn mật khẩu, v.v. Nó cũng có thể được cấu hình để xác thực yếu tố thứ hai bằng mã thông báo. Bằng cách sử dụng PAM, tất cả những thứ đó cũng có sẵn trong SSH miễn phí.

— JanKanis

7

Nếu bạn đang sử dụng xác thực mật khẩu, thì SSH sẽ gửi mật khẩu qua mạng. Kết nối được mã hóa, vì vậy những kẻ nghe trộm không thể nhìn thấy mật khẩu. Kết nối được xác thực, với điều kiện là bạn không nhấp một cách mù quáng thông qua một tên miền. Tính xác thực của không thể được thiết lập thông báo, vì vậy mật khẩu của bạn sẽ không được gửi cho bất kỳ ai trừ máy chủ hợp pháp.

Câu trả lời nhàm chán cho tại sao vì sao đây là giao thức SSH yêu cầu.

Câu trả lời ít nhàm chán hơn là xác thực mật khẩu phải hoạt động theo cách đó. Có nhiều cách để thực hiện xác thực không hoạt động theo cách này nhưng đây không còn là xác thực mật khẩu đơn giản.

Hầu hết các giao thức xác thực nâng cao hơn xác thực mật khẩu đơn giản đều có đặc tính tốt là máy khách không gửi bất kỳ dữ liệu bí mật nào đến máy chủ mà máy chủ độc hại có thể sử dụng để mạo danh người dùng trên máy chủ thứ ba. Với xác thực khóa công khai SSH , phương thức xác thực SSH phổ biến nhất ngoài mật khẩu, điều này hoạt động vì máy khách gửi chữ ký (yêu cầu khóa riêng) của dữ liệu bao gồm mã định danh phiên; nếu máy chủ độc hại cố gắng xác thực với máy chủ thứ ba, nó sẽ phải tạo một chữ ký dữ liệu bao gồm một mã định danh phiên khác, điều này sẽ không thể thực hiện được nếu không có khóa riêng ở trên máy khách.

Lưu ý rằng nếu bạn sử dụng xác thực khóa chung và bạn phải nhập mật khẩu để sử dụng khóa thì đây không phải là xác thực dựa trên mật khẩu. Mật khẩu để sử dụng khóa được sử dụng riêng ở phía máy khách, để đọc khóa từ tệp khóa. Khi sử dụng xác thực khóa chung, máy chủ không biết hoặc quan tâm liệu khóa có được lưu trong tệp được mã hóa hay không.

Xác thực mật khẩu yêu cầu gửi mật khẩu đến máy chủ. Gửi một hàm băm của mật khẩu thay vì mật khẩu không giúp ích gì, vì sau đó mật khẩu sẽ trở thành hàm băm: kẻ tấn công sẽ không cần tìm mật khẩu thực tế, chỉ có hàm băm. Kẻ tấn công có thểtấn công bằng cách tìm mật khẩu thực tế, vì vậy không có cải thiện. Nhưng nếu kẻ tấn công tìm thấy hàm băm nhưng không phải mật khẩu, trong sơ đồ đề xuất của bạn, điều đó là đủ. Ngược lại, với xác thực dựa trên mật khẩu thông thường, kẻ tấn công phải biết mật khẩu, biết băm không đủ tốt và nếu mật khẩu đủ mạnh thì kẻ tấn công sẽ không thể tìm thấy mật khẩu từ hàm băm. Trong thực tế, lý do kẻ tấn công có thể biết hàm băm nhưng không phải mật khẩu là kẻ tấn công đã tìm cách trích xuất cơ sở dữ liệu băm mật khẩu từ máy chủ, có thể từ bản sao lưu không được bảo vệ hoặc thông qua lỗ hổng trên máy chủ. Lỗ hổng như vậy trên các trang web làm cho tin tức khá thường xuyên.

Giao thức đề xuất của bạn là ít tốt hơn so với giao thức tiêu chuẩn. Đừng cuộn tiền điện tử của riêng bạn!

— Gilles 'SO- ngừng là ác'
nguồn

2

Oh bạn nói đúng. Điều đó thực sự có nghĩa là biết băm là đủ. Tôi đã tập trung vào việc giữ cho người dùng sử dụng lại mật khẩu an toàn và không nghĩ về các tệp bóng bị rò rỉ. Có thể mơ về điều gì đó trong vòng vài giây trong quá trình viết bình luận bên dưới câu trả lời trên StackExchange không dẫn đến các khái niệm bảo mật tốt nhất. ;-)

— UTF-8

Tôi hơi không đồng ý rằng gửi mật khẩu luôn tốt hơn gửi băm. Có những tình huống phổ biến trong đó người dùng sử dụng cùng một mật khẩu được đồng bộ hóa cho nhiều hệ thống. Một trong những hệ thống này có thể được gia công cho bên thứ ba. Sau đó, sẽ chỉ có ích khi chuyển băm cho bên thứ ba chứ không phải mật khẩu, vì băm có thể được sử dụng trên các hệ thống (khác) khác, trong khi mật khẩu là phổ quát và có thể được sử dụng trên tất cả các hệ thống. (Tôi giả sử một hàm băm thích hợp không thể đảo ngược ngay cả với các bảng cầu vồng, như bcrypt hoặc PBKDF2.)

— Johannes Overmann

@JohannesOvermann Đó là một kịch bản khác với kịch bản mà tôi thảo luận trong câu trả lời của mình: câu trả lời của tôi chỉ là về một kịch bản hai bên với một khách hàng xác thực với máy chủ. Trong kịch bản của bạn liên quan đến ba bên, giải pháp bạn đề xuất không hoạt động vì lý do tôi giải thích trong câu trả lời của tôi: máy chủ của bên thứ ba không có cách nào để biết rằng người yêu cầu biết mật khẩu. Điều đó cũng không an toàn vì bên thứ ba có cơ hội đảo ngược băm bằng vũ lực. Có những giải pháp được triển khai rộng rãi cho kịch bản đó thực sự hoạt động an toàn, ví dụ Kerberos.

— Gilles 'SO- ngừng trở nên xấu xa'

@Gilles Vâng, tôi đồng ý Kerberos sẽ là cách thích hợp để làm điều đó. Tôi vẫn lo ngại rằng thông qua ssh và nhiều hệ thống dựa trên mật khẩu khác, mật khẩu được truyền sang phía bên kia theo cách để phía bên kia biết mật khẩu văn bản đơn giản. Điểm chính của tôi là: 1. Có, hàm băm tốt như mật khẩu, ngoại trừ hàm băm phụ thuộc vào trường hợp sử dụng trong khi mật khẩu là phổ quát. 2. Truyền mật khẩu bằng văn bản thuần túy (được mã hóa) có nghĩa là không có sự khác biệt giữa "Tôi được phép truy cập hệ thống" và "Tôi tin tưởng hệ thống mà tôi ủy quyền để biết mật khẩu của mình" thật khó chịu.

— Julian Overmann

@Gilles Dù sao, tôi đánh giá cao đầu vào của bạn (nó vẫn khiến tôi phải suy nghĩ) và tôi có cảm giác cả hai chúng tôi sẽ đồng ý rằng xác thực dựa trên mật khẩu không phải là cách tốt nhất để xác thực. Đó là một dự phòng khá thô.

— Julian Overmann

12

Đúng. Mật khẩu được gửi qua kết nối được mã hóa, nhưng nó ở dạng bản rõ đến máy chủ từ xa.

Cách thông thường để xác thực là cho máy chủ tính toán hàm băm của mật khẩu và so sánh nó với giá trị được lưu trên máy chủ. Có một số cách lưu băm và với các triển khai hiện tại, máy khách không biết máy chủ sử dụng cái gì. ( xem ví dụ crypttrang nam ). (Ngay cả khi có, chỉ cần gửi một hàm băm của mật khẩu sẽ khiến băm tương đương với mật khẩu.)

Ngoài ra, nếu máy chủ sử dụng PAM, các mô-đun PAM có thể thực hiện xác thực với bất kỳ phương thức nào, một số trong đó có thể yêu cầu mật khẩu trong văn bản gốc.

Tuy nhiên, xác thực bằng khóa chung không gửi khóa đến máy chủ từ xa. (Một số giải thích và liên kết về điều này trong một câu hỏi về bảo mật.SE )

Ngoài ra còn có các thuật toán xác thực dựa trên mật khẩu như SRP , không yêu cầu gửi mật khẩu bằng văn bản đơn giản đến đầu kia. Mặc dù SRP dường như chỉ được triển khai cho OpenSSH như một bản vá bên ngoài.

— ilkkachu
nguồn

@ UTF-8, một cái gì đó như thế tất nhiên có thể được thực hiện. Hoặc một cái gì đó như CRAM-MD5. Theo như tôi biết, đó không phải là trường hợp thông thường. Ngoài ra bất cứ điều gì như thế sẽ yêu cầu thay đổi phía khách hàng. Gửi mật khẩu đơn giản cho phép máy chủ tự quyết định cách băm mật khẩu.

— ilkkachu

1

@ UTF-8, bạn có thể làm một cái gì đó như thế này, nhưng nó sẽ không còn là passwordloại xác thực được xác định trong các tiêu chuẩn ssh. Nó sẽ là một biến thể của keyboard interactiveloại xác thực.

— dùng4556274

1

@ user4556274, hoặc có thể là một phương thức xác thực hoàn toàn riêng biệt, vì dù sao cũng cần phải thay đổi mã và RFC khá ngụ ý điều đó keyboard-interactivecó nghĩa là đầu vào từ người dùng.

— ilkkachu

2

Cần lưu ý rằng xác thực mật khẩu đã lỗi thời và có nhiều hậu quả có vấn đề đối với bảo mật, và keyboard-interactivethậm chí còn tệ hơn khi gửi các bí mật giống như mật khẩu do các cuộc tấn công thời gian. Các cấu hình hiện đại chỉ nên sử dụng xác thực khóa chung và nên tắt xác thực mật khẩu. Không có lý do gì để tài khoản người dùng thậm chí có mật khẩu nữa.

— R .. GitHub DỪNG GIÚP ICE

1

@R .., bạn có tài liệu tham khảo nào không? Vấn đề với password, ý tôi là, và đặc biệt là cuộc tấn công thời gian?

— ilkkachu

3

Có, ssh gửi mật khẩu qua mạng, nhưng sau khi mã hóa đầu cuối đã được đàm phán. Xem phần 8 của RFC 4252 có thông báo xác thực mật khẩu chứaplaintext password in ISO-10646 UTF-8 encoding [RFC3629]

— người dùng4556274
nguồn

3

Nếu bạn sử dụng sơ đồ xác thực dựa trên mật khẩu thì có , mật khẩu sẽ được chuyển qua mạng đến điểm cuối ...

Nhưng nó là một kênh được mã hóa.

ví dụ

% ssh remotehost
user@remotehost's password: 

bash$ logout

Trong trường hợp này, mật khẩu đã được gửi mã hóa qua mạng.

Đây là lý do tại sao nó rất quan trọng để xử lý known_hostscác mục đúng cách và chú ý nhiều nếu bạn nhìn thấy @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @thông báo! Đó là sự bảo vệ của bạn chống lại một cuộc tấn công MITM.

— Stephen Harris
nguồn

0

SSH sẽ gửi userid và mật khẩu qua mạng bằng văn bản đơn giản bên trong một kênh được mã hóa. Đây là lý do tại sao khi bạn kết nối một máy chủ mới, bạn sẽ được nhắc chấp nhận khóa. Trong trường hợp tấn công trung gian với máy chủ đã biết, SSH sẽ từ chối kết nối cho đến khi bạn xóa khóa cũ.

Mật khẩu văn bản đơn giản có sẵn ở các điểm cuối, máy tính của bạn và máy tính từ xa. Có thể vô hiệu hóa xác thực mật khẩu, trong trường hợp đó mật khẩu không được nhắc cũng như không được gửi đến máy chủ từ xa.

An toàn hơn khi sử dụng xác thực dựa trên khóa với khóa được bảo vệ bằng mật khẩu. Bạn cần lấy chìa khóa của mình được thêm vào hệ thống từ xa. Khóa công khai là một tệp văn bản có thể được chuyển bằng nhiều cơ chế. Khi sử dụng xác thực dựa trên khóa, có thể đặt ra các hạn chế đối với việc sử dụng khóa.

— BillThor
nguồn

Không. Xem RFC 4252 # 8 .

— dùng207421

Câu trả lời của bạn mâu thuẫn ở một vài nơi.

— Các cuộc đua nhẹ nhàng trong quỹ đạo

Câu đầu tiên là đúng. Nhưng đây không phải là lý do tại sao bạn được nhắc chấp nhận khóa của máy chủ mới.

— Gilles 'SO- ngừng trở nên xấu xa'

'Văn bản thuần túy bên trong một kênh được mã hóa' hiện là một mâu thuẫn về mặt thuật ngữ.

— dùng207421

@EJP Mật khẩu là văn bản đơn giản như được gắn với bất kỳ định dạng văn bản không đơn giản nào. Kênh được mã hóa dưới dạng gắn với kênh không được mã hóa được sử dụng bởi telnet. Nếu bạn quản lý để khiến ai đó kết nối với máy chủ honeypot, bạn sẽ nắm bắt được mật khẩu văn bản đơn giản.

— BillThor