Tóm tắt nhanh
- Lỗi trong OpenSSH trên một số hệ thống dùng musl libc, không bật PAM, có thể bỏ qua xác thực mật khẩu SSH.
- Kịch bản cần đồng thời bật đăng nhập mật khẩu, có tài khoản mang trường mật khẩu
*và ít nhất một tài khoản khác có hash mật khẩu kiểu$5$hoặc$6$. - Chuỗi mật khẩu gửi tới dài từ 257 đến 1.024 byte có thể khiến đăng nhập thành công vào tài khoản bị ảnh hưởng.
- OpenSSH 10.6p2 và các gói Alpine đã vá lỗi; sau khi nâng cấp phải khởi động lại dịch vụ
sshd.
OpenSSH phát hành bản 10.6p2 ngày 5/11/2026 để xử lý lỗi bỏ qua xác thực mật khẩu trên một số hệ thống Linux dùng musl libc khi không bật PAM. Trên cấu hình dễ bị ảnh hưởng, chuỗi mật khẩu dài từ 257 đến 1.024 byte có thể cho phép đăng nhập vào một tài khoản vốn không có mật khẩu.
Đây không phải lỗi khiến mọi máy Linux chạy OpenSSH đều gặp nguy hiểm. Điều kiện nằm ở cách sshd, thư viện musl và thiết lập tài khoản phối hợp với nhau; các hệ thống Ubuntu, Debian hay Fedora dùng glibc không thuộc nhóm bị ảnh hưởng theo thông tin hiện có.
Một giá trị báo lỗi lại trùng với dấu khóa tài khoản
Khi sshd kiểm tra mật khẩu mà không qua PAM, nó dùng hàm crypt() để băm mật khẩu người dùng nhập rồi so sánh với giá trị lưu trong tài khoản. Nếu tài khoản có trường mật khẩu chỉ là *, đó không phải một hash có thể khớp với mật khẩu thật: dấu này thường dùng cho tài khoản không được xác thực bằng mật khẩu.
Vấn đề xuất hiện khi mật khẩu đầu vào vượt quá giới hạn 256 byte mà musl xử lý cho thuật toán liên quan. Thay vì trả về một hash bình thường, crypt() của musl trả ký tự * để báo lỗi. Kết quả lỗi này lại giống hệt trường được lưu ở tài khoản không có mật khẩu; nhánh xác thực sau đó có thể xem hai chuỗi là khớp.
OpenSSH từng thêm một cách làm giảm rò rỉ thông tin qua thời gian phản hồi: với tài khoản không có hash dùng được, sshd mượn salt từ tài khoản khác để thực hiện phép băm, khiến phản hồi gần giống trường hợp tài khoản hợp lệ. Khi kết hợp với cách musl biểu diễn lỗi bằng dấu sao, biện pháp chống timing attack này tạo ra tình huống ngoài dự kiến: phép so sánh có thể thành công.
Vì vậy, điều kiện không dừng ở việc nhập một chuỗi rất dài. Theo cảnh báo của Alpine Linux, máy phải có ít nhất một tài khoản mang trường mật khẩu * và một tài khoản khác có hash $5$ hoặc $6$. Kẻ tấn công cũng cần biết tên tài khoản có trường * và có thể kết nối tới cổng SSH.
Alpine cần kiểm tra cấu hình, không chỉ nhìn tên bản phân phối
Alpine Linux là trường hợp đáng chú ý vì gói OpenSSH máy chủ mặc định được biên dịch không có PAM. Lỗi cũng có thể áp dụng với gói có PAM nếu cấu hình đặt UsePAM no. Để bị khai thác, PasswordAuthentication phải bật; trên cấu hình mặc định của OpenSSH, tùy chọn này thường được bật trừ khi quản trị viên đã thay đổi.
Các bản Alpine từ 3.16 đến 3.24 và nhánh edge nằm trong phạm vi được kiểm tra của cảnh báo. Tuy nhiên, chỉ cài Alpine không đồng nghĩa máy chắc chắn bị khai thác: hệ thống không chạy sshd, đã tắt xác thực mật khẩu, dùng PAM với UsePAM yes, hoặc không có đủ kiểu tài khoản nêu trên thì thiếu điều kiện của lỗi.
Các container Alpine thường được dùng làm ảnh nền nhẹ, nhưng cảnh báo này không có nghĩa mọi container đang chạy đều lộ SSH. Container không chạy sshd không chịu đường khai thác trực tiếp này. Rủi ro đáng quan tâm hơn là máy ảo hoặc máy chủ nhỏ có sshd mở ra mạng, đặc biệt các ảnh tiny-cloud Alpine có tài khoản mặc định chỉ dùng khóa và quyền doas không cần mật khẩu. Nếu cấu hình khác tạo thêm hash mật khẩu trên máy, tài khoản đó có thể trở thành mục tiêu.
Ubuntu, Debian và Fedora dùng glibc không bị ảnh hưởng theo thông tin từ nhà nghiên cứu phát hiện lỗi; hệ thống xác thực qua PAM cũng không đi vào nhánh xử lý gây ra vấn đề này. Không nên suy rộng cảnh báo thành “OpenSSH trên Linux đã bị phá”: phạm vi phụ thuộc đồng thời thư viện C, cách dựng sshd, cấu hình đăng nhập và trạng thái tài khoản.
Cập nhật gói chưa thay thế sshd đang chạy
OpenSSH 10.6p2 có biện pháp khắc phục ở phía sshd. Alpine cũng phát hành các gói đã vá cho các nhánh được hỗ trợ và cả một số nhánh cũ; bản sửa tương ứng gồm Alpine 3.21.10, 3.22.8, 3.23.8 và 3.24.4, cùng các gói bảo trì cho những nhánh trước đó.
Điểm dễ bị bỏ sót là nâng cấp gói chỉ thay các tệp trên đĩa. Tiến trình sshd hiện tại vẫn chạy trong bộ nhớ cho đến khi được khởi động lại, nên máy chủ cần restart dịch vụ sau khi cập nhật. Alpine khuyến nghị dùng rc-service sshd restart.
Nếu chưa thể cập nhật ngay, Alpine đề nghị tắt đăng nhập bằng mật khẩu bằng cách đặt PasswordAuthentication no trong cấu hình sshd rồi khởi động lại dịch vụ. Trước khi làm, quản trị viên nên xác nhận đăng nhập bằng SSH key hoạt động và giữ phiên hiện tại mở cho tới khi thử được một phiên mới; nếu tắt mật khẩu khi khóa truy cập chưa sẵn sàng, việc quản trị từ xa có thể bị gián đoạn.
Kiểm tra nhật ký để phát hiện đăng nhập bất thường
Alpine khuyến nghị rà soát /var/log/messages để tìm các dòng sshd ghi nhận Accepted password cho tài khoản vốn không có mật khẩu, chẳng hạn tài khoản chỉ dùng khóa hoặc người dùng mặc định trên một số ảnh cloud. Quản trị viên nên kiểm tra thêm hoạt động doas, tài khoản mới, tệp vừa tạo và khóa được thêm vào authorized_keys.
Nếu không thể loại trừ khả năng đã có người đăng nhập trái phép, hãy xử lý máy như một hệ thống có thể đã bị xâm nhập thay vì chỉ cập nhật gói rồi bỏ qua dấu vết. OpenSSH ghi nhận nhà nghiên cứu Özgün Kültekin thuộc Wakefield đã báo lỗi; bản sửa 10.6p2 được phát hành ngày 5/11/2026.
Nguồn tham khảo: OpenSSH 10.6p2 Release Notes; Alpine Linux Security Advisory; Phân tích của Özgün Kültekin
