Vấn đềBạn đang cố gắng quản lý một switch Cisco Catalyst cũ hoặc một máy chủ CentOS 6 đời cũ, nhưng chiếc laptop Ubuntu 24.04 mới toanh của bạn lại từ chối kết nối. Kết nối bị ngắt ngay lập tức. Thay vì dấu nhắc mật khẩu, bạn thấy lỗi này:
$ ssh root@192.168.1.10
Unable to negotiate with 192.168.1.10 port 22: no matching host key type found. Their offer: ssh-rsa
Tại sao điều này xảy raĐây không phải là lỗi phần mềm. Đây là một bước đi bảo mật có chủ đích. Kể từ bản phát hành OpenSSH 8.8 vào tháng 9 năm 2021, thuật toán chữ ký ssh-rsa đã bị vô hiệu hóa theo mặc định.
Vấn đề nằm ở hàm băm SHA-1. Các nhà nghiên cứu bảo mật đã chứng minh rằng SHA-1 dễ bị tấn công va chạm tiền tố (chosen-prefix attacks). Vào năm 2020, chi phí để thực hiện một cuộc tấn công như vậy ước tính khoảng 50.000 USD — hoàn toàn nằm trong khả năng của nhiều kẻ xấu. Vì SSH client hiện đại của bạn coi SHA-1 là không còn an toàn, nó sẽ từ chối đề nghị sử dụng thuật toán này từ máy chủ. Bạn về cơ bản đang bị kẹt giữa các tiêu chuẩn bảo mật hiện đại và cơ sở hạ tầng cũ kỹ.
Giải pháp 1: Sửa nhanh (Dòng lệnh)Nếu bạn chỉ cần truy cập vào máy chủ một lần để cập nhật tệp cấu hình, đừng thay đổi cài đặt hệ thống. Bạn có thể yêu cầu SSH cho phép thuật toán cũ chỉ trong phiên làm việc này bằng cách sử dụng cờ -o.
ssh -o HostKeyAlgorithms=+ssh-rsa root@192.168.1.10
Nếu bạn sử dụng một SSH key để đăng nhập và việc đó cũng thất bại, có khả năng bạn cần phải kích hoạt lại RSA cho cả public key:
ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa root@192.168.1.10
Giải pháp 2: Sửa một lần dùng mãi mãi (Khuyên dùng)Việc nhập các cờ dài dòng mỗi lần kết nối rất phiền phức. Cách tiếp cận tốt hơn là tạo một ngoại lệ cho máy chủ cụ thể đó trong cấu hình cục bộ của bạn. Điều này giúp hệ thống của bạn luôn an toàn cho mọi kết nối khác trong khi vẫn truy cập được thiết bị cũ một cách liền mạch.
- Mở tệp cấu hình SSH của người dùng:
nano ~/.ssh/config- Thêm các dòng sau cho IP hoặc hostname của thiết bị cụ thể:Host 192.168.1.10 HostKeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms +ssh-rsa- Lưu và thoát. Đảm bảo tệp có quyền truy cập chính xác để SSH không bỏ qua nó:``` chmod 600 ~/.ssh/config
Giờ đây, một lệnh `ssh root@192.168.1.10` đơn giản sẽ hoạt động mà không cần thêm bất kỳ cờ nào.
## Giải pháp 3: Tùy chọn "mạnh tay" (Sửa trên toàn hệ thống)Nếu bạn đang làm việc trong một phòng lab với hàng trăm máy cũ, bạn có thể muốn kích hoạt tùy chọn này trên toàn hệ thống. **Hãy cẩn thận: điều này làm cho mọi kết nối SSH bạn khởi tạo trở nên kém an toàn hơn một chút.**
Chỉnh sửa tệp `/etc/ssh/ssh_config` bằng sudo và thêm các dòng sau vào cuối tệp:
HostKeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms +ssh-rsa
## Xác minh kết nốiĐể xác nhận giải pháp đang hoạt động như mong đợi, hãy chạy SSH ở chế độ chi tiết (verbose). Bạn có thể lọc đầu ra để xem chính xác thuật toán nào đã được thỏa thuận.
ssh -v root@192.168.1.10 2>&1 | grep -i "host key"
Tìm một dòng tương tự như sau để xác nhận thành công:
debug1: kex: host key algorithm: ssh-rsa
## Giải pháp lâu dàiBỏ qua các kiểm tra bảo mật chỉ là biện pháp tạm thời. Nếu bạn có quyền quản trị trên máy chủ từ xa, bạn nên nâng cấp các key của nó lên loại hiện đại như **Ed25519**. Nó nhanh hơn và an toàn hơn đáng kể so với RSA.
Chạy lệnh này trên máy chủ từ xa để tạo một host key mới:
ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key < /dev/null
Sau đó, thêm `HostKey /etc/ssh/ssh_host_ed25519_key` vào tệp `/etc/ssh/sshd_config` của máy chủ và khởi động lại dịch vụ SSH. Client hiện đại của bạn giờ đây sẽ kết nối được mà không cần bất kỳ thủ thuật nào.