similar to: GSSAPI Key Exchange Patch for OpenSSH 5.0p1 (plus an added extra)

Somewhat belatedly, I'm pleased to announce the availability of my GSSAPI key exchange patches for OpenSSH 5.2p1. Apologies for the delay in getting these out, a honeymoon, followed by the pressure of work, made the first half of this year rather busy! Whilst OpenSSH contains support for GSSAPI user authentication, this still relies upon SSH host keys to authenticate the server to the

From the better-late-than-never-department, I'm pleased to announce the availability of my GSSAPI Key Exchange patches for OpenSSH 5.3p1. This is a pretty minor maintenance release - it contains a couple of fixes to take into account changes to the underlying OpenSSH code, and a compilation fix for when GSSAPI isn't required. Thanks to Colin Wilson and Jim Basney for their bug reports.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm pleased to (finally) announce the availability of my GSSAPI Key Exchange patch for OpenSSH 4.7p1. Whilst OpenSSH contains support for doing GSSAPI user authentication, this only allows the underlying security mechanism to authenticate the user to the server, and continues to use SSH host keys to authenticate the server to the

Hi, I'm pleased to be able to announce the availability of my GSSAPI Key Exchange patch for OpenSSH 4.4p1. This patch adds RFC4462 compatibility to OpenSSH, along with adding additional GSSAPI support that is yet to make it into the main tree. The patch implements: *) gss-group1-sha1-*, gss-group14-sha1-* and gss-gex-sha1-* key exchange mechanisms. This can be enabled through the

Hi, I'm pleased to announce the availability of my GSSAPI Key Exchange patch for OpenSSH 4.6p1. This patch adds support for the RFC4462 GSSAPI key exchange mechanisms to OpenSSH, along with some minor fixes for the GSSAPI code that is already in the tree. The patch implements: *) gss-group1-sha1-*, gss-group14-sha1-* and gss-gex-sha1-* key exchange mechanisms. (#1242) *)

http://bugzilla.mindrot.org/show_bug.cgi?id=1218 Summary: GSSAPI client code permits SPNEGO usage Product: Portable OpenSSH Version: 4.3p2 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Kerberos support AssignedTo: bitbucket at mindrot.org ReportedBy:

Hi, I'm pleased to announce the availability of my GSSAPI Key Exchange patch for OpenSSH 5.7p1. In addition to adding support for key exchange, vital for enterprise users of SSH and Kerberos, it also adds a number of other GSSAPI related features: *) Cascading Credential Renewal - when enabled, credentials renewed on your local workstation are automatically forwarded to hosts

Hello, Kevin Way wrote: > I'm curious if there are technical (or other) reasons that prevent > FreeBSD from adding RFC 4462 (GSSAPI Key Exchange) support to sshd. > The MIT Kerberos team first requested this four years ago, and > implementation patches have been available for years at: > http://www.sxw.org.uk/computing/patches/openssh.html > > The author of those

Now that RFC 4462 has been published, I was wondering if there would be any interest in looking again at integrating the key exchange portions of my GSSAPI patch into the OpenSSH tree? As I've mentioned before, key exchange has significant benefits for large sites as it allows them to use Kerberos to authenticate ssh hosts, and removes the need to maintain and distribute ssh known_hosts

Hi, This is to announce the availability of a new version of my GSSAPI key exchange patch for OpenSSH. The code is available from http://www.sxw.org.uk/computing/patches/openssh.html Changes since the last release are: *) Implement GSS group exchange *) Disable DNS canonicalization of the hostname passed to the GSSAPI library - an option is provided to allow this to be overriden on

Patches supporting GSSAPI Key Exchange in OpenSSH 4.3p2 are now available from http://www.sxw.org.uk/computing/patches/openssh.html These patches add support for performing GSSAPI key exchange to the OpenSSH client and server. Whilst OpenSSH contains support for using GSSAPI in the user authentication step, this is inadequate for many sites, as it doesn't provide a mechanism for using

>From a security standpoint, if the default keytab (/etc/krb5.keytab) contains only ONE principal, does it matter if GSSAPIStrictAcceptorCheck is set to "yes" or "no"? My company uses an internally built OpenSSH package that includes the GSSAPI Key Exchange patch. Because we have 1000s of hosts, we need to use a "standard" sshd_config file that works for the

[ If you're not familiar with the GSSAPI key exchange patches, or unsure why they make OpenSSH usable in large Kerberos deployments, http://www.sxw.org.uk/computing/patches/openssh.html contains some background information ] Regular readers of these emails will be aware that they've recently all begun with apologies for the delay in producing the patch - this has been down to a poor tool

Will Simon Wilkinson's GSSAPI Key Exchange patch ever be incorporated into the OpenSSH source? http://www.sxw.org.uk/computing/patches/openssh.html I'm sure I'm not the only one that uses it and would like to see it become part of the OpenSSH source. Is there something missing or is there some technical/philosophical reason for not including it?

Dear all, (apologoies - this has nothing to do with 4.7 being out, but is rather a long-standing issue that regularly bites us). Is there anything I could do to further the case of https://bugzilla.mindrot.org/show_bug.cgi?id=1008 As a summary, GSSAPI auth against machine in a DNS load-balanced server farm fails. SSH-1 Kerberos works. DNS load-balanced farm: Individual machines in the farm

are these patches in in 5.2.p1?Kerberos/GSSAPI Support in OpenSSH http://www.sxw.org.uk/computing/patches/openssh.html *Key exchange **Cascading Credentials *Thanks, Tedc

Hi guys, I have a server setup with openssh-5.0p1 and use some users as sftp-only chroot accounts. The following configuration yields exactly the result I want: user is chrooted, logs to syslog, all is good. #================================================# Subsystem sftp internal-sftp -f AUTHPRIV -l VERBOSE Match User fredwww ChrootDirectory %h #ForceCommand internal-sftp

On Solaris 10 (SPARC & x86), I'm seeing the following error: error: Failed to allocate internet-domain X11 display socket. I tracked this down to this code change between openssh 4.7p1 and 5.0p1: *** openssh-4.7p1/channels.c Mon Jun 25 03:04:47 2007 --- openssh-5.0p1/channels.c Wed Apr 2 15:43:57 2008 *************** *** 1,4 **** ! /* $OpenBSD: channels.c,v 1.270 2007/06/25 08:20:03

On Sun, May 4, 2008 at 12:00 PM, Dan Yefimov <dan at nf15.lightwave.net.ru> wrote: > On Sun, 4 May 2008, john wrote: > > > > What exact steps have you taken to accomplish what Damien proposed? > > > > > Yes sorry Dan, I should have been specific. > > > > I created a file in my chroot root called /home/dev/auth.log > > > > Then I

I've implemented the /dev/log socket inside my chroot environment. I'm able to log the users interactions with the server, but I have one remaining issue. The logs don't contain and usernames or userids. The process ID is logged and we could go through and try to associate the process ID with the user who logged in, but I was hoping to find an easier way. We need to be able to