search for: basney

...mechanism into the display_error routine in order to get better error messages back. As both MIT and Heimdal are moving towards supporting pluggable GSSAPI mechanisms, it would be good to fix this. The attached two line patch against CVS resolves this problem (which was originally reported by Jim Basney) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

https://bugzilla.mindrot.org/show_bug.cgi?id=958 Christoph Anton Mitterer <calestyo at scientia.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |calestyo at scientia.net --- Comment #3 from Christoph Anton Mitterer <calestyo at

Hi, When building OpenSSH 5.2p1 on MacOSX 10.6.0, I get the following ld error gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o mux.o -L. -Lopenbsd-compat/ -fstack-protector-all -lssh -lopenbsd-compat -lcrypto -lz Undefined symbols: "_res_9_query", referenced from: _getrrsetbyname in libopenbsd-compat.a(getrrsetbyname.o)

...unce 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. I'd like to thank the distributors who've been patiently waiting for me to get this done - sorry once again for the delay. Why? ---- Whilst OpenSSH contains support for GSSAPI user authentication, this still relies upon SSH host keys to authenticate the server to th...

...er to give the GSSAPI acceptor identity (Kerberos principal) which the server will use to accept their request. It is useful in situations such as port forwarding, where the name that must be used to reach a particular host doesn't match the name that that machine knows itself by. Thanks to Jim Basney for this code! Cheers, Simon.

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 =

...: amd64 OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: Kerberos support Assignee: unassigned-bugs at mindrot.org Reporter: thomas.downes at ligo.org This is effectively a bump of bug 958, filed by Jim Basney, to the current version of openssh. Jim maintains a patch for openssh which enables authentication with GSI GSSAPI. Effectively it enables single-sign-on with certificate verification by the client of the host and of the client by the host. This is in use securely by a large number of users in sci...

In an environment where users use smart cards to authenticate on Windows and then use ssh to login to UNIX systems via GSSAPI, it is nigh impossible to renew/refresh the Kerberos credentials in the UNIX session. If the user fails to renew their credentials before they expire, the user is stuck and must log out and log back in to get valid tickets. Meanwhile it is entirely likely that on the

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, When I use an ssh client built from the openssh.org OpenSSH_5.1p1 sources on Mac OS 10.5.5 (Darwin Kernel Version 9.5.0: Wed Sep 3 11:29:43 PDT 2008; root:xnu-1228.7.58~1/RELEASE_I386 i386), I get the following error when trying to launch an xterm in a remote ssh session: debug1: client_input_channel_open: ctype x11 rchan 3 win 2097152 max 16384 debug1: client_request_x11: request from

Hello OpenSSH developers, I hope you won't mind confirming something for me. Recently an OpenSSH user objected to me about the sshd exiting with status 0 when the bind to port 22 fails ("Address already in use"), because it makes it not obvious to the init script that something went wrong in sshd startup. As I understand it, this behavior is due to the sshd calling daemon() before