2009-07-28 23:20:50 +00:00
|
|
|
#include "putty.h"
|
2008-12-02 18:18:32 +00:00
|
|
|
#ifndef NO_GSSAPI
|
2021-04-22 16:58:40 +00:00
|
|
|
#include "ssh/pgssapi.h"
|
|
|
|
|
#include "ssh/gss.h"
|
|
|
|
|
#include "ssh/gssc.h"
|
2010-05-19 18:22:17 +00:00
|
|
|
|
|
|
|
|
/* Unix code to set up the GSSAPI library list. */
|
|
|
|
|
|
Replace mkfiles.pl with a CMake build system.
This brings various concrete advantages over the previous system:
- consistent support for out-of-tree builds on all platforms
- more thorough support for Visual Studio IDE project files
- support for Ninja-based builds, which is particularly useful on
Windows where the alternative nmake has no parallel option
- a really simple set of build instructions that work the same way on
all the major platforms (look how much shorter README is!)
- better decoupling of the project configuration from the toolchain
configuration, so that my Windows cross-building doesn't need
(much) special treatment in CMakeLists.txt
- configure-time tests on Windows as well as Linux, so that a lot of
ad-hoc #ifdefs second-guessing a particular feature's presence from
the compiler version can now be replaced by tests of the feature
itself
Also some longer-term software-engineering advantages:
- other people have actually heard of CMake, so they'll be able to
produce patches to the new build setup more easily
- unlike the old mkfiles.pl, CMake is not my personal problem to
maintain
- most importantly, mkfiles.pl was just a horrible pile of
unmaintainable cruft, which even I found it painful to make changes
to or to use, and desperately needed throwing in the bin. I've
already thrown away all the variants of it I had in other projects
of mine, and was only delaying this one so we could make the 0.75
release branch first.
This change comes with a noticeable build-level restructuring. The
previous Recipe worked by compiling every object file exactly once,
and then making each executable by linking a precisely specified
subset of the same object files. But in CMake, that's not the natural
way to work - if you write the obvious command that puts the same
source file into two executable targets, CMake generates a makefile
that compiles it once per target. That can be an advantage, because it
gives you the freedom to compile it differently in each case (e.g.
with a #define telling it which program it's part of). But in a
project that has many executable targets and had carefully contrived
to _never_ need to build any module more than once, all it does is
bloat the build time pointlessly!
To avoid slowing down the build by a large factor, I've put most of
the modules of the code base into a collection of static libraries
organised vaguely thematically (SSH, other backends, crypto, network,
...). That means all those modules can still be compiled just once
each, because once each library is built it's reused unchanged for all
the executable targets.
One upside of this library-based structure is that now I don't have to
manually specify exactly which objects go into which programs any more
- it's enough to specify which libraries are needed, and the linker
will figure out the fine detail automatically. So there's less
maintenance to do in CMakeLists.txt when the source code changes.
But that reorganisation also adds fragility, because of the trad Unix
linker semantics of walking along the library list once each, so that
cyclic references between your libraries will provoke link errors. The
current setup builds successfully, but I suspect it only just manages
it.
(In particular, I've found that MinGW is the most finicky on this
score of the Windows compilers I've tried building with. So I've
included a MinGW test build in the new-look Buildscr, because
otherwise I think there'd be a significant risk of introducing
MinGW-only build failures due to library search order, which wasn't a
risk in the previous library-free build organisation.)
In the longer term I hope to be able to reduce the risk of that, via
gradual reorganisation (in particular, breaking up too-monolithic
modules, to reduce the risk of knock-on references when you included a
module for function A and it also contains function B with an
unsatisfied dependency you didn't really need). Ideally I want to
reach a state in which the libraries all have sensibly described
purposes, a clearly documented (partial) order in which they're
permitted to depend on each other, and a specification of what stubs
you have to put where if you're leaving one of them out (e.g.
nocrypto) and what callbacks you have to define in your non-library
objects to satisfy dependencies from things low in the stack (e.g.
out_of_memory()).
One thing that's gone completely missing in this migration,
unfortunately, is the unfinished MacOS port linked against Quartz GTK.
That's because it turned out that I can't currently build it myself,
on my own Mac: my previous installation of GTK had bit-rotted as a
side effect of an Xcode upgrade, and I haven't yet been able to
persuade jhbuild to make me a new one. So I can't even build the MacOS
port with the _old_ makefiles, and hence, I have no way of checking
that the new ones also work. I hope to bring that port back to life at
some point, but I don't want it to block the rest of this change.
2021-04-10 14:21:11 +00:00
|
|
|
#if !defined NO_LIBDL && !defined STATIC_GSSAPI && !defined NO_GSSAPI
|
2010-05-19 18:22:17 +00:00
|
|
|
|
2010-09-25 07:16:56 +00:00
|
|
|
const int ngsslibs = 4;
|
|
|
|
|
const char *const gsslibnames[4] = {
|
2010-05-19 18:22:17 +00:00
|
|
|
"libgssapi (Heimdal)",
|
|
|
|
|
"libgssapi_krb5 (MIT Kerberos)",
|
|
|
|
|
"libgss (Sun)",
|
2010-09-25 07:16:56 +00:00
|
|
|
"User-specified GSSAPI library",
|
2010-05-19 18:22:17 +00:00
|
|
|
};
|
2011-06-25 17:37:31 +00:00
|
|
|
const struct keyvalwhere gsslibkeywords[] = {
|
|
|
|
|
{ "libgssapi", 0, -1, -1 },
|
|
|
|
|
{ "libgssapi_krb5", 1, -1, -1 },
|
|
|
|
|
{ "libgss", 2, -1, -1 },
|
|
|
|
|
{ "custom", 3, -1, -1 },
|
2010-05-19 18:22:17 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Run-time binding against a choice of GSSAPI implementations. We
|
|
|
|
|
* try loading several libraries, and produce an entry in
|
|
|
|
|
* ssh_gss_libraries[] for each one.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
static void gss_init(struct ssh_gss_library *lib, void *dlhandle,
|
2019-09-08 19:29:00 +00:00
|
|
|
int id, const char *msg)
|
2008-08-10 13:10:31 +00:00
|
|
|
{
|
2010-05-19 18:22:17 +00:00
|
|
|
lib->id = id;
|
|
|
|
|
lib->gsslogmsg = msg;
|
2010-09-25 07:16:56 +00:00
|
|
|
lib->handle = dlhandle;
|
2008-08-10 13:10:31 +00:00
|
|
|
|
2010-05-19 18:22:17 +00:00
|
|
|
#define BIND_GSS_FN(name) \
|
|
|
|
|
lib->u.gssapi.name = (t_gss_##name) dlsym(dlhandle, "gss_" #name)
|
2008-08-10 13:10:31 +00:00
|
|
|
|
2010-05-19 18:22:17 +00:00
|
|
|
BIND_GSS_FN(delete_sec_context);
|
|
|
|
|
BIND_GSS_FN(display_status);
|
|
|
|
|
BIND_GSS_FN(get_mic);
|
Support GSS key exchange, for Kerberos 5 only.
This is a heavily edited (by me) version of a patch originally due to
Nico Williams and Viktor Dukhovni. Their comments:
* Don't delegate credentials when rekeying unless there's a new TGT
or the old service ticket is nearly expired.
* Check for the above conditions more frequently (every two minutes
by default) and rekey when we would delegate credentials.
* Do not rekey with very short service ticket lifetimes; some GSSAPI
libraries may lose the race to use an almost expired ticket. Adjust
the timing of rekey checks to try to avoid this possibility.
My further comments:
The most interesting thing about this patch to me is that the use of
GSS key exchange causes a switch over to a completely different model
of what host keys are for. This comes from RFC 4462 section 2.1: the
basic idea is that when your session is mostly bidirectionally
authenticated by the GSSAPI exchanges happening in initial kex and
every rekey, host keys become more or less vestigial, and their
remaining purpose is to allow a rekey to happen if the requirements of
the SSH protocol demand it at an awkward moment when the GSS
credentials are not currently available (e.g. timed out and haven't
been renewed yet). As such, there's no need for host keys to be
_permanent_ or to be a reliable identifier of a particular host, and
RFC 4462 allows for the possibility that they might be purely
transient and only for this kind of emergency fallback purpose.
Therefore, once PuTTY has done a GSS key exchange, it disconnects
itself completely from the permanent host key cache functions in
storage.h, and instead switches to a _transient_ host key cache stored
in memory with the lifetime of just that SSH session. That cache is
populated with keys received from the server as a side effect of GSS
kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if
later in the session we have to fall back to a non-GSS key exchange.
However, in practice servers we've tested against do not send a host
key in that way, so we also have a fallback method of populating the
transient cache by triggering an immediate non-GSS rekey straight
after userauth (reusing the code path we also use to turn on OpenSSH
delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
|
|
|
BIND_GSS_FN(verify_mic);
|
2010-05-19 18:22:17 +00:00
|
|
|
BIND_GSS_FN(import_name);
|
|
|
|
|
BIND_GSS_FN(init_sec_context);
|
|
|
|
|
BIND_GSS_FN(release_buffer);
|
|
|
|
|
BIND_GSS_FN(release_cred);
|
|
|
|
|
BIND_GSS_FN(release_name);
|
Support GSS key exchange, for Kerberos 5 only.
This is a heavily edited (by me) version of a patch originally due to
Nico Williams and Viktor Dukhovni. Their comments:
* Don't delegate credentials when rekeying unless there's a new TGT
or the old service ticket is nearly expired.
* Check for the above conditions more frequently (every two minutes
by default) and rekey when we would delegate credentials.
* Do not rekey with very short service ticket lifetimes; some GSSAPI
libraries may lose the race to use an almost expired ticket. Adjust
the timing of rekey checks to try to avoid this possibility.
My further comments:
The most interesting thing about this patch to me is that the use of
GSS key exchange causes a switch over to a completely different model
of what host keys are for. This comes from RFC 4462 section 2.1: the
basic idea is that when your session is mostly bidirectionally
authenticated by the GSSAPI exchanges happening in initial kex and
every rekey, host keys become more or less vestigial, and their
remaining purpose is to allow a rekey to happen if the requirements of
the SSH protocol demand it at an awkward moment when the GSS
credentials are not currently available (e.g. timed out and haven't
been renewed yet). As such, there's no need for host keys to be
_permanent_ or to be a reliable identifier of a particular host, and
RFC 4462 allows for the possibility that they might be purely
transient and only for this kind of emergency fallback purpose.
Therefore, once PuTTY has done a GSS key exchange, it disconnects
itself completely from the permanent host key cache functions in
storage.h, and instead switches to a _transient_ host key cache stored
in memory with the lifetime of just that SSH session. That cache is
populated with keys received from the server as a side effect of GSS
kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if
later in the session we have to fall back to a non-GSS key exchange.
However, in practice servers we've tested against do not send a host
key in that way, so we also have a fallback method of populating the
transient cache by triggering an immediate non-GSS rekey straight
after userauth (reusing the code path we also use to turn on OpenSSH
delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
|
|
|
BIND_GSS_FN(acquire_cred);
|
|
|
|
|
BIND_GSS_FN(inquire_cred_by_mech);
|
2008-08-10 13:10:31 +00:00
|
|
|
|
2010-05-19 18:22:17 +00:00
|
|
|
#undef BIND_GSS_FN
|
2008-08-10 13:10:31 +00:00
|
|
|
|
2010-05-19 18:22:17 +00:00
|
|
|
ssh_gssapi_bind_fns(lib);
|
2008-08-10 13:10:31 +00:00
|
|
|
}
|
|
|
|
|
|
2010-05-19 18:22:17 +00:00
|
|
|
/* Dynamically load gssapi libs. */
|
Post-release destabilisation! Completely remove the struct type
'Config' in putty.h, which stores all PuTTY's settings and includes an
arbitrary length limit on every single one of those settings which is
stored in string form. In place of it is 'Conf', an opaque data type
everywhere outside the new file conf.c, which stores a list of (key,
value) pairs in which every key contains an integer identifying a
configuration setting, and for some of those integers the key also
contains extra parts (so that, for instance, CONF_environmt is a
string-to-string mapping). Everywhere that a Config was previously
used, a Conf is now; everywhere there was a Config structure copy,
conf_copy() is called; every lookup, adjustment, load and save
operation on a Config has been rewritten; and there's a mechanism for
serialising a Conf into a binary blob and back for use with Duplicate
Session.
User-visible effects of this change _should_ be minimal, though I
don't doubt I've introduced one or two bugs here and there which will
eventually be found. The _intended_ visible effects of this change are
that all arbitrary limits on configuration strings and lists (e.g.
limit on number of port forwardings) should now disappear; that list
boxes in the configuration will now be displayed in a sorted order
rather than the arbitrary order in which they were added to the list
(since the underlying data structure is now a sorted tree234 rather
than an ad-hoc comma-separated string); and one more specific change,
which is that local and dynamic port forwardings on the same port
number are now mutually exclusive in the configuration (putting 'D' in
the key rather than the value was a mistake in the first place).
One other reorganisation as a result of this is that I've moved all
the dialog.c standard handlers (dlg_stdeditbox_handler and friends)
out into config.c, because I can't really justify calling them generic
any more. When they took a pointer to an arbitrary structure type and
the offset of a field within that structure, they were independent of
whether that structure was a Config or something completely different,
but now they really do expect to talk to a Conf, which can _only_ be
used for PuTTY configuration, so I've renamed them all things like
conf_editbox_handler and moved them out of the nominally independent
dialog-box management module into the PuTTY-specific config.c.
[originally from svn r9214]
2011-07-14 18:52:21 +00:00
|
|
|
struct ssh_gss_liblist *ssh_gss_setup(Conf *conf)
|
2008-08-10 13:10:31 +00:00
|
|
|
{
|
2010-05-19 18:22:17 +00:00
|
|
|
void *gsslib;
|
Post-release destabilisation! Completely remove the struct type
'Config' in putty.h, which stores all PuTTY's settings and includes an
arbitrary length limit on every single one of those settings which is
stored in string form. In place of it is 'Conf', an opaque data type
everywhere outside the new file conf.c, which stores a list of (key,
value) pairs in which every key contains an integer identifying a
configuration setting, and for some of those integers the key also
contains extra parts (so that, for instance, CONF_environmt is a
string-to-string mapping). Everywhere that a Config was previously
used, a Conf is now; everywhere there was a Config structure copy,
conf_copy() is called; every lookup, adjustment, load and save
operation on a Config has been rewritten; and there's a mechanism for
serialising a Conf into a binary blob and back for use with Duplicate
Session.
User-visible effects of this change _should_ be minimal, though I
don't doubt I've introduced one or two bugs here and there which will
eventually be found. The _intended_ visible effects of this change are
that all arbitrary limits on configuration strings and lists (e.g.
limit on number of port forwardings) should now disappear; that list
boxes in the configuration will now be displayed in a sorted order
rather than the arbitrary order in which they were added to the list
(since the underlying data structure is now a sorted tree234 rather
than an ad-hoc comma-separated string); and one more specific change,
which is that local and dynamic port forwardings on the same port
number are now mutually exclusive in the configuration (putting 'D' in
the key rather than the value was a mistake in the first place).
One other reorganisation as a result of this is that I've moved all
the dialog.c standard handlers (dlg_stdeditbox_handler and friends)
out into config.c, because I can't really justify calling them generic
any more. When they took a pointer to an arbitrary structure type and
the offset of a field within that structure, they were independent of
whether that structure was a Config or something completely different,
but now they really do expect to talk to a Conf, which can _only_ be
used for PuTTY configuration, so I've renamed them all things like
conf_editbox_handler and moved them out of the nominally independent
dialog-box management module into the PuTTY-specific config.c.
[originally from svn r9214]
2011-07-14 18:52:21 +00:00
|
|
|
char *gsspath;
|
2010-09-25 07:16:56 +00:00
|
|
|
struct ssh_gss_liblist *list = snew(struct ssh_gss_liblist);
|
2008-08-10 13:10:31 +00:00
|
|
|
|
2010-09-25 07:16:56 +00:00
|
|
|
list->libraries = snewn(4, struct ssh_gss_library);
|
|
|
|
|
list->nlibraries = 0;
|
2008-08-10 13:10:31 +00:00
|
|
|
|
2010-05-19 18:22:17 +00:00
|
|
|
/* Heimdal's GSSAPI Library */
|
|
|
|
|
if ((gsslib = dlopen("libgssapi.so.2", RTLD_LAZY)) != NULL)
|
2019-09-08 19:29:00 +00:00
|
|
|
gss_init(&list->libraries[list->nlibraries++], gsslib,
|
|
|
|
|
0, "Using GSSAPI from libgssapi.so.2");
|
2008-08-10 13:10:31 +00:00
|
|
|
|
2010-05-19 18:22:17 +00:00
|
|
|
/* MIT Kerberos's GSSAPI Library */
|
|
|
|
|
if ((gsslib = dlopen("libgssapi_krb5.so.2", RTLD_LAZY)) != NULL)
|
2019-09-08 19:29:00 +00:00
|
|
|
gss_init(&list->libraries[list->nlibraries++], gsslib,
|
|
|
|
|
1, "Using GSSAPI from libgssapi_krb5.so.2");
|
2008-08-10 13:10:31 +00:00
|
|
|
|
2010-05-19 18:22:17 +00:00
|
|
|
/* Sun's GSSAPI Library */
|
|
|
|
|
if ((gsslib = dlopen("libgss.so.1", RTLD_LAZY)) != NULL)
|
2019-09-08 19:29:00 +00:00
|
|
|
gss_init(&list->libraries[list->nlibraries++], gsslib,
|
|
|
|
|
2, "Using GSSAPI from libgss.so.1");
|
2010-09-25 07:16:56 +00:00
|
|
|
|
|
|
|
|
/* User-specified GSSAPI library */
|
Post-release destabilisation! Completely remove the struct type
'Config' in putty.h, which stores all PuTTY's settings and includes an
arbitrary length limit on every single one of those settings which is
stored in string form. In place of it is 'Conf', an opaque data type
everywhere outside the new file conf.c, which stores a list of (key,
value) pairs in which every key contains an integer identifying a
configuration setting, and for some of those integers the key also
contains extra parts (so that, for instance, CONF_environmt is a
string-to-string mapping). Everywhere that a Config was previously
used, a Conf is now; everywhere there was a Config structure copy,
conf_copy() is called; every lookup, adjustment, load and save
operation on a Config has been rewritten; and there's a mechanism for
serialising a Conf into a binary blob and back for use with Duplicate
Session.
User-visible effects of this change _should_ be minimal, though I
don't doubt I've introduced one or two bugs here and there which will
eventually be found. The _intended_ visible effects of this change are
that all arbitrary limits on configuration strings and lists (e.g.
limit on number of port forwardings) should now disappear; that list
boxes in the configuration will now be displayed in a sorted order
rather than the arbitrary order in which they were added to the list
(since the underlying data structure is now a sorted tree234 rather
than an ad-hoc comma-separated string); and one more specific change,
which is that local and dynamic port forwardings on the same port
number are now mutually exclusive in the configuration (putting 'D' in
the key rather than the value was a mistake in the first place).
One other reorganisation as a result of this is that I've moved all
the dialog.c standard handlers (dlg_stdeditbox_handler and friends)
out into config.c, because I can't really justify calling them generic
any more. When they took a pointer to an arbitrary structure type and
the offset of a field within that structure, they were independent of
whether that structure was a Config or something completely different,
but now they really do expect to talk to a Conf, which can _only_ be
used for PuTTY configuration, so I've renamed them all things like
conf_editbox_handler and moved them out of the nominally independent
dialog-box management module into the PuTTY-specific config.c.
[originally from svn r9214]
2011-07-14 18:52:21 +00:00
|
|
|
gsspath = conf_get_filename(conf, CONF_ssh_gss_custom)->path;
|
|
|
|
|
if (*gsspath && (gsslib = dlopen(gsspath, RTLD_LAZY)) != NULL)
|
2019-09-08 19:29:00 +00:00
|
|
|
gss_init(&list->libraries[list->nlibraries++], gsslib,
|
|
|
|
|
3, dupprintf("Using GSSAPI from user-specified"
|
|
|
|
|
" library '%s'", gsspath));
|
2010-09-25 07:16:56 +00:00
|
|
|
|
|
|
|
|
return list;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void ssh_gss_cleanup(struct ssh_gss_liblist *list)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* dlopen and dlclose are defined to employ reference counting
|
|
|
|
|
* in the case where the same library is repeatedly dlopened, so
|
|
|
|
|
* even in a multiple-sessions-per-process context it's safe to
|
|
|
|
|
* naively dlclose everything here without worrying about
|
|
|
|
|
* destroying it under the feet of another SSH instance still
|
|
|
|
|
* using it.
|
|
|
|
|
*/
|
|
|
|
|
for (i = 0; i < list->nlibraries; i++) {
|
2019-09-08 19:29:00 +00:00
|
|
|
dlclose(list->libraries[i].handle);
|
|
|
|
|
if (list->libraries[i].id == 3) {
|
|
|
|
|
/* The 'custom' id involves a dynamically allocated message.
|
|
|
|
|
* Note that we must cast away the 'const' to free it. */
|
|
|
|
|
sfree((char *)list->libraries[i].gsslogmsg);
|
|
|
|
|
}
|
2010-09-25 07:16:56 +00:00
|
|
|
}
|
|
|
|
|
sfree(list->libraries);
|
|
|
|
|
sfree(list);
|
2008-08-10 13:10:31 +00:00
|
|
|
}
|
|
|
|
|
|
2010-09-25 07:16:56 +00:00
|
|
|
#elif !defined NO_GSSAPI
|
|
|
|
|
|
|
|
|
|
const int ngsslibs = 1;
|
|
|
|
|
const char *const gsslibnames[1] = {
|
|
|
|
|
"static",
|
|
|
|
|
};
|
2011-06-25 17:37:31 +00:00
|
|
|
const struct keyvalwhere gsslibkeywords[] = {
|
|
|
|
|
{ "static", 0, -1, -1 },
|
2010-09-25 07:16:56 +00:00
|
|
|
};
|
2008-08-10 13:10:31 +00:00
|
|
|
|
2010-05-19 18:22:17 +00:00
|
|
|
/*
|
|
|
|
|
* Link-time binding against GSSAPI. Here we just construct a single
|
|
|
|
|
* library structure containing pointers to the functions we linked
|
|
|
|
|
* against.
|
|
|
|
|
*/
|
2008-08-10 13:10:31 +00:00
|
|
|
|
2010-05-19 18:22:17 +00:00
|
|
|
#include <gssapi/gssapi.h>
|
2008-08-10 13:10:31 +00:00
|
|
|
|
2010-05-19 18:22:17 +00:00
|
|
|
/* Dynamically load gssapi libs. */
|
Post-release destabilisation! Completely remove the struct type
'Config' in putty.h, which stores all PuTTY's settings and includes an
arbitrary length limit on every single one of those settings which is
stored in string form. In place of it is 'Conf', an opaque data type
everywhere outside the new file conf.c, which stores a list of (key,
value) pairs in which every key contains an integer identifying a
configuration setting, and for some of those integers the key also
contains extra parts (so that, for instance, CONF_environmt is a
string-to-string mapping). Everywhere that a Config was previously
used, a Conf is now; everywhere there was a Config structure copy,
conf_copy() is called; every lookup, adjustment, load and save
operation on a Config has been rewritten; and there's a mechanism for
serialising a Conf into a binary blob and back for use with Duplicate
Session.
User-visible effects of this change _should_ be minimal, though I
don't doubt I've introduced one or two bugs here and there which will
eventually be found. The _intended_ visible effects of this change are
that all arbitrary limits on configuration strings and lists (e.g.
limit on number of port forwardings) should now disappear; that list
boxes in the configuration will now be displayed in a sorted order
rather than the arbitrary order in which they were added to the list
(since the underlying data structure is now a sorted tree234 rather
than an ad-hoc comma-separated string); and one more specific change,
which is that local and dynamic port forwardings on the same port
number are now mutually exclusive in the configuration (putting 'D' in
the key rather than the value was a mistake in the first place).
One other reorganisation as a result of this is that I've moved all
the dialog.c standard handlers (dlg_stdeditbox_handler and friends)
out into config.c, because I can't really justify calling them generic
any more. When they took a pointer to an arbitrary structure type and
the offset of a field within that structure, they were independent of
whether that structure was a Config or something completely different,
but now they really do expect to talk to a Conf, which can _only_ be
used for PuTTY configuration, so I've renamed them all things like
conf_editbox_handler and moved them out of the nominally independent
dialog-box management module into the PuTTY-specific config.c.
[originally from svn r9214]
2011-07-14 18:52:21 +00:00
|
|
|
struct ssh_gss_liblist *ssh_gss_setup(Conf *conf)
|
2008-08-10 13:10:31 +00:00
|
|
|
{
|
2010-09-25 07:16:56 +00:00
|
|
|
struct ssh_gss_liblist *list = snew(struct ssh_gss_liblist);
|
2008-08-10 13:10:31 +00:00
|
|
|
|
2010-09-25 07:16:56 +00:00
|
|
|
list->libraries = snew(struct ssh_gss_library);
|
|
|
|
|
list->nlibraries = 1;
|
|
|
|
|
|
|
|
|
|
list->libraries[0].gsslogmsg = "Using statically linked GSSAPI";
|
2008-08-10 13:10:31 +00:00
|
|
|
|
2010-05-19 18:22:17 +00:00
|
|
|
#define BIND_GSS_FN(name) \
|
2010-09-25 07:16:56 +00:00
|
|
|
list->libraries[0].u.gssapi.name = (t_gss_##name) gss_##name
|
2008-08-10 13:10:31 +00:00
|
|
|
|
2010-05-19 18:22:17 +00:00
|
|
|
BIND_GSS_FN(delete_sec_context);
|
|
|
|
|
BIND_GSS_FN(display_status);
|
|
|
|
|
BIND_GSS_FN(get_mic);
|
Support GSS key exchange, for Kerberos 5 only.
This is a heavily edited (by me) version of a patch originally due to
Nico Williams and Viktor Dukhovni. Their comments:
* Don't delegate credentials when rekeying unless there's a new TGT
or the old service ticket is nearly expired.
* Check for the above conditions more frequently (every two minutes
by default) and rekey when we would delegate credentials.
* Do not rekey with very short service ticket lifetimes; some GSSAPI
libraries may lose the race to use an almost expired ticket. Adjust
the timing of rekey checks to try to avoid this possibility.
My further comments:
The most interesting thing about this patch to me is that the use of
GSS key exchange causes a switch over to a completely different model
of what host keys are for. This comes from RFC 4462 section 2.1: the
basic idea is that when your session is mostly bidirectionally
authenticated by the GSSAPI exchanges happening in initial kex and
every rekey, host keys become more or less vestigial, and their
remaining purpose is to allow a rekey to happen if the requirements of
the SSH protocol demand it at an awkward moment when the GSS
credentials are not currently available (e.g. timed out and haven't
been renewed yet). As such, there's no need for host keys to be
_permanent_ or to be a reliable identifier of a particular host, and
RFC 4462 allows for the possibility that they might be purely
transient and only for this kind of emergency fallback purpose.
Therefore, once PuTTY has done a GSS key exchange, it disconnects
itself completely from the permanent host key cache functions in
storage.h, and instead switches to a _transient_ host key cache stored
in memory with the lifetime of just that SSH session. That cache is
populated with keys received from the server as a side effect of GSS
kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if
later in the session we have to fall back to a non-GSS key exchange.
However, in practice servers we've tested against do not send a host
key in that way, so we also have a fallback method of populating the
transient cache by triggering an immediate non-GSS rekey straight
after userauth (reusing the code path we also use to turn on OpenSSH
delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
|
|
|
BIND_GSS_FN(verify_mic);
|
2010-05-19 18:22:17 +00:00
|
|
|
BIND_GSS_FN(import_name);
|
|
|
|
|
BIND_GSS_FN(init_sec_context);
|
|
|
|
|
BIND_GSS_FN(release_buffer);
|
|
|
|
|
BIND_GSS_FN(release_cred);
|
|
|
|
|
BIND_GSS_FN(release_name);
|
Support GSS key exchange, for Kerberos 5 only.
This is a heavily edited (by me) version of a patch originally due to
Nico Williams and Viktor Dukhovni. Their comments:
* Don't delegate credentials when rekeying unless there's a new TGT
or the old service ticket is nearly expired.
* Check for the above conditions more frequently (every two minutes
by default) and rekey when we would delegate credentials.
* Do not rekey with very short service ticket lifetimes; some GSSAPI
libraries may lose the race to use an almost expired ticket. Adjust
the timing of rekey checks to try to avoid this possibility.
My further comments:
The most interesting thing about this patch to me is that the use of
GSS key exchange causes a switch over to a completely different model
of what host keys are for. This comes from RFC 4462 section 2.1: the
basic idea is that when your session is mostly bidirectionally
authenticated by the GSSAPI exchanges happening in initial kex and
every rekey, host keys become more or less vestigial, and their
remaining purpose is to allow a rekey to happen if the requirements of
the SSH protocol demand it at an awkward moment when the GSS
credentials are not currently available (e.g. timed out and haven't
been renewed yet). As such, there's no need for host keys to be
_permanent_ or to be a reliable identifier of a particular host, and
RFC 4462 allows for the possibility that they might be purely
transient and only for this kind of emergency fallback purpose.
Therefore, once PuTTY has done a GSS key exchange, it disconnects
itself completely from the permanent host key cache functions in
storage.h, and instead switches to a _transient_ host key cache stored
in memory with the lifetime of just that SSH session. That cache is
populated with keys received from the server as a side effect of GSS
kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if
later in the session we have to fall back to a non-GSS key exchange.
However, in practice servers we've tested against do not send a host
key in that way, so we also have a fallback method of populating the
transient cache by triggering an immediate non-GSS rekey straight
after userauth (reusing the code path we also use to turn on OpenSSH
delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
|
|
|
BIND_GSS_FN(acquire_cred);
|
|
|
|
|
BIND_GSS_FN(inquire_cred_by_mech);
|
2008-08-10 13:10:31 +00:00
|
|
|
|
2010-05-19 18:22:17 +00:00
|
|
|
#undef BIND_GSS_FN
|
2008-08-10 13:10:31 +00:00
|
|
|
|
2010-09-25 07:16:56 +00:00
|
|
|
ssh_gssapi_bind_fns(&list->libraries[0]);
|
|
|
|
|
|
|
|
|
|
return list;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void ssh_gss_cleanup(struct ssh_gss_liblist *list)
|
|
|
|
|
{
|
|
|
|
|
sfree(list->libraries);
|
|
|
|
|
sfree(list);
|
2008-08-10 13:10:31 +00:00
|
|
|
}
|
|
|
|
|
|
2010-05-19 18:22:17 +00:00
|
|
|
#endif /* NO_LIBDL */
|
|
|
|
|
|
|
|
|
|
#endif /* NO_GSSAPI */
|