ssh không thể thương lượng - không tìm thấy phương thức trao đổi khóa phù hợp

Tôi đang cố gắng đăng nhập vào bộ định tuyến DSL của mình, vì tôi gặp sự cố với thư dòng lệnh. Tôi hy vọng có thể cấu hình lại bộ định tuyến.

Khi tôi đưa ra sshlệnh, đây là những gì xảy ra:

$ ssh enduser@10.255.252.1

Unable to negotiate with 10.255.252.1 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

Vì vậy, sau đó tôi đã xem bài đăng stackexchange này và sửa đổi lệnh của tôi thành điều này, nhưng tôi gặp một vấn đề khác, lần này là với mật mã.

$ ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 enduser@10.255.252.1

Unable to negotiate with 10.255.252.1 port 22: no matching cipher found. Their offer: 3des-cbc

Vì vậy, có một lệnh để cung cấp 3des-cbc mã hóa? Tôi không chắc chắn về 3des, như liệu tôi có muốn thêm nó vĩnh viễn vào hệ thống của mình không.

Có một lệnh để cho phép 3des-cbcmật mã?

vấn đề ở đây là gì? Đó không phải là yêu cầu mật khẩu.

Lỗi cụ thể này xảy ra trong khi kênh được mã hóa đang được thiết lập. Nếu hệ thống của bạn và hệ thống từ xa không chia sẻ ít nhất một mật mã, thì không có mật mã nào để đồng ý và không có kênh mã hóa nào khả thi. Thông thường các máy chủ SSH sẽ cung cấp một số ít các mật mã khác nhau để phục vụ cho các khách hàng khác nhau; Tôi không chắc tại sao máy chủ của bạn sẽ được cấu hình để chỉ cho phép 3DES-CBC.

Bây giờ, 3DES-CBC không phải là khủng khiếp. Nó chậm và cung cấp bảo mật ít hơn một số thuật toán khác, nhưng nó không thể bị phá vỡ ngay lập tức miễn là các phím được chọn đúng. Bản thân CBC có một số vấn đề khi bản mã có thể được sửa đổi trong quá trình vận chuyển, nhưng tôi nghi ngờ rằng tham nhũng kết quả sẽ bị từ chối bởi HMAC của SSH, làm giảm tác động. Tóm lại, có những lựa chọn tồi tệ hơn 3DES-CBC, và có những lựa chọn tốt hơn. Tuy nhiên, luôn luôn cẩn thận khi ghi đè các mặc định liên quan đến bảo mật, bao gồm các lựa chọn thuật toán trao đổi khóa và mật mã.Những mặc định đó là mặc định cho một lý do; một số người khá thông minh đã sử dụng một số năng lực não bộ để xem xét các lựa chọn và xác định rằng những gì được chọn làm mặc định cung cấp bảo mật tổng thể tốt nhất so với đánh đổi hiệu suất.

Khi bạn phát hiện ra, bạn có thể sử dụng -c ...(hoặc -oCiphers=...) để chỉ định mật mã nào sẽ cung cấp từ phía khách hàng. Trong trường hợp này, việc thêm -c 3des-cbcchỉ cho phép 3DES-CBC từ máy khách. Vì điều này phù hợp với một mật mã mà máy chủ cung cấp, một kênh được mã hóa có thể được thiết lập và kết nối tiến tới giai đoạn xác thực.

Bạn cũng có thể thêm điều này vào cá nhân của bạn ~/.ssh/config. Để tránh thực hiện thay đổi toàn cầu để giải quyết vấn đề cục bộ, bạn có thể đặt nó trong một khổ Hostthơ. Ví dụ: nếu cấu hình SSH của bạn hiện đang nói (ví dụ giả):

Port 9922

chỉ định một cổng mặc định toàn cầu là 9922 thay vì 22 mặc định, bạn có thể thêm một khổ chủ cho máy chủ cần cấu hình đặc biệt và một khổ chủ máy chủ chung cho trường hợp mặc định. Điều đó sẽ trở thành một thứ như ...

Host 10.255.252.1
    Ciphers 3des-cbc
    KexAlgorithms +diffie-hellman-group1-sha1
Host *
    Port 9922

Việc thụt lề là tùy chọn, nhưng tôi thấy nó giúp tăng cường khả năng đọc. Dòng trống và dòng bắt đầu với #được bỏ qua.

Nếu bạn luôn (hoặc chủ yếu) đăng nhập với cùng một người dùng trên hệ thống đó, bạn cũng có thể chỉ định tên người dùng đó:

Host 10.255.252.1
    Ciphers 3des-cbc
    KexAlgorithms +diffie-hellman-group1-sha1
    User enduser
Host *
    Port 9922

Bạn không cần thêm một khổ Host *thơ nếu không có gì trong ~ / .ssh / config của bạn để bắt đầu, vì trong trường hợp đó chỉ có các mặc định được biên dịch hoặc toàn hệ thống (thường là từ / etc / ssh / ssh_config) đã sử dụng.

Tại thời điểm này, dòng lệnh ssh để kết nối với máy chủ này giảm xuống chỉ còn

$ ssh 10.255.252.1

và tất cả người dùng khác trên hệ thống của bạn và các kết nối đến tất cả các máy chủ khác trong hệ thống của bạn, không bị ảnh hưởng bởi các thay đổi.

Ok tôi đọc manpage và tìm ra nó.

Tôi không muốn sửa đổi tập tin cấu hình của mình và vì vậy tôi đã tìm kiếm cụm từ "mật mã" trong trang man cho tôi thấy -ctùy chọn; điều này cho phép tôi chỉ định loại mã hóa. lệnh kết thúc là:

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -c 3des-cbc enduser@10.255.252.1

Gần đây tôi gặp vấn đề này khi sử dụng PuTTY để kết nối với phiên bản Ubuntu mới hơn. Có vẻ như các phiên bản trước của PuTTY đã không cập nhật mật mã. Vì vậy, việc tải xuống phiên bản mới nhất của PuTTY đã khắc phục sự cố. Đó có thể là một giải pháp khác.

Một câu trả lời khác cho các comamnd MacOSX và CLI (ví dụ SFTP): tham khảo bài viết này @ http://www.openssh.com/legacy.html (Tùy chọn kế thừa OpenSSL). Tôi đã nhận được một lỗi nhất quán là "không thể thương lượng" đã được giải quyết bằng thông tin trong bài viết này, cụ thể là cài đặt tham số cấu hình trong tệp "~ / .ssh / config".

BTW, tôi đã gặp lỗi này khi máy chủ SFTP đích của tôi (không thuộc quyền quản trị của tôi) cuối cùng đã tắt TLS 1.0 (tùy chọn mã hóa SSL) và yêu cầu TLS 1.1 hoặc 1.2.