GitHub sắp siết SSH: khóa RSA cũ chưa chắc phải tạo lại

lúc 06:41 28 tháng 9, 2026|Tác giả: Ban biên tập QUASA|6 phút đọc| 1

Trong thông báo SSH ngày 22/9/2026, GitHub ấn định từ 14/10/2026 khóa RSA mới tải lên để xác thực hoặc ký phải dài ít nhất 3.072 bit; các đợt brownout khi bỏ chữ ký RSA/SHA-1 và cơ chế trao đổi khóa cũ được lên lịch 4/11 và 9/12/2026. Đây là lịch thay đổi sắp tới, không phải lệnh vô hiệu hóa ngay mọi khóa RSA đã đăng ký.

Với remote SSH, khóa RSA hiện có vẫn có thể dùng nếu client tạo chữ ký rsa-sha2-256 hoặc rsa-sha2-512. Remote HTTPS nằm ngoài thay đổi thuật toán SSH này. Vì vậy, tên ssh-rsa ở đầu khóa công khai chưa đủ để kết luận phải tạo khóa khác; cần xác định chương trình nào thực hiện kết nối và thuật toán chữ ký chương trình ấy hỗ trợ.

Quy định mới nhắm vào khóa tải lên và thuật toán khi kết nối

Ngưỡng độ dài áp dụng cho khóa RSA mới được đăng ký, kể cả khóa dùng xác thực SSH và khóa dùng ký commit. Một khóa RSA đã lưu trong tài khoản không tự trở thành không hợp lệ chỉ vì ngắn hơn ngưỡng dành cho lần tải lên mới. Trái lại, nếu một client tiếp tục dùng chữ ký RSA với SHA-1, độ dài của khóa không giải quyết được vấn đề: chính kiểu chữ ký đó nằm trong diện bị loại.

Thay đổi khác liên quan đến diffie-hellman-group-exchange-sha256, thuật toán trao đổi khóa cũ, vốn thuộc giai đoạn thiết lập phiên SSH chứ không phải khóa tài khoản. Cùng lịch cập nhật, phương thức hậu lượng tử mlkem768x25519-sha256 sẽ được hỗ trợ trên github.com và GitHub Enterprise Cloud có Data Residency, trừ khu vực Mỹ. Việc có thêm một phương thức trao đổi khóa không đòi người dùng phải thay khóa xác thực: client có hỗ trợ và ưu tiên nó mới chọn nó, còn client cũ có thể dùng phương thức khác được chấp nhận.

Với GitHub Enterprise Server tự quản, thời điểm áp dụng còn phụ thuộc phiên bản triển khai, nên cần xác định host mà remote thực sự truy cập.

Vì sao thấy ssh-rsa chưa có nghĩa là đang dùng SHA-1

ssh-rsa có hai vai trò tên gọi. Ở đầu nội dung khóa công khai, nó xác định loại khóa RSA. Trong quá trình xác thực SSH, thuật toán chữ ký cũng mang tên ssh-rsa, nhưng ở đây nó chỉ chữ ký RSA dùng SHA-1; rsa-sha2-256 và rsa-sha2-512 là chữ ký RSA dùng SHA-2. Cùng một cặp khóa RSA có thể tạo các chữ ký ấy.

Hướng dẫn thêm khóa SSH của GitHub nêu rằng khóa RSA có giá trị valid_after trước 2/11/2021 hiện có thể dùng các thuật toán chữ ký khác nhau, còn khóa tạo sau mốc đó phải dùng SHA-2; một số client cũ cần nâng cấp. Quy tắc hiện hành cho khóa cũ không bảo đảm RSA/SHA-1 sẽ được nhận sau lịch loại bỏ mới.

Phân loại remote, client rồi mới xét khóa

Cây quyết định bắt đầu ở kết nối thực tế của từng kho mã. Các lệnh sau chỉ đọc cấu hình hoặc thông tin khóa:

Chạy git remote -v để xem URL fetch và push. Với submodule đã được khởi tạo, dùng git submodule foreach --recursive 'git remote -v'. Nếu có quy tắc viết lại URL trong Git, git remote get-url --all origin và git remote get-url --push --all origin cho thấy URL sau khi áp dụng quy tắc; thay origin bằng tên remote thực tế.
Nếu URL thực tế bắt đầu bằng https://, lịch bỏ thuật toán SSH này không áp dụng. Với [email protected]:, ssh:// hoặc host GitHub Enterprise dùng SSH, xác định client chạy trong đúng môi trường clone, fetch hoặc push. ssh -V cho biết phiên bản OpenSSH tại môi trường đó, nhưng không đo được thư viện SSH nhúng trong IDE, CI hay ứng dụng Java.
Với OpenSSH, ssh -Q sig liệt kê thuật toán chữ ký mà chương trình biết; ssh -G [email protected] in cấu hình có hiệu lực mà không mở kết nối. Hai lệnh này cho biết năng lực và cấu hình ở phía client, không chứng minh thuật toán đã được thương lượng trong một phiên thật. Với thư viện khác, cần xem phiên bản của chính thư viện.
Nếu cần xét khóa RSA định tải lên, ssh-keygen -lf ~/.ssh/id_rsa.pub đọc độ dài và dấu vân tay của tệp khóa công khai ở đường dẫn ví dụ. Thay đường dẫn bằng tệp đang dùng; kết quả không cho biết client sẽ chọn RSA/SHA-1 hay RSA/SHA-2 khi xác thực.

Từ đó, remote SSH dùng Ed25519 hoặc ECDSA không vướng quy định về độ dài RSA hay việc bỏ chữ ký RSA/SHA-1, dù client vẫn cần trao đổi khóa bằng một phương thức được máy chủ chấp nhận. Với RSA đã đăng ký, khả năng ký SHA-2 của client là điểm quyết định; nếu client chỉ ký RSA/SHA-1, tạo một khóa RSA khác trên chính client ấy không sửa được nguyên nhân. Với RSA chưa đăng ký, phải xét thêm độ dài khóa trước khi tải lên.

Brownout sẽ bộc lộ client cũ, nhưng ngày loại bỏ còn sai thứ tự

Brownout tạm ngừng chấp nhận các thuật toán sắp bị loại, khiến lỗi có thể chỉ xuất hiện ở job CI, submodule hoặc công cụ triển khai. Kết nối thành công trên laptop không chứng minh hệ thống tự động dùng cùng client; thư viện cũ còn có thể phụ thuộc cơ chế trao đổi khóa bị loại.

Phân tích của Nandann đối chiếu ngưỡng OpenSSH 7.2p1 cho chữ ký RSA/SHA-2 và chỉ ra changelog ghi mốc loại bỏ cuối là 13/1/2026, dù mốc này đứng sau các brownout cuối năm 2026 trong cùng lịch. Không có cơ sở để tự sửa thành một năm khác khi GitHub chưa làm rõ. Các mốc đã xác định đủ để phân loại kết nối SSH và client chịu ảnh hưởng; thời điểm loại bỏ hoàn toàn vẫn cần một lịch chính thức nhất quán.

Đọc thêm:

Chia sẻ: