Xác thực Putty Kerberos / GSSAPI


9

Tôi đã cấu hình một vài máy chủ Linux để xác thực với Active Directory Kerberos bằng sssd trên RHEL6. Tôi cũng đã kích hoạt xác thực GSSAPI với hy vọng đăng nhập không mật khẩu.

Nhưng dường như tôi không thể yêu cầu Putty (0,63) xác thực mà không cần mật khẩu.

GSSAPI hoạt động giữa các hệ thống Linux (máy khách openSSH) được cấu hình để xác thực AD, sử dụng cài đặt .ssh / config để bật GSSAPI.

Nó cũng hoạt động từ Cygwin (máy khách openSSH), sử dụng cùng các cài đặt .ssh / config cũng như chạy lệnh kinit để lấy vé.

Ngoài ra Samba cũng chia sẻ trên tất cả các hệ thống Linux, bao gồm các thư mục chính hoạt động từ Windows Explorer mà không yêu cầu mật khẩu (Tôi không chắc GSSAPI có hoạt động ở đó không)

Tôi có thể cố gắng khắc phục sự cố này bằng cách nào? Hầu hết người dùng của tôi sử dụng Putty. Ngoài ra, tôi không phải là Quản trị viên Windows nên tôi không thể làm bất cứ điều gì trên bộ điều khiển miền. Tài khoản của tôi chỉ có đặc quyền để thêm máy chủ vào Miền AD.


Tôi bật tính năng ghi nhật ký gói putty SSH. Tôi thấy loại này thú vị, tôi không biết phải làm gì với thông tin này:

Event Log: Server version: SSH-2.0-OpenSSH_5.3
Event Log: Using SSH protocol version 2
Event Log: We claim version: SSH-2.0-PuTTY_Release_0.63
Outgoing packet #0x0, type 20 / 0x14 (SSH2_MSG_KEXINIT)
Incoming packet #0x0, type 20 / 0x14 (SSH2_MSG_KEXINIT)
Event Log: Doing Diffie-Hellman group exchange
Outgoing packet #0x1, type 30 / 0x1e (SSH2_MSG_KEX_DH_GEX_REQUEST)
Incoming packet #0x1, type 31 / 0x1f (SSH2_MSG_KEX_DH_GEX_GROUP)
Event Log: Doing Diffie-Hellman key exchange with hash SHA-256
Outgoing packet #0x2, type 32 / 0x20 (SSH2_MSG_KEX_DH_GEX_INIT)
Incoming packet #0x2, type 33 / 0x21 (SSH2_MSG_KEX_DH_GEX_REPLY)
Outgoing packet #0x3, type 21 / 0x15 (SSH2_MSG_NEWKEYS)
Event Log: Initialised AES-256 SDCTR client->server encryption
Event Log: Initialised HMAC-SHA1 client->server MAC algorithm
Outgoing raw data at 2014-11-25 00:21:08
Incoming packet #0x3, type 21 / 0x15 (SSH2_MSG_NEWKEYS)
Event Log: Initialised AES-256 SDCTR server->client encryption
Event Log: Initialised HMAC-SHA1 server->client MAC algorithm
Outgoing packet #0x4, type 5 / 0x05 (SSH2_MSG_SERVICE_REQUEST)
Incoming packet #0x6, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
...%gssapi-keyex
,gssapi-with-mic
,password.
Event Log: Using SSPI from SECUR32.DLL
Event Log: Attempting GSSAPI authentication
Outgoing packet #0x6, type 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST)
Incoming packet #0x7, type 60 / 0x3c (SSH2_MSG_USERAUTH_GSSAPI_RESPONSE)
Event Log: GSSAPI authentication initialised
Outgoing packet #0x7, type 61 / 0x3d (SSH2_MSG_USERAUTH_GSSAPI_TOKEN)
Incoming packet #0x8, type 61 / 0x3d (SSH2_MSG_USERAUTH_GSSAPI_TOKEN)
Event Log: GSSAPI authentication initialised
Event Log: GSSAPI authentication loop finished OK
Outgoing packet #0x8, type 66 / 0x42 (SSH2_MSG_USERAUTH_GSSAPI_MIC)
Incoming packet #0x9, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
...%gssapi-keyex
,gssapi-with-mic
,password.

1
Bật gỡ lỗi trên ssh daemon night hiển thị thông tin hữu ích. Bạn luôn có thể bắt đầu phiên bản thứ hai trên một cổng khác để kiểm tra.
Paul Haldane

Câu trả lời:


7

Trên các máy Windows là một phần của miền Active Directory, người dùng sẽ nhận được vé cấp vé Kerberos khi họ đăng nhập vào Windows và PuTTY có thể sử dụng để xác thực nếu xác thực GSSAPI được bật trong Kết nối cấu hình PuTTY | SSH | Auth | GSSAPI (và các phương thức xác thực khác mà nó thử trước GSSAPI, chẳng hạn như khóa chung thông qua Pagete, không được thiết lập hoặc vô hiệu hóa trong Kết nối | SSH | Auth).

[Nếu bạn cũng cần phân quyền bán vé (ví dụ: để gắn hệ thống tệp kerberized trên máy chủ sau khi đăng nhập), hãy đảm bảo rằng ủy nhiệm GSSAPI cũng được bật trong PuTTY các máy chủ mà bạn đăng nhập được đánh dấu trong Active Directory trong tab Phân quyền như " Tin tưởng máy tính này để ủy quyền cho bất kỳ dịch vụ nào (chỉ dành cho Kerberos) " mà chúng không được mặc định. Việc thiết lập lòng tin sau này trong AD chỉ cần thiết cho ủy quyền để làm việc từ các máy khách Windows như PuTTY; nó không cần thiết cho các máy khách "ssh -K" của Linux.]

Trên các máy Windows tự quản lý (cá nhân) không thuộc miền Active Directory, bạn vẫn có thể sử dụng xác thực Kerberos / GSSAPI (và ủy quyền bán vé) qua PuTTY, nhưng bạn phải tự lấy vé. Thật không may, Windows 7 không được cài đặt với bất kỳ chương trình kinit tương đương nào (để bạn yêu cầu vé theo cách thủ công) và PuTTY cũng không nhắc bạn nhập mật khẩu Kerberos nếu bạn thiếu vé. Do đó, bạn phải cài đặt MIT Kerberos cho Windowsgói, bao gồm cả các công cụ dòng lệnh kinit / klist / kdestroy thông thường, cũng như một công cụ GUI gọn gàng "MIT Kerberos Ticket Manager". Sử dụng những cái đó để lấy vé của bạn, và sau đó PuTTY sẽ tự động sử dụng thư viện MIT GSSAPI thay vì Microsoft SSPI, và tất cả sẽ hoạt động. Nếu "Trình quản lý vé MIT Kerberos" đang chạy, nó sẽ tự động nhắc bạn nhập mật khẩu Kerberos của bạn khi PuTTY cần một vé, vì vậy nên liên kết nó từ thư mục Khởi động.


1
Tôi đã học được rằng Windows thực sự có một loại tương đương với lệnh của MIT Kerberos kinitđược gọi cmdkey.
Markus Kuhn

1
Về cho phép phái đoàn vé, nếu bạn là một trong những người hiểu rằng Active Directory được thực sự chỉ Microsoft LDAPv3 dưới mui xe: đảm bảo mục LDAP của hiệu trưởng dịch vụ mà bạn muốn để có thể giao phó một vé Kerberos để có trong nó userAccountControl sự bit TRUSTED_FOR_DELEGATION = 0x80000 = 524288 được đặt.
Markus Kuhn

FYI cho bất cứ ai xem xét việc định cấu hình "Tin tưởng máy tính này để ủy quyền cho bất kỳ dịch vụ nào (chỉ dành cho Kerberos)", ví dụ: ủy quyền Kerberos không bị ràng buộc, điều này có ý nghĩa bảo mật SERIOUS mà bạn nên xem xét. Trước tiên tôi khuyên bạn nên đọc adsecurity.org/?p=1667 .
Brad

3

Trước tiên hãy kiểm tra xem đầu ra klist của bạn trên hộp Windows đang chạy PuTTY có hiển thị TGT hợp lệ không. Sau đó, trong cấu hình cho phiên PuTTY của bạn, hãy đảm bảo Thử xác thực GSSAPI được bật Connection - SSH - Auth - GSSAPI. Cuối cùng, hãy chắc chắn rằng nó được cấu hình để đăng nhập với tên người dùng của bạn tự động Connection - Data. Bạn có thể chỉ định rõ ràng tên người dùng hoặc chọn nút radio cho Sử dụng tên người dùng hệ thống .

Trong lịch sử, đó là tất cả những gì tôi cần làm để làm cho đăng nhập SSH không mật khẩu hoạt động thông qua Kerberos.


1
klist tgt có vẻ như nó có ý nghĩa với tôi. nói rằng nó cũng có thể chuyển tiếp. klist hiển thị 5 khóa, cho những thứ như Exchange. Tôi cũng có một vé cho máy chủ Linux mà tôi đang cố gắng ssh. Tôi đã đi qua cấu hình putty 100 lần. Tất cả các tài liệu / hướng dẫn trực tuyến khá nhiều đều nói cùng một điều nên tôi tin rằng phần đó được thiết lập đúng.
xdaxdb

3

Vấn đề là trong thiết lập Windows Kerberos. Tôi nghĩ Active Directory của chúng tôi được thiết lập thú vị, tôi thực sự không biết tôi không phải là quản trị viên Windows.

Nhưng tôi đã khắc phục sự cố bằng cách định cấu hình thủ công Kerberos bằng ksetup trong Windows 7 CLI.

Sau khi khởi động lại máy trạm từ xa, tôi không thể đăng nhập vào PC. Đó là bởi vì trong cấu hình ban đầu, phần TLD trong miền cõi của tôi luôn vắng mặt (domain \ user) nhưng sau khi tôi định cấu hình thủ công, tôi phải thay đổi tên miền đăng nhập của mình để phản ánh tên miền đầy đủ (domain.TLD \ user) và Tôi đã có thể đăng nhập vào PC Windows của mình, mặc dù hiện tại có vẻ mất nhiều thời gian hơn để xác thực.

Trước những thay đổi, đầu ra của ksetup chỉ hiển thị cảnh giới mặc định của tôi và nó ở dạng chữ thường.

Tôi đã sử dụng "nslookup -type = SRV _kerberos._tcp.domain.TLD" để có được tất cả các máy chủ kdc cho vương quốc của tôi.

Tôi đã không đặt bất kỳ cờ nào.

Tôi đã đặt ánh xạ tên người dùng của mình "ksetup / mapuser user@domain.TLD user"

Tài nguyên tôi đã sử dụng: https://wiki.ncsa.illinois.edu/display/ITS/Windows+7+Kerberos+Login+USE+External+Kerberos+KDC

https://www.cgl.ucsf.edu/Security/CGLAUTH/CGLAUTH.html

Nếu bất cứ ai có bất kỳ đề xuất nào tôi có thể cung cấp cho các quản trị viên Windows về cách họ có thể khắc phục điều này (nó có bị hỏng không?) Tôi sẽ chuyển nó đi.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.