similar to: No TTY prealloc; Tru64 can't do post-auth privsep

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,

On Mon, Jun 24, 2002 at 03:00:10PM -0600, Theo de Raadt wrote: > Date: Mon, 24 Jun 2002 15:00:10 -0600 > From: Theo de Raadt <deraadt at cvs.openbsd.org> > Subject: Upcoming OpenSSH vulnerability > To: bugtraq at securityfocus.com > Cc: announce at openbsd.org > Cc: dsi at iss.net > Cc: misc at openbsd.org > > There is an upcoming OpenSSH vulnerability that

On Mon, Jun 24, 2002 at 03:00:10PM -0600, Theo de Raadt wrote: > Date: Mon, 24 Jun 2002 15:00:10 -0600 > From: Theo de Raadt <deraadt at cvs.openbsd.org> > Subject: Upcoming OpenSSH vulnerability > To: bugtraq at securityfocus.com > Cc: announce at openbsd.org > Cc: dsi at iss.net > Cc: misc at openbsd.org > > There is an upcoming OpenSSH vulnerability that

I know it is just after a release, but I'm trying to see how the regression tests look on Tru64. I hadn't had a chance to really look at them before because I didn't have sudo installed on Tru64 (now I do). Anyway, for the 3.9p1 release, all of them run except for a couple of problems: - agent-ptrace fails; it looks like setgid isn't enough to kill tracing under Tru64, and I

The ls_file function in sftp-server.c calls snprintf with "%8llu" as part of the format string and a "unsigned long long" type argument. The "%ll" format is not a valid format on Tru64 (at least 4.0F). Apparently it can confuse snprintf as well - sftp-server will segfault and core dump if the user types "ls". This isn't really a needed format string on

Here is a long-overdue (sorry about that) patch for Tru64. It is pretty minor mostly (minor formatting and removal of a couple of unneeded calls), and it disables post-auth privsep (so that OpenSSH will work "out of the box" on Tru64, avoiding the many questions). I'm also looking at getting setproctitle working. For Tru64 4.x, it isn't a big deal (normal PS_USE_CLOBBER_ARGV

http://bugzilla.mindrot.org/show_bug.cgi?id=306 ------- Additional Comments From cmadams at hiwaay.net 2002-06-28 00:31 ------- I'm not seeing this on Tru64 4.0G or 5.1A with OpenSSH 3.4p1. What does "rsh [server]" say? Are you using IPv6? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

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

I am just looking for a quick answer as to whether or not OpennSSH is compatible with Digital Unix Tru64 v 4.0F. Hing Fei Wong Systems Engineer Building 100, M1309 Valley Forge, PA Admin # 4-6242 -----Original Message----- From: Darren Tucker [mailto:dtucker at zip.com.au] Sent: Friday, June 23, 2006 3:53 AM To: Wong, Hing Fei Cc: www at openbsd.org Subject: Re: OpenSSH compatibility with

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

Hi- Under privsep, I experimented with moving the session_setup_sia() out of do_child() and into do_setusercontext(), which is where the uids/gids are set to the final execution user. The call is made with a NULL tty, and this is functional provided that any later pty allocation uses grantpty() to set the device permissions. Logging in with this method shows that a utmp entry does get made for

I have "PermitRootLogin no" in my sshd_config, but under Tru64 and SIA, the root login attempts still get passed to the SIA system (so I get lots of warnings about failed root logins). On systems with a "max failed attempts" setting, the root account can be locked out this way. I started looking at the code, and I'm not sure I understand what I see. In auth-passwd.c,

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- Unfortunately, I just found out about the patch that was available for tru64 privsep. I was entirely unaware that there was a lack of support. Will the patch be considered for approval if it is applied to 3.4p1, or does it have to be done against -current? The reason I'm asking is that I have 3.4p1 working as is, so I know if I have a problem it is likely related to the patch and not

http://bugzilla.mindrot.org/show_bug.cgi?id=296 ------- Additional Comments From dtucker at zip.com.au 2003-05-12 18:42 ------- Can this bug be closed? The ChangeLog seems to indicate that it's been addressed. 20030320 [snip] - (bal) Disable Privsep for Tru64 after pre-authentication due to issues with SIA. Also, clean up of tru64 support patch by Chris Adams <cmadams at

Ok.. I need wider testing for this. I'm getting reports back it works mostly. 'ssh site ls' fails, but they can login with Privsep enbled. Can I get those who are using Tru64 or OSF/1 that have SIA enabled to test? This should apple to either -cvs or the current snapshot (I would perfer not to use 3.4p1 due to bugs). I'm going on a trip next week and will be around very spotty

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

http://bugzilla.mindrot.org/show_bug.cgi?id=653 Summary: sshd breaks logins after upgrade to 3.7.1p1 (Tru64 UNIX) Product: Portable OpenSSH Version: 3.7.1p1 Platform: Alpha OS/Version: other Status: NEW Severity: critical Priority: P2 Component: sshd AssignedTo: openssh-bugs at mindrot.org

The Cray and tru64 patches I have, have been applied. Unless there is any major "oh my god it does not work". I believe 3.6 should now be ready for release soon. I'd like to thank everyone for providing feedback on the status of their their platform. Hopefully, we have not missed any platform that is commonly used. - Ben