subversion svn/svnserve SASL with GSSAPI auth not working (for me)

[Dan White]

On 09/02/12 18:26 -0400, Curtis Villamizar wrote:
>
>I'm running FreeBSD 8.3, SASL 2.1.25_2 and subversion 1.7.5.  I'm
>using the supplied heimdal (not from ports collection).
>
>In a past life I swithed from a cvs repository using krb5 to svn using
>GSSAPI but I don't have access to that config.  It was also 2008 and I
>think it was subversion 1.5, the first to support SASL.
>
>I've tried various combinations in svn.conf on the server side with no
>luck.  The best I get is:
>
>  % kinit
>  <user>@<KRB5-REALM>'s Password:
>  % svn checkout svn://<host>/trunk/home home
>  svn: E170001: Unable to connect to a repository \
>        at URL 'svn://<host>/trunk/home'
>  svn: E170001: Authentication error from server: \
>        SASL(-1): generic failure: GSSAPI Error:  \
>        No credentials were supplied, \
>	or the credentials were unavailable or inaccessible. \
>	(unknown mech-code 0 for mech unknown)
>  % klist
>  Credentials cache: FILE:/home/<user>/.krb/_O
>          Principal: <user>@<krb5-realm>
>    Issued           Expires          Principal
>  Sep  2 17:00:24  Sep  3 03:00:24  krbtgt/<krb5-realm>@<krb5-realm>
>  Sep  2 17:04:35  Sep  2 21:04:35  svn/<host>@<krb5-realm>
>
>[ line continue added for readability.  <user>, etc is an edit. ]
>
>AFAIK there is no way to enable any sort of verbose logging of the
>authentication on the client side without editing the SASL code.
>
>On the server side all I get is:
>
>  # su -m svn -c 'sh -c "/usr/local/bin/svnserve.bin -6 -X \
>        --foreground --listen-port=3690 --listen-host <ipv6addr> \
>	-r <repos-path>"'
>  svnserve: E210002: Network connection closed unexpectedly
>
>The above is with log level 7.  (Not very helpful IMHO).
>
>Obviously since I got back svn/<host>@<krb5-realm> in klist, the server
>side has found the krb5-keytab file.  On the server side the svn.conf
>file contains:
>
>  mech_list: GSSAPI DIGEST-MD5
>  keytab: /home/svn/krb5-keytab
>  log_level: 7
>
>The svnserve.conf file in the repos contains:
>
>  [general]
>  anon-access = none
>  auth-access = write
>  realm = <krb5-realm>
>  ### authz-db selects an authz file - see comments there
>  ### force case of usernames when accessing authz-db file (none,lower,upper)
>  #authz-db = authz
>  #force-username-case = lower
>
>  [sasl]
>  #  use-sasl disables all other authentication (A Good Thing (tm) imho)
>  use-sasl = true
>  min-encryption = 56
>  max-encryption = 2048
>
>[ aside : preliminary results of looking into the code ...
>
>  I did some poking into the code of svn, svnserve, and sasl to see if
>  there was any debugging or logging that could be enabled, or to just
>  find a good place to add logging, but haven't found anything.
>
>  The following yields nothing in the sasl code and subversion code:
>
>    find * -type f | xargs egrep -l 'unknown mech-code|mech unknown'
>
>  Probably a consequence of internationalization (further
>  obstrufication).

'unknown mech-code 0 for mech' appears in several sasl and non-sasl related
returns with a google search. I guess that it originates from heimdal.

Check your kdc logs. This could be something as simple as a dns
disagreement as to what principal the server should be using.

The order, as I understand it, is:

The client obtains a TGT from the kdc
The client initiates a connection with the svn server
The server returns with a string that contains the supported sasl
mechanisms
The client chooses an appropriate mechanism
If gssapi, then:
   obtain a service ticket from the kdc
   complete authentication with the svn server using the service ticket
   (this step is where things appear to go awry, and points to a possible
   service name mismatch)

Make sure that your server contains a matching keytab entry as in your
svn/<host>@<krb5-realm> output from above. Explicitly provide a hostname
within your svnserv.conf, for sasl initialization, if it allows for such a
configuration. If not, verify that 'hostname -f' looks correct on your svn
server.

If you restart your svn server, you should see which principal it is
requesting from your kdc (or at least, the first time it initializes sasl).

>  It appears as though the error is passed from the server to client
>  based on "Authentication error from server" in the message.  That
>  string is found in libsvn_ra_svn/cyrus_auth.c (client side) at line
>  908, which is quite a ways down in svn_ra_svn__do_cyrus_auth and
>  follows a call to try_auth.  try_auth calls sasl_client_start and
>  I'm guessing that the "(unknown mech-code 0 for mech unknown)" in
>  the error response has something to do with the "case SASL_NOMECH:"
>  which is followed by "return
>  svn_error_create(SVN_ERR_RA_SVN_NO_MECHANISMS, NULL, NULL);".
>
>  If so, the tickets get passed about successfully indicating the
>  GSSAPI was tried and succeeded, yet sasl_client_start returns
>  SASL_NOMECH.  There is comment indicating that this in not handled
>  (line 1248 in cyrus-sasl-2.1.25/lib/server.c).
>
>  If plugin->mech_avail returns SASL_NOTDONE we could get SASL_NOMECH.
>  If somehow SASL_NEED_PROXY or SASL_NEED_HTTP were set we could get
>  SASL_NOMECH.  Perhaps these should have a sasl_seterror before the
>  return statement (on or about line 1294 in server.c).
>
>  The above are in mech_permitted in server.c, called by
>  sasl_server_start.  Perhaps logging after that call would help.
>
>  Following the conditional "if (m->m.condition == SASL_CONTINUE) {"
>  at line 1424 is a series of "if (result == SASL_OK) {" conditionals,
>  each doing a next step.  A better approach might be a "if (result !=
>  SASL_OK) {" followed by a log message and a goto.  If goto is not
>  liked, then do a "do ... while (0)" which always does the inside
>  once (or "for (__i=0;__i==0;++__i)" if that is more clear) and then
>  use a break rather than a goto.  This way each casue of failure can
>  be logged.
>
>... end aside ]
>
>Perhaps someone on this list has a clue as to why I'm seeing this
>problem.  Otherwise I'll edit the above code and send diffs that help
>isolate the problem.  I then hope those diffs will be taken to make it
>easier for the next person to figure out where a problem is coming
>from without editing the code to do it.  Note that the diffs I'm
>suggesting would not change what the code does, just add logging.
>
>At best these diffs will point me closer to which plugging function to
>look at (to then add logging to further isolate, ... and so on).
>
>Curtis
>

-- 
Dan White