Kerberos hoạt động với SSH như thế nào?

Giả sử tôi có bốn máy tính, máy tính xách tay, Server1, Server2, Kerberos:

• Tôi đăng nhập bằng PuTTY hoặc SSH từ L đến S1, cung cấp tên người dùng / mật khẩu của tôi
• Từ S1 tôi rồi SSH sang S2. Không cần mật khẩu vì Kerberos xác thực tôi

Mô tả tất cả các trao đổi giao thức SSH và KRB5 quan trọng: "L gửi tên người dùng đến S1", "K gửi ... đến S1", v.v.

(Câu hỏi này nhằm mục đích chỉnh sửa cộng đồng; vui lòng cải thiện nó cho người đọc không phải là chuyên gia .)

Đăng nhập lần đầu:

• L gửi tên người dùng và yêu cầu xác thực SSH đến S1
• S1 trả về các cơ chế xác thực SSH có sẵn, với "mật khẩu" là một trong số đó
• L chọn "mật khẩu" và gửi mật khẩu đơn giản đến S1
• S1 cung cấp tên người dùng và mật khẩu cho ngăn xếp PAM.
• Trên S1, PAM (thường pam_krb5hoặc pam_sss) yêu cầu TGT (vé cấp vé) từ Kerberos KDC.
  1. S1 thu được một TGT.
     • Kiểu cũ (không có preauth): S1 gửi AS-REQ và nhận AS-REP có chứa TGT.
     • Kiểu mới (với preauth): S1 sử dụng mật khẩu của bạn để mã hóa dấu thời gian hiện tại và gắn nó vào AS-REQ. Máy chủ giải mã dấu thời gian và xác minh rằng nó nằm trong khoảng thời gian cho phép; nếu giải mã thất bại, mật khẩu sẽ bị từ chối ngay lập tức. Mặt khác, TGT được trả về trong AS-REP.
  2. S1 cố gắng giải mã TGT bằng khóa được tạo từ mật khẩu của bạn. Nếu giải mã thành công, mật khẩu được chấp nhận là chính xác.
  3. TGT được lưu trữ vào bộ đệm thông tin xác thực mới được tạo. (Bạn có thể kiểm tra $KRB5CCNAMEbiến môi trường để tìm ccache hoặc sử dụng klistđể liệt kê nội dung của nó.)
• S1 sử dụng PAM để thực hiện kiểm tra ủy quyền (phụ thuộc vào cấu hình) và mở phiên.
  • Nếu pam_krb5được gọi trong giai đoạn ủy quyền, nó sẽ kiểm tra xem có ~/.k5logintồn tại không. Nếu có, nó phải liệt kê hiệu trưởng Kerberos của khách hàng. Mặt khác, hiệu trưởng được phép duy nhất là .username@DEFAULT-REALM

Đăng nhập lần hai:

• S1 gửi tên người dùng và yêu cầu SSH authn đến S2
• S2 trả về các mechs auth có sẵn, một trong số chúng là "gssapi-with-mic" ¹
• S1 yêu cầu một vé cho , bằng cách gửi TGS-REQ cùng với TGT đến KDC và nhận TGS-REP cùng với vé dịch vụ từ nó.host/s2.example.com@EXAMPLE.COM
• S1 tạo ra "AP-REQ" (yêu cầu xác thực) và gửi nó đến S2.
• S2 cố gắng giải mã yêu cầu. Nếu nó thành công, xác thực được thực hiện. (PAM không được sử dụng để xác thực.)
  • Các giao thức khác như LDAP có thể chọn mã hóa việc truyền dữ liệu hơn nữa bằng "khóa phiên" được kèm theo yêu cầu; tuy nhiên, SSH đã đàm phán lớp mã hóa của riêng mình.
• Nếu xác thực thành công, S2 sử dụng PAM để thực hiện kiểm tra ủy quyền và mở phiên, giống như S1.
• Nếu chuyển tiếp thông tin xác thực được bật và TGT có cờ "có thể chuyển tiếp", thì S1 yêu cầu một bản sao TGT của người dùng (với bộ cờ "được chuyển tiếp") và gửi nó đến S2, nơi nó được lưu trữ vào một ccache mới. Điều này cho phép đăng nhập được xác thực Kerberos.

Lưu ý rằng bạn cũng có thể có được TGT tại địa phương. Trên Linux, bạn có thể thực hiện việc này bằng cách sử dụng kinit, sau đó kết nối bằng ssh -K. Đối với Windows, nếu bạn đã đăng nhập vào miền Windows AD, Windows sẽ làm điều đó cho bạn; mặt khác, MIT Kerberos có thể được sử dụng. PuTTY 0.61 hỗ trợ sử dụng cả Windows (SSPI) và MIT (GSSAPI), mặc dù bạn phải bật chuyển tiếp (ủy quyền) theo cách thủ công.

¹ gssapi-keyex cũng có thể nhưng không được chấp nhận vào OpenSSH chính thức.

Nói một cách ngắn gọn: lý tưởng, nên lấy vé Kerberos trên thiết bị đầu cuối (L) của bạn, bằng kinitlệnh hoặc là một phần của chuỗi đăng nhập cục bộ trong một thiết lập được gọi là "đăng nhập một lần". Các hệ thống từ xa (S1, S2) sau đó có thể truy cập được mà không cần nhắc mật khẩu. Có thể truy cập chuỗi (L → S1 → S2) bằng cách sử dụng một kỹ thuật gọi là "chuyển tiếp vé". Thiết lập như vậy đòi hỏi, đặc biệt, KDC phải có thể truy cập trực tiếp từ thiết bị đầu cuối (L).

Câu trả lời khác của grawity giải thích cách tiếp cận này một cách chi tiết.

Bước duy nhất không rõ ràng ở đây là có một mô-đun PAM trên S1 sử dụng thông tin đăng nhập của bạn để thực hiện kinitvà nhận cho bạn một vé cấp vé từ K (xác thực ứng dụng khách). Sau đó, khi bạn SSH đến S2 bằng xác thực Kerberos, xác thực dịch vụ khách sẽ diễn ra. Tôi không thấy lợi ích của việc vượt qua tất cả các tin nhắn trao đổi tẻ nhạt bằng tin nhắn.

Ném -vvvvào lệnh ssh của bạn nếu bạn muốn xem mọi tin nhắn và đọc mô tả Wikipedia về Kerberos.