- if no available gssapi mechanisms, abort instead of sending 0 to
the server
- handle SSH_SMSG_FAILURE messages from server (not sure if server is
misbehaving in this case but the client can do the right thing anyway)
- handle cases where try_gssapi_authentication() fails before beginning
the handshake (for example, if there are no GSSAPI credentials);
previously, we'd block waiting for the server to reply even if we
never sent anything to the server
code re-org to match with OpenSSH 3.6. privsep functions should only be
used in server modules now, so split up some functions in gss-genr.c
and moved server-specific parts to gss-serv.c
moved kexgss_client() from kexgss.c to kexgssc.c and
moved kexgss_server() from kexgss.c to kexgsss.c to work with OpenSSH 3.6
code re-org where privsep functions are only available in the server now
jbasney [Mon, 17 Mar 2003 20:38:27 +0000 (20:38 +0000)]
- use get_canonical_hostname() for GSSAPI service hostname resolution
so we get the same hostname each time for DNS round-robin
- renamed resolve_hostname() to resolve_localhost() because that's all
we want it to do now
jbasney [Fri, 21 Feb 2003 15:58:20 +0000 (15:58 +0000)]
undo changes for termining target GSSAPI service name that avoided DNS
because Globus and Kerberos want to use DNS irrespective of DNS spoofing
concerns
jbasney [Fri, 8 Nov 2002 14:41:45 +0000 (14:41 +0000)]
configure needs to set HAVE_GSSAPI_EXT depending on our Globus version;
the header files don't give enough information for us to determine the
correct value here
jbasney [Fri, 8 Nov 2002 14:40:51 +0000 (14:40 +0000)]
- define HAVE_GSSAPI_EXT for GT 2.x installs but *not* for GT 1.x
- for GT 2.x w/ mechglue, still need to link with libglobus_gssapi_gsi to
satisfy reference to gssapi module activation in libglobus_gss_assist
jbasney [Tue, 8 Oct 2002 17:18:32 +0000 (17:18 +0000)]
segv bug fix: gss_accept_sec_context() returns a read-only pointer to the
mech OID, so we shouldn't stash it in our Gssctxt object where we expect
a pointer to an xmalloc'ed object
jbasney [Mon, 7 Oct 2002 18:34:56 +0000 (18:34 +0000)]
for privilege separation, send gss_indicate_mechs() and gss_display_status()
to privileged process, which has the GSSAPI libraries loaded and has the
GSSAPI state, rather than calling them in the unprivileged process, which
can't load teh GSSAPI libraries and doesn't have the GSSAPI state
jbasney [Mon, 7 Oct 2002 18:24:15 +0000 (18:24 +0000)]
ctxt may be NULL when using privsep, so either avoid using it to get the oid
(if we already have it stashed in a local variable) or use GSS_C_NO_OID
instead
jbasney [Mon, 7 Oct 2002 18:23:18 +0000 (18:23 +0000)]
remove explicit call to gss_initialize(); instead, we make sure the
unprivileged child process doesn't call any mechanism-specific GSSAPI
functions (i.e., gss_display_status() and gss_indicate_mechs()) so
mechglue library doesn't need to initialize other GSSAPI libraries in
the unprivileged child process
jbasney [Wed, 2 Oct 2002 14:20:23 +0000 (14:20 +0000)]
add an explicit call to gss_initialize() at sshd startup when using mechglue
because otherwise, we'll have problems initializing later on if
privilege separation is enabled
if gss_accept_sec_context() fails with a packet to send back to the client,
send the GSS packet first before sending the SSH failure message rather
than the other way around so the client will handle the GSS packet before
tearing down its GSS context
debug message cleanup:
- removed superfluous display_gssapi_status() function; ssh_gssapi_error()
is better
- if fail to set GSI username from credentials, write debug message that
says so with GSSAPI error text following, so it's clear what's going on
and the GSSAPI errors may not indicate a failure (i.e., Kerberos can
still work)
changes for gssapi mechglue support:
- rename get_gssapi_cred() to get_gsi_cred() and get_gss_our_name() to
get_gsi_name() and try to force the GSI mechanism, because these functions
(for getting the grid-mapfile name for implicit username mapping) are
GSI specific; this needs more work
- fix debug messages to not assume only one gssapi mechanism
- only tell server about those gssapi oids for which we have valid creds
- prefer GSI over Kerberos GSSAPI mech, because we can only choose one
and we can always do regular (non-GSSAPI) Kerberos auth later