RE: Problems configuring SSH to work with GSSAPI
- From: "Frank E. Gruman" <f.gruman@xxxxxxxxxxxxxx>
- Date: Wed, 31 Dec 2008 09:45:15 -0500
Frank E. Gruman wrote:tells me that
Hello all,functionality in openSUSE 11.1 through Yast > Network Services >
I am attempting to set up the SSH Single Sign-On
Windows Domain Membership > Single Sign-On for SSH. YaST
it is setting it up correctly, but I am getting an errorwhen I try to
actually perform a GSSAPI connection.local machine
more information
debug1: Unspecified GSS failure. Minor code may provide
No such file or directorysign-on working just fine for domain accounts into the
I have successfully set up domain membership and have
as well as file serving to other Windows machines (Samba, and I amcan think
assuming by proxy, krb5 client). The only two things that I
of as the issues are the .local domain name that our IT departmentand Windows
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
Small Business Server 2003) and the .(dot) in the middle ofall of our
usernames. Unfortunately, I don't have another ADenvironment to test
against or full administrative rights into the current one.this problem
"configure", as well as the error message above with no luck.
I tried Google with several variations of "openssh", "gss",
I have also posted the same message to the openSUSE forums in the
event that someone on that specific system has run into
(http://forums.opensuse.org/network-internet/403139-openssh-single-sign-domain-membership.html).
/etc/ssh/sshd_config len 676efforts for assistance.
Has anyone else gotten this to work? I appreciate any
truncate to fit in this space (on openSUSE forums).
Regards,
Frank
The following are logs showing the output with ... to
*** 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
for f.gruman...GSSAPIAuthentication yes
debug3: /etc/ssh/sshd_config:127 setting
debug3: /etc/ssh/sshd_config:128 settingGSSAPICleanupCredentials yes
debug3: /etc/ssh/sshd_config:129 settingChallengeResponseAuthentication yes
...version PuTTY_Release_0.60_q1.129
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
debug1: no match: PuTTY_Release_0.60_q1.129ssh-connection method none
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
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
service=''debug3: mm_start_pam enteringssh-connection method gssapi-with-mic
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
debug1: attempt 1 failures 0more information
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
No such file or directoryssh-connection method none
debug3: mm_request_send entering: type 38
debug3: mm_request_receive entering
debug1: userauth-request for user f.gruman service
debug1: attempt 2 failures 1supported authentication methods available
debug2: Unrecognized authentication method name: none
Received disconnect from xxx.xxx.xxx.181: 14: No
debug1: do_cleanupQuest PuTTY
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 -
- Vintela Resource Central) ***SSH-2.0-PuTTY_Release_0.60_q1.129
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:
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 targetwith hash SHA-256
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
2008-12-26 18:31:28 Host key fingerprint is:
...
2008-12-26 18:31:28 SSPI: trying user_name='f.gruman'
is a pair2008-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
of Windows 2003 server running Active Directory with the Questplatform has the
Vintella software. A number of Red Hat / Solaris 10 platforms that
have the Quest sshd installed. Then an OpenBSD v4.4
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 serverOpenBSD platform.
running active directory (no Quest software), and an
platform types
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
- I have to select the options under connection/SSH/GSSAPIpassword.
deligate/trust DNS, if not ticked then I get prompted for a
using the net
The method for OpenBSD is using samba to join the domain
utility this creates the keytab entries. The otherplatforms use the
quest software.principal
Your host name might be wrong host/Sandbox for the service
is reported by the quest client, this should be something likektutil).
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
If they do not match you are not in the same ADS domain/REALM.security = ads in
When you say file serving with samba, are you using
the smb.conf? Does the smb.conf include a use kerberoskeytab = 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
- References:
- Re: Problems configuring SSH to work with GSSAPI
- From: Nigel J. Taylor
- Re: Problems configuring SSH to work with GSSAPI
- Prev by Date: RE: Problems configuring SSH to work with GSSAPI
- Next by Date: RE: Problems configuring SSH to work with GSSAPI
- Previous by thread: RE: Problems configuring SSH to work with GSSAPI
- Next by thread: RE: Problems configuring SSH to work with GSSAPI
- Index(es):
Relevant Pages
|