> > 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-si > ngle-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 > > > > Nigel, > > Thanks for your response. My samba configuration uses > "security = ads" but does NOT contain a "kerberos keytab = > true" line. And for that matter, your note caused me to go > looking for a keytab file (?krb5.keytab?) and there was none > on my system. So - that said, did your samba configuration > include the keytab option before joining the domain or did > you have to create it? I must admit, I have become a bit > lazy with checking my config files lately since openSUSE has > been doing a decent job with their recent builds and their > GUI wizards. > > Perhaps my question now should go to another list (unless you > have the answer) where I find out how to get a keytab > generated for a machine that is already part of the domain. > > Thanks for the assistance. > > Regards, > Frank Nigel, Please disregard my previous post. The keytab generation is simple, even after the fact. After setting the smb.conf parameter "use kerberos keytab = yes" I simple executed a "net ads keytab create" command. VOILA! I now have a krb5.keytab. The client side of this took me an extra couple of seconds - I was delegating credentials but not trusting DNS. It seems unintuitive to not trust my DNS server, but I marked that box and attempted to connect. Thank you for pointing me in the right direction. Best Regards and Happy New Year!! Frank
