> -----Original Message----- > From: Frank E. Gruman > Sent: Wednesday, December 31, 2008 9:45 AM > To: 'Nigel J. Taylor' > Cc: 'secureshell@xxxxxxxxxxxxxxxxx' > Subject: RE: Problems configuring SSH to work with GSSAPI > > > > 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 And one last thing for the whole list to know - you MUST ensure that your /etc/hosts file has the right records as well. I had this working well on the first box and then tried to get everything running on another and ran into this issue. /etc/hosts needs to have the FQDN of the server in the 127.0.0.2 address name (as well as possibly the shortened name) Something like: 127.0.0.2 sandbox.mydomain.tld sandbox Happy New Year to All!!
