similar to: Upcoming OpenSSH vulnerability

Well, after digging around and thinking some more, I'm giving up on the idea of preallocating a TTY to get post-auth privsep working on Tru64. I don't think it will work, because just allocating a TTY doesn't fix the problem - there's no valid way to tie that TTY back to the client process (because it hasn't requested a TTY yet and may not ever do so). The problem is that the

OpenSSH 3.3 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. We would like to thank the OpenSSH community for their continued support and encouragement. Changes since OpenSSH 3.2.3: ============================

Hi, I'm attempting to get openssh-3.4p1 up and running on our DEC/Compaq Alpa workstations. They are running Tru64 Unix 5.1A. I compile the package myself. Openssh-3.1 worked perfectly, with the default sshd_config file. Openssh-3.4p1 works, if I set UsePrivilegeSeparation to "no" in the sshd_config file. NOTE: I have a secondary issue with the ListenAddress default setting

A colleague was having trouble running OpenSSH 3.3p on his server. He, like many of us, has been clobbered by the mighty security penis of Theo De Raadt into enabling "privsep". But on some Linux 2.2 kernels, this is broken. Apparantly, OpenSSH "portable" relies on non-POSIX compliant mmap() features. Making the mmap() call in monitor_mm.c look something like this:

Either this never made it to the list or no one cares about Tru64. This is the last time I'll send this patch to the list. If no one steps up and finishes it or provides me with enough information to fix any remaining bugs (one being complaint that 'ssh site cmd' does not work right). If there is no activity on this for a week. I'll post it to bugzilla and will ignore any

What do we loose by not having post-auth privsep? What code is executed between authorization and actual setting of the effective uid? On Tue, 3 Sep 2002, Chris Adams wrote: > Once upon a time, Toni L. Harbaugh-Blackford <harbaugh at nciaxp.ncifcrf.gov> said: > > It appears that the integration of the sia session setup will either > > have to be rethought or abandoned

Tru64 patch will not make it into 3.5 (this is final) due to lack of willing people to test. I have given the Tru64/osf1 community almost a month to test it. And *ONE* person came forward to give me verification. And don't give me shit about "I don't have time." The person who tested it was LEAVING his employer with Tru64. He found time. IT IS YOUR GAWD DAMN PLATFORM. IF

Hi- I applied the privsep patch to Tru64 5.1A openssh 3.4p1 and it *almost* works. I get in from the client side and xauth is run, but in the meantime the server side disconnects. Running sshd in debug mode level 3 gives the following output: . . . debug1: session_input_channel_req: session 0 req shell debug1: fd 5 setting TCP_NODELAY debug1: channel 0: rfd 13

OK, I got a chance to try out the Tru64 patch for privsep. I applied the patch to 3.4p1. Partial success, in that it now works for me for logins to "root". Logins to ordinary accounts fail after authentication, when trying to set tty characteristics. See the excerpt from the debug messages below. This is for Tru64 V4.0F (with enhanced_security turned on, obviously.) I guess it's time

OpenSSH 5.9 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches,

OpenSSH 5.9 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches,

Outside the pre-auth patch by Markus to fix Cygwin and a few other platforms. SEND ME (privately) ANY required patch against the lastest snapshot. I'm doing the final commits this evening. Patches that have been temporary rejected for this release. - Owl's full patch for SysV Shm if mmap fails - mmap() on /dev/zero - mmap() on sparse file .. Not looked at the BSD/OS 5.0 patch

Well, I had just finally gotten around to downloading a snapshot to test the latest on Tru64 a couple of days ago but hadn't had a chance to build it yet, and 3.7p1 has now been released. Sigh. The problem is that Tru64 setreuid() and setregid() are broken, so privsep doesn't work. This could also be a security problem for SIA authentication in general (any version of OpenSSH on Tru64,

Hi, OpenSSH 5.9 is almost ready for release, so we would appreciate testing on as many platforms and systems as possible. This release contains a couple of new features and changes and bug fixes. Testing of the new sandboxed privilege separation mode (see below) would be particularly appreciated. Snapshot releases for portable OpenSSH are available from http://www.mindrot.org/openssh_snap/ The

Hi, OpenSSH 6.1 is almost ready for release, so we would appreciate testing on as many platforms and systems as possible. This release contains a couple of new features and bug fixes. Snapshot releases for portable OpenSSH are available from http://www.mindrot.org/openssh_snap/ The OpenBSD version is available in CVS HEAD: http://www.openbsd.org/anoncvs.html Portable OpenSSH is also available

Hi- Since the tru64 patch was designed for -current, I thought I would try to build it with a recent snapshot before backporting to 3.4p1. So I downloaded openssh-SNAP-20020826.tar.gz frpm the portable snapshots, but it does not contain the 'configure' script. I tried copying the 'configure' from 3.4p1, but that does not create a Makefile from the Makefile.in. Where are the

Wondering --- I know theo sent out a message asking vendors to get off their butts to get privlege seperation working, so what I'm wondering is whether this is happening/working/etc with Solaris? (specifically 8)...I know this is a portability question, since Sun doesn't support SSH on solaris 8. not on the list, so please CC me. thanks. adam

FYI >To: misc@openbsd.org >Subject: FreeBSD hiding security stuff >Date: Fri, 04 Mar 2005 03:51:42 -0700 >From: Theo de Raadt <deraadt@cvs.openbsd.org> > >A few FreeBSD developers apparently have found some security issue >of some sort affecting i386 operating systems in some cases. > >They have refused to give us real details. > >A promise is now being

Dear openssh-unix-dev; I recently downloaded the tarball openssh-3.4p1 and built it for my Tru64 Unix ( OSF/1 ) 5.1a system. My configure statement is: ./configure --prefix=/usr/local/security/tools/openssh-3.4p1 \ --exec-prefix=/usr/local/security/tools/openssh-3.4p1 \ -with-ssl-dir=/usr/local/security/tools/openssl-0.9.6g \ -with-zlib-dir=/usr/local/compress/tools/zlib-1.1.3 \

Hi, A bug I've had reported is that scp doesn't work with large files (Debian bug number 106809). The problem seems to be scp.c:504: if ((fd = open(name, O_RDONLY, 0)) < 0) Is there some reason why making that if ((fd = open(name, O_RDONLY|O_LARGEFILE, 0)) < 0) would break things? It seems a simple fix to me... Thanks, Matthew -- "At least you know where you are