Vì sao GitHub đột ngột từ chối khóa SSH: tệp .pub biến mất

• git pull trên chiếc laptop không hề thay đổi bỗng thất bại với GitHub, nhưng sau khi tạo tệp .pub tương ứng với khóa riêng thì xác thực lại thành công
• Khi có tệp .pub, OpenSSH trước tiên trình khóa công khai để được chấp thuận rồi mới ký; nếu không có, nó gửi ngay yêu cầu xác thực đã ký
• Cả hai luồng đều phù hợp với RFC 4252 và sshd thông thường cũng chấp nhận, nhưng frontend SSH của GitHub khi đó dường như không chấp nhận yêu cầu được ký trực tiếp
• Trong 12 lần thử nghiệm có kiểm soát, cả 6 lần không có tệp .pub đều bị từ chối, còn cả 6 lần có tệp đều thành công
• Sự thay đổi banner máy chủ cho phép suy đoán về khả năng phần mềm phía máy chủ đã thay đổi, nhưng nguyên nhân chính xác chưa được xác nhận, nên cách an toàn là duy trì kèm tệp khóa công khai tương ứng

---

Lỗi xác thực đột ngột và cách khắc phục

• Trên laptop chính, git pull bị dừng với lỗi Permission denied (publickey)
  • Khóa đó vẫn còn được đăng ký trên GitHub
  • Một laptop khác dùng khóa khác vẫn có thể lấy cùng kho lưu trữ bình thường
• Không tìm thấy bất thường trong khóa và cấu hình client
  • openssl rsa -check trả về RSA key ok
  • Đang sử dụng thuật toán chữ ký mới nhất rsa-sha2-512
  • ~/.ssh/config không có vấn đề và trang trạng thái GitHub cũng bình thường
• Sau khi cài đặt lại, tệp khóa công khai tương ứng với ~/.ssh/github_rsa đã biến mất; tạo bằng lệnh sau thì xác thực thành công

ssh-keygen -y -f ~/.ssh/github_rsa > ~/.ssh/github_rsa.pub

• Trong thử nghiệm có kiểm soát, cả 6 lần không có tệp .pub đều thất bại, còn cả 6 lần có tệp đều thành công

Luồng xác thực thay đổi theo tệp .pub

• OpenSSH sử dụng các luồng xác thực khóa công khai khác nhau tùy theo sự tồn tại của tệp .pub
  • Nếu có tệp, nó trình khóa công khai trước, đợi máy chủ chấp thuận rồi mới ký
  • Nếu chỉ có khóa riêng, nó bỏ qua bước kiểm tra trước và gửi ngay yêu cầu xác thực đã ký đầy đủ
• Cả hai cách đều được RFC 4252 cho phép, và sshd thông thường chấp nhận cả hai
• Trên GitHub khi đó, yêu cầu khóa công khai được ký trực tiếp đã bị từ chối, nhưng chưa xác nhận liệu phía GitHub có thực sự thay đổi hay không
  • Banner máy chủ trong log debug không còn ở dạng babeld-<hash> như trước mà hiển thị là 6a2c000
  • Khả năng phần mềm máy chủ mới đã từ chối yêu cầu ký trực tiếp vẫn chỉ là suy đoán
• Để tránh vấn đề tương tự, nên duy trì kèm tệp .pub tương ứng với khóa riêng

[GN⁺]

Các ý kiến trên Lobste.rs

• Đã gặp cùng vấn đề trong 4 giờ qua, và sự cố đã được ghi nhận tại https://www.githubstatus.com/incidents/g40zcbvchny4

• Vài tuần trước, khi thay SSH key, tôi đã không xóa file .pub cũ vốn bị Git bỏ qua; dù kết nối bằng key mới vẫn liên tục thất bại
  Chỉ sau khi bật nhiều tùy chọn debug, tôi mới phát hiện SSH client đang gửi fingerprint cũ; tôi hoàn toàn không biết OpenSSH đọc file .pub, và lâu nay vẫn nghĩ đó là file hoàn toàn không cần thiết

• Hôm nay máy chủ CI cũng gặp sự cố tương tự, có vẻ đột nhiên không thể kết nối tới github.com
  Sau khi thay bằng key ed25519 đúng, mọi thứ hoạt động trở lại, nhưng key này cũng không có file .pub tương ứng nên không rõ vì sao lại khắc phục được

  • Key đột nhiên không hoạt động khiến tôi lo trước tiên là có sự cố bị xâm nhập, nhưng giờ có vẻ GitHub đang trực tiếp xử lý nên cũng yên tâm

• Hôm nay tôi cũng gặp cùng vấn đề, và theo những gì tôi biết thì không có thông báo nào rằng GitHub đã lên kế hoạch thay đổi hành vi xác thực SSH

  • Có vẻ không phải là thay đổi đã được lên kế hoạch

• Tôi đã mất cả mật khẩu lẫn recovery key nên phải dùng quy trình khôi phục tài khoản dựa trên SSH key, nhưng GitHub lại đánh dấu SSH key đó là hết hạn, khiến tôi mất hoàn toàn quyền truy cập tài khoản

• Có lẽ tôi đã không để file .pub trong suốt 7–8 năm, nên hy vọng vấn đề được khắc phục trước lần tới tôi dùng GitHub

  • File public key có thể được tạo lại dễ dàng, và lệnh tương ứng cũng có trong bài viết gốc

• Nếu cả hai luồng xác thực đều hợp lệ, tôi thắc mắc vì sao lại tồn tại luồng dò tìm key
  Nó có vẻ chỉ gây ra hành vi bất thường kiểu này; dù sao nếu có thể tạo public key từ private key thì SSH có thể tự động xử lý là được

  • Đây là tính năng dành cho tình huống private key được mã hóa hoặc lưu trong token bảo mật phần cứng, nên không thể dùng ngay
    SSH kiểm tra trước với server xem key nào có thể dùng được, để người dùng không phải giải mã một key chắc chắn sẽ thất bại khi xác thực một cách không cần thiết
    Hành vi này cũng có những tác dụng phụ đặc biệt như https://github.com/FiloSottile/whoami.filippo.io, vì vậy cũng cần cho phép cách làm trong đó server phải biết trước public key của client thì mới có thể thử xác thực, phòng trường hợp người dùng vô tình kết nối nhầm server

• Tài khoản Office 365 dùng cho công việc của tôi cũng đột ngột ngừng hoạt động hôm nay, lần đầu tiên sau 5 năm
  Tôi tự hỏi liệu Microsoft có bị sự cố xâm nhập nên đã salt lại toàn bộ giá trị, hay đây chỉ là chuyện xảy ra với người dùng châu Âu vì cuộc bỏ phiếu Chat Control 1.0 gần đây

  • Dịch vụ chấm dứt kết nối của GitHub và xác thực tài khoản M365 hoàn toàn không liên quan; tôi chắc chắn 99,999% đây chỉ là trùng hợp
    Tôi là một trong hai người mà tôi biết từng làm việc ở cả Git Systems của GitHub lẫn bộ sản phẩm Office/M365 của Microsoft, nên tôi có đủ tư cách để khẳng định như vậy
    Ngay cả nếu nguyên nhân là một thay đổi chính sách hoặc kỹ thuật được áp dụng giống nhau cho cả hai dịch vụ, đây là các hệ thống tách biệt với nhau nên khả năng được triển khai trong cùng một ngày là cực kỳ thấp