OpenSSH Single Sign-On with Domain Membership

English Network/Internet
#1

Hello all,

I am attempting to set up the SSH Single Sign-On functionality through Yast > Network Services > Windows Domain Membership > Single Sign-On for SSH. YaST tells me that it is setting it up correctly, but I am getting an error when I try to actually perform a GSSAPI connection.
debug1: Unspecified GSS failure. Minor code may provide more information
No such file or directory

I have successfully set up domain membership and have sign-on working just fine for domain accounts into the local machine as well as file serving to other Windows machines (Samba, and by proxy, krb5). The only thing that I can think of as the issue is the .local domain name that our IT department created (Yes, there is an RFC to reserve the name, but MS documents ‘recommended’ that name back when this was set up - The Domain Name System name recommendations for Small Business Server 2000 and Windows Small Business Server 2003). Unfortunately, I don’t have another AD environment to test against.

Has anyone else gotten this to work?

Regards,
Frank

The following are logs showing the output with … to truncate to fit in this space.
*** From server command line ***
sandbox:/home/MYDOMAIN/f.gruman # /usr/sbin/sshd -dddd
debug2: load_server_config: filename /etc/ssh/sshd_config
debug2: load_server_config: done config len = 676
debug2: parse_server_config: config /etc/ssh/sshd_config len 676
…
debug3: /etc/ssh/sshd_config:127 setting GSSAPIAuthentication yes
debug3: /etc/ssh/sshd_config:128 setting GSSAPICleanupCredentials yes
debug3: /etc/ssh/sshd_config:129 setting ChallengeResponseAuthentication yes
…
debug3: /etc/ssh/sshd_config:139 setting UsePAM yes
debug1: sshd version OpenSSH_5.1p1
…
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
…
Connection from xxx.xxx.xxx.181 port 1284
debug1: Client protocol version 2.0; client software version PuTTY_Release_0.60_q1.129
debug1: no match: PuTTY_Release_0.60_q1.129
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1
debug2: fd 3 setting O_NONBLOCK
debug3: privsep user:group 71:65
debug1: permanently_set_uid: 71/65
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug2: Network child is on pid 22954
debug3: preauth child monitor started
debug3: mm_request_receive entering
debug1: SSH2_MSG_KEXINIT received
…
debug3: mm_request_send entering: type 0
debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI
debug3: mm_request_receive_expect entering: type 1
debug3: mm_request_receive entering
debug3: monitor_read: checking request 0
debug3: mm_answer_moduli: got parameters: 1024 4096 8192
debug3: mm_request_send entering: type 1
debug3: mm_choose_dh: remaining 0
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug2: dh_gen_key: priv key bits set: 250/512
debug2: bits set: 2111/4096
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug2: monitor_read: 0 used once, disabling now
debug3: mm_request_receive entering
debug2: bits set: 2061/4096
debug3: mm_key_sign entering
debug3: mm_request_send entering: type 4
debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN
debug3: mm_request_receive_expect entering: type 5
debug3: mm_request_receive entering
debug3: monitor_read: checking request 4
debug3: mm_answer_sign
debug3: mm_answer_sign: signature 0x7f2761d98620(143)
debug3: mm_request_send entering: type 5
debug2: monitor_read: 4 used once, disabling now
debug3: mm_request_receive entering
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug2: cipher_init: set keylen (16 → 32)
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug2: cipher_init: set keylen (16 → 32)
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user f.gruman service ssh-connection method none
debug1: attempt 0 failures 0
debug3: mm_getpwnamallow entering
debug3: mm_request_send entering: type 6
debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM
debug3: mm_request_receive_expect entering: type 7
debug3: mm_request_receive entering
debug3: monitor_read: checking request 6
debug3: mm_answer_pwnamallow
debug2: parse_server_config: config reprocess config len 676
debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1
debug3: mm_request_send entering: type 7
debug2: monitor_read: 6 used once, disabling now
debug3: mm_request_receive entering
debug2: input_userauth_request: setting up authctxt for f.gruman
debug3: mm_start_pam entering
debug3: mm_request_send entering: type 45
debug3: mm_inform_authserv entering
debug3: mm_request_send entering: type 3
debug2: input_userauth_request: try method none
debug3: monitor_read: checking request 45
debug1: PAM: initializing for “f.gruman”
debug1: userauth-request for user f.gruman service ssh-connection method gssapi-with-mic
debug1: attempt 1 failures 0
debug2: input_userauth_request: try method gssapi-with-mic
debug3: mm_request_send entering: type 37
debug3: mm_request_receive_expect entering: type 38
debug3: mm_request_receive entering
debug1: PAM: setting PAM_RHOST to “xxx.xxx.xxx.181”
debug1: PAM: setting PAM_TTY to “ssh”
debug2: monitor_read: 45 used once, disabling now
debug3: mm_request_receive entering
debug3: monitor_read: checking request 3
debug3: mm_answer_authserv: service=ssh-connection, style=
debug2: monitor_read: 3 used once, disabling now
debug3: mm_request_receive entering
debug3: monitor_read: checking request 37
debug1: Unspecified GSS failure. Minor code may provide more information
No such file or directory

debug3: mm_request_send entering: type 38
debug3: mm_request_receive entering
debug1: userauth-request for user f.gruman service ssh-connection method none
debug1: attempt 2 failures 1
debug2: Unrecognized authentication method name: none
Received disconnect from xxx.xxx.xxx.181: 14: No supported authentication methods available
debug1: do_cleanup
debug3: PAM: sshpam_thread_cleanup entering
debug1: do_cleanup
debug1: PAM: cleanup
debug3: PAM: sshpam_thread_cleanup entering

*** The Log from the Client (Putty w/ GSSAPI from Quest - Quest PuTTY - Vintela Resource Central) ***
2008-12-26 18:31:27 Looking up host “Sandbox”
2008-12-26 18:31:27 Connecting to xxx.xxx.xxx.118 port 22
2008-12-26 18:31:27 Server version: SSH-2.0-OpenSSH_5.1
2008-12-26 18:31:27 We claim version: SSH-2.0-PuTTY_Release_0.60_q1.129
2008-12-26 18:31:27 SSPI: acquired credentials for: f.gruman@MYDOMAIN.LOCAL
2008-12-26 18:31:27 Constructed service principal name ‘host/Sandbox’
2008-12-26 18:31:27 Enabling GSSKEX for this target
2008-12-26 18:31:27 Using SSH protocol version 2
2008-12-26 18:31:27 Doing Diffie-Hellman group exchange
2008-12-26 18:31:27 Doing Diffie-Hellman key exchange with hash SHA-256
2008-12-26 18:31:28 Host key fingerprint is:
…
2008-12-26 18:31:28 SSPI: trying user_name=‘f.gruman’ service=’’
2008-12-26 18:31:28 SSPI: acquired credentials for: f.gruman@MYDOMAIN.LOCAL
2008-12-26 18:31:28 Constructed service principal name ‘host/Sandbox’
2008-12-26 18:31:28 GSSAPI authentication aborted
2008-12-26 18:31:28 Disconnected: No supported authentication methods available

#2

You may need the key exchange patch. This might necessitate compiling OpenSSH by hand, rather than using the package. The patch is at

Kerberos/GSSAPI Support in OpenSSH

Good luck!
dafydd

#3

Thanks for the tip on the new build.

It turns out that this is pretty much a configuration issue. Simply enabling the “Single Sign-On for SSH” in Yast2 > Network Services > Windows Domain Membership is not enough to allow remote SSH connections with GSSAPI. Here is what I had to do:
[ul]
[li]Modify the samba server configuration file (Yast2 > Network Services > Samba Server > Identity(tab) > Advanced > Expert Global Settings) and add “use kerberos keytab = yes”. I leave the manual modification to those who prefer hand coding the smb.conf file.[/li][LIST]
[li]If you do this prior to joining the Windows domain then Samba should generate this keytab file for you to hold your Kerberos data. I did this after joining the domain, so had to run “net ads keytab create” from the console to get the keytab file created properly.[/li]
[/ul]
[li]Next, you need to make sure the SSH server can fully resolve its own name in /etc/hosts. To do this, go to Yast2 > Network Services > Hostnames and edit the entry for 127.0.0.2. Make sure there are two entries in here; the short machine name (e.g. server1) and the FQDN (e.g. server1.mydomain.com).[/li][ul]
[li]Example : 127.0.0.2 server1.mydomain.com server1[/li][/ul]
[/LIST]

After completing the two steps above as well as enabling the check box I noted earlier I was able to successfully connect to my Linux box through SSH using my Windows credentials. I was not prompted for a username or password.

Regards,
Frank