Frank E. Gruman wrote: > Hello all, > > I am attempting to set up the SSH Single Sign-On functionality in openSUSE 11.1 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 I am assuming by proxy, krb5 client). The only two things that I can think of as the issues are 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) and the .(dot) in the middle of all of our usernames. Unfortunately, I don't have another AD environment to test against or full administrative rights into the current one. > > I tried Google with several variations of "openssh", "gss", "configure", as well as the error message above with no luck. I have also posted the same message to the openSUSE forums in the event that someone on that specific system has run into this problem (http://forums.opensuse.org/network-internet/403139-openssh-single-sign-domain-membership.html). > > Has anyone else gotten this to work? I appreciate any efforts for assistance. > > Regards, > Frank > > > The following are logs showing the output with ... to truncate to fit in this space (on openSUSE forums). > *** 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@xxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxx > 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 > I can't help with SUSE, but single-sign-on does work for Red Hat / Solaris 10 / OpenBSD from a windows platform. Setup I have is a pair of Windows 2003 server running Active Directory with the Quest Vintella software. A number of Red Hat / Solaris 10 platforms that have the Quest sshd installed. Then an OpenBSD v4.4 platform has the standard version of OpenSSH 5.1 plus the samba port (compiled with ads support). I have a second set-up with just and Windows 2003 server running active directory (no Quest software), and an OpenBSD platform. >From another windows 2003 server (in the active directory domain) I logged on using my Active Directory domain account, then using Quest putty the single sign-on works to all these platform types - I have to select the options under connection/SSH/GSSAPI deligate/trust DNS, if not ticked then I get prompted for a password. The method for OpenBSD is using samba to join the domain using the net utility this creates the keytab entries. The other platforms use the quest software. Your host name might be wrong host/Sandbox for the service principal is reported by the quest client, this should be something like host/sandbox.mydomain.local, this has to match the keytab entries host/sandbox.mydomain.local@xxxxxxxxxxxxxx on sandbox - view with ktutil (or with VAS software vastool ktutil). If they do not match you are not in the same ADS domain/REALM. When you say file serving with samba, are you using security = ads in the smb.conf? Does the smb.conf include a use kerberos keytab = true. Regards Nigel Taylor
