> > > 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
