similar to: updated gssapi diff

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 |

Hello! Please consider including the attached patch in the next release. It allows one to drop privilege separation code while building openssh by using '--disable-privsep' switch of configure script. If one doesn't use privilege separation at all, why don't simply allow him to drop privilege separation support completely? -- Sincerely Your, Dan. -------------- next part

It took me a while to track this down. I am using MIT Kerberos 1.4.3 and libgssapi-0.7. With some patches that came with Suse 10, but that doesn't appear to be relevant. I have been using openssh-4.2p1 (with Simon's patches) and openssh-4p3p2 out of the box. I see the same problem no matter which version of openssh I am using. I am using two Suse Linux x86 boxes as a test

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,

I'm trying to troubleshoot gssapi_with_mic authentication with OpenSSH 5.2p1 on FreeBSD 8.0. If I run sshd with maximum debug "sshd -ddd" the most detail I get is: GSSAPI MIC check failed That comes from line 282 in auth2-gss.c 279 if (!GSS_ERROR(PRIVSEP(ssh_gssapi_checkmic(gssctxt, &gssbuf, &mic)))) 280 authenticated =

As you know, revoking RSA/DSA keys in an SSH environment requires editing all authorized_keys and authorized_keys2 files that reference those public keys. This is, well, difficult at best but certainly very obnoxious, particularly in a large environment. SSH key management is difficult. This patch simplifies key management wherever GSS-API/Kerberos is used and is general enough to be used with

Hi all, I am compiling the OpenSSH4.7p1 on hp-ux PA11.23 system, however, it gives the following bug: cc +DD64 -I. -I. -I../include/openssl -I../include/tcpwrap -I../include/zlib -D_HPUX_SOURCE -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED=1 -I/usr/local/include -I../include/gssapi -DSSHDIR=\"/opt/ssh/etc\" -D_PATH_SSH_PROGRAM=\"/opt/ssh/bin/ssh\"

Hello, I have a compile problem concerning samba-3.0.0 (final) with gssapi on a Solaris 9 machine. I don't know how to fix this, so any suggestions are welcome. Situation: We use LDAP to authenticate logins of a group of users, so I want to use this LDAP directory also from samba. (Openldap-2.1.22 was compiled with BerkeleyDB.4.1, heimdal-0.6 kerberos, and cyrus-sasl-2.1.13). After a

Signed-off-by: Johannes L?thberg <johannes at kyriasis.com> --- gss-serv-krb5.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/gss-serv-krb5.c b/gss-serv-krb5.c index 795992d9..a12bb244 100644 --- a/gss-serv-krb5.c +++ b/gss-serv-krb5.c @@ -106,6 +106,11 @@ ssh_gssapi_krb5_userok(ssh_gssapi_client *client, char *name) } else retval = 0; +#ifdef USE_PAM + if

Playing around with the [wonderful] GSS-API patches for OpenSSH [1] I noticed that there is a bit of functionality missing from OpenSSH/GSS-API, namely that authorized_keys2 has no meaning when using GSS authentication. Yes, ~/.k5login can be used to grant access to an account for applications that support Kerberos, as does OpenSSH with those GSS patches, but .k5login does not and cannot provide

On Jan 17, 2017, at 9:57 AM, Douglas E Engert <deengert at gmail.com> wrote: > On 1/16/2017 2:09 PM, Ron Frederick wrote: >> 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.

Trying to update to dovecot-1.0.alpha5 and seeing this at compile time: mech-gssapi.o mech-gssapi.c; then mv -f ".deps/mech-gssapi.Tpo" ".deps/mech-gssapi.Po"; else rm -f ".deps/mech-gssapi.Tpo"; exit 1; fi mech-gssapi.c:30:27: gssapi/gssapi.h: No such file or directory mech-gssapi.c:42: error: syntax error before "gss_ctx_id_t" mech-gssapi.c:51: error:

As far as I know this patch has no security implications -- I don't believe that allowing sshd to use get_local_name() (in canohost.c) on a connected socket to determine it's own fqdn will allow a malicious client (or router or dns server) to make it come to the wrong conclusion. But please let me know if you think I'm wrong. Please also let me know if you're just not interested

Gssapi is failing at the following statement in sshconnect2.c, ok never gets set to 1:: ssh_gssapi_check_mechanism fails /* Check to see if the mechanism is usable before we offer it */ while (mech < gss_supported->count && !ok) { /* My DER encoding requires length<128 */ if (gss_supported->elements[mech].length < 128 &&

Hi, Was trying to use the gssapi support and the authentication would consistently die for me. The following patch fixes: --- src/auth/mech-gssapi.c.orig 2006-01-10 15:46:10.000000000 +1300 +++ src/auth/mech-gssapi.c @@ -138,7 +138,7 @@ static OM_uint32 obtain_service_credenti return major_status; } - gss_release_name(&minor_status, gss_principal); +

This patch (to OpenSSH 3.0.2p1) adds support for using krb4, krb5 and other principal names in authorized_keys entries. It's a sort of replacement for .klogin and .k5login, but it's much more general than .k*login as it applies to any authentication mechanism where a name is associated with the ssh client and it supports name patterns and all the normal authorized_keys entry options

http://bugzilla.mindrot.org/show_bug.cgi?id=1073 Summary: if userok rejects a user their creds still get set Product: Portable OpenSSH Version: 3.9p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Kerberos support AssignedTo: bitbucket at mindrot.org

Hi all, It looks like a bug for me, but I'd like to ask if someone has the same problem. We are using OpenSSH 4.3p2 from Debian 4.0 (stable), but the same problem is with original OpenSSH 4.3p2. When root logins with his kerberos ticket and then logout, his ticket remains on the machine. I found in source (sshd.c) in privsep_postauth function, that if root logins then use_privsep is set to 0

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

Hello, ALL. I am trying to organize a transparent single sign-on concept for my Active Directory users into Dovecot via IMAP. On the user's desktop I use Thunderbird 6.0 as a mail client (MUA), Windows XP as an operating system. Domain is controlled by Windows 2008 Server SP2 with Active Directory. I have installed on my Mail server Debian GNU/Linux 6.0.2 (Squeeze) and Dovecot 2.0.13 from