search for: gss_s_complet

(I hope this message is appropriate for these lists. If not, please tell me and I won't do it again.) Hi All. There will be a new release of OpenSSH in a couple of weeks. This release contains Kerberos and GSSAPI related changes that we would like to get some feedback about (and hopefully address any issues with) before the release. I encourage anyone with an interest in

.../* Now, if we're complete and we have the right flags, then * we flag the user as also having been authenticated */ if (((flags == NULL) || ((*flags & GSS_C_MUTUAL_FLAG) && (*flags & GSS_C_INTEG_FLAG))) && (ctx->major == GSS_S_COMPLETE)) { if (ssh_gssapi_getclient(ctx, &gssapi_client)) fatal("Couldn't convert client name"); } return (status); The fatal() call there only happens when ssh_gssapi_getclient() fails, but not when one of the outer conditions f...

If I am trying to build OpenSSH 6.6 with Kerberos GSSAPI support, do I still need to get Simon Wilkinson's patches? --- Scott Neugroschl | XYPRO Technology Corporation 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 |

...s SASL, and I believe I have found a couple of bugs in Dovecot's GSSAPI implementation. The first problem is that, because of the way the client invokes libsasl, it sends a GSSAPI request which does not ask for mutual authentication. This means that on the server gss_accept_sec_context returns GSS_S_COMPLETE with a zero-length output token. Dovecot currently sends this to the client as a zero-length continuation response, but this is incorrect according to RFC 4752: what it ought to do instead is proceed straight to the security layer negotiations, and send a gss_wrap packet. The second is that Cyrus...

...char *service_name; + if (strcmp(request->auth->gssapi_hostname,"$ALL") == 0) { + auth_request_log_info(request, "gssapi", + "Using all keytab entires"); + *ret = GSS_C_NO_CREDENTIAL; + return GSS_S_COMPLETE; + } + if (strcasecmp(request->service, "POP3") == 0) { /* The standard POP3 service name with GSSAPI is called just "pop". */

How reasonable, acceptable and difficult would it be to "enhance" openssh so authorizations using kerberos (specifically kerberos tickets) consulted the authorized_keys file? And to be a bit more precise... consulted authorized_keys so it could utilize any "options" (eg. from=, command=, environment=, etc) that may be present? I'm willing to make custom changes, but

...dispatch_set(SSH2_MSG_USERAUTH_GSSAPI_TOKEN, NULL); + userauth_finish(authctxt, 0, "gssapi"); + } else { + if (send_tok.length != 0) { + packet_start(SSH2_MSG_USERAUTH_GSSAPI_TOKEN); + packet_put_string(send_tok.value, send_tok.length); + packet_send(); + } + if (maj_status == GSS_S_COMPLETE) { + dispatch_set(SSH2_MSG_USERAUTH_GSSAPI_TOKEN, NULL); + dispatch_set(SSH2_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE, + &input_gssapi_exchange_complete); + } + } + + gss_release_buffer(&min_status, &send_tok); +} + +static void +input_gssapi_errtok(int type, u_int32_t plen,...

I?m working on an implementation of ?gssapi-with-mic? authentication for my AsyncSSH package and trying to get it to interoperate with OpenSSH. I?ve gotten it working, but there seems to be a discrepancy between the OpenSSH implementation and RFC 4462. Specifically, RFC 4462 says the following in section 3.4: Since the user authentication process by its nature authenticates only the client,