Xác thực SSH bằng gssapi-keyex hoặc gssapi-with-mic (không cho phép khóa công khai)

Công ty của tôi đã vô hiệu hóa xác thực khóa công khai SSH, do đó tôi phải nhập thủ công mỗi lần mật khẩu của mình (tôi không cho phép thay đổi /etc/ssh/sshd_config).

Tuy nhiên gssapi-keyexvà gssapi-with-micxác thực được bật (vui lòng xem bên dưới sshđầu ra gỡ lỗi).

Làm thế nào tôi có thể sử dụng đăng nhập tự động trong trường hợp này?
Tôi có thể khai thác gssapi-keyexvà / hoặc gssapi-with-micxác thực không?

> ssh -v -o PreferredAuthentications=publickey hostxx.domainxx
OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to hostxx.domainxx [11.22.33.44] port 22.
debug1: Connection established.
debug1: identity file /home/me/.ssh/identity type -1
debug1: identity file /home/me/.ssh/id_rsa type -1
debug1: identity file /home/me/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'hostxx.domainxx' is known and matches the RSA host key.
debug1: Found key in /home/me/.ssh/known_hosts:2
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,password
debug1: No more authentication methods to try.
Permission denied (gssapi-keyex,gssapi-with-mic,password).

Có lẽ.

• Bạn có thể có được một vé cho hiệu trưởng của bạn trên hệ thống máy khách của bạn như là một phần của quy trình đăng nhập tiêu chuẩn hoặc thủ công ( kinit, MIT Kerberos cho Windows) không?
• Máy chủ có hiệu trưởng kerberos hay bạn có thể cung cấp cho nó không? Nó phải là hình thức host/server.example.com@EXAMPLE.COM.
• Là GSSAPIxác thực kích hoạt trên khách hàng của bạn?
• Máy khách của bạn có biết máy chủ thuộc về bản ghi tài nguyên DNS TXT hoặc ánh xạ cục bộ không?

Nếu bạn nói "có" với tất cả những điều trên, thì xin chúc mừng, bạn có thể sử dụng GSSAPIAuthentication.

• Bạn cũng có thể cần phải bật ủy quyền, tùy thuộc vào thiết lập của bạn.

Các bước kiểm tra:
(Giả sử: domain = example.com; realm = EXAMPLE.COM)

1. kinit username@EXAMPLE.COM
   • Lý tưởng nhất là việc này được xử lý bởi quy trình đăng nhập tiêu chuẩn của bạn bằng cách bao gồm pam_krb5hoặc pam_sss(với auth_provider = krb5) phù hợp pam stack.
2. kvno host/server.example.com@EXAMPLE.COM
   • Đây là một bước gỡ lỗi. sshthực hiện điều này tự động nếu bạn có bộ đệm hợp lệ và bạn đang nói chuyện với bộ sshdhỗ trợ gssapi-with-michoặc gssapi-keyex.
3. dig _kerberos.example.com txt nên trở về "EXAMPLE.COM"
   • Ngoài ra, ánh xạ có thể được lưu trữ trong [domain_realm]phần của /etc/krb5.confas .example.com = EXAMPLE.COM, nhưng dnsphương thức chia tỷ lệ tốt hơn nhiều.
4. ssh -o GSSAPIAuthentication=yes username@server.example.com
   • Để đăng nhập vào tên người dùng khác với tên hiệu trưởng của bạn trên máy chủ sẽ phải biết để ánh xạ nó với các chi tiết mà tôi không nhận được ở đây.

Phương pháp 4 bước là chính xác (cũng có các bản ghi SRV Kerberos trong DNS thậm chí còn thanh lịch hơn và có mặt trong mọi Active Directory). Tôi sử dụng điều này mọi lúc, và đã ủng hộ phương pháp pubkey này vì các lý do chủ yếu liên quan đến bảo mật và kiểm soát.

Điều đó nói rằng, điều này chỉ cung cấp đăng nhập tương tác, mặc dù nó có thể tương tác gần như một khi bạn đã nhận được một vé trên máy trạm của bạn. Vé Kerberos hoạt động giống như tác nhân SSH; một khi bạn đã có nó, các kết nối mới sẽ ổn định và không có mật khẩu; mặc dù với một giới hạn thời gian.

Để có được đăng nhập hàng loạt tương tác, bạn cần lấy tệp keytab, một tệp chủ yếu chứa mật khẩu cho tài khoản Kerberos, giống như một nửa riêng tư của khóa SSH. Theo biện pháp phòng ngừa an ninh áp dụng; đặc biệt là vì keytab không được mã hóa hoặc bảo vệ bằng mật khẩu.

Tôi khá miễn cưỡng khi cung cấp cho người dùng của mình các keytab cho tài khoản cá nhân của họ, nhưng tôi rất tích cực sử dụng các tài khoản dịch vụ với các quyền tối thiểu cho các công việc hàng loạt khác nhau, đặc biệt là điều quan trọng là thông tin đăng nhập vào hệ thống từ xa, đơn giản là pubkey có thể ' t đạt được.

Keytabs có thể được tạo bằng ktutil trên Unix hoặc KTPASS.EXE trên Windows (sau này từ các dịch vụ AD Kerberos). Xin lưu ý rằng ktutil tồn tại trong hai hương vị, Heimdal và MIT, và cú pháp của chúng khác nhau. Đọc các trang trên một hệ thống có liên quan giúp.