similar to: openssh-3.4p1 built on Tru64 Unix 5.1a - bug with sftpd

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

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

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

Hi Toni, I'm sorry, I haven't had much time to work on this today. When I run sshd (from the patched snapshot) in a debugger, with a breakpoint early in setup_sia(), this is what I find after connecting with a client: (1) There are two sshd processes. One is running as root, and the other as the user I logged with using the client. The root process is the one in the debugger,

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

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

We are using rsync to maintain a warm mirror of our boot disks. I just updated to rsync 2.6.0 and noticed that the rsync runs are now getting errors when copying sockets. The system is running Tru64 5.1A pk 4 on an AlphaServer 4100. Is this a bug? Is there some way to not copy sockets or should I find all of them and add them to the exclude file? rsync was built using a straight ./configure

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

Hi, I have recently loaded Openssh 3.4p1 on an Tru64 Unix 5.1A system. I followed the installation instructions described in INSTALL, essentially using all default settings, and it went throught without any obvious errors. I can then use the root account to initiate outbound and inbound ssh calls, and can log on without any problems. The trouble is that when I try to use ssh to log in (from a

http://bugzilla.mindrot.org/show_bug.cgi?id=429 mouring at eviladmin.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE Summary|SSH 3.4p1 problems on Tru64 |SSH 3.4p1 problems

Hi- I built openssh-3.0p1 on a Tru64 4.0G without any problem. The system uses enhanced security, so the sia_* routines are used by sshd. Unfortunately, password authentication fails because sia_ses_authent() returns 0 in auth-sia.c. The thing is, the password is CORRECT; I verified this by inserting debugging statements before the call to sia_ses_authent(). The call to sia_ses_init()

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

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

http://bugzilla.mindrot.org/show_bug.cgi?id=429 Summary: SSH 3.4p1 problems on Tru64 V4.0D & Tru64 V4.0F Product: Portable OpenSSH Version: 3.4p1 Platform: Alpha OS/Version: OSF/1 Status: NEW Severity: major Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org

http://bugzilla.mindrot.org/show_bug.cgi?id=933 Summary: compile problem on tru64 5.1A code outside of a #ifdef that should not be included on tru64 Product: Portable OpenSSH Version: 3.8p1 Platform: Alpha OS/Version: OSF/1 Status: NEW Severity: normal Priority: P2 Component: Build

http://bugzilla.mindrot.org/show_bug.cgi?id=1007 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- OS/Version|All |Tru64 Component|sftp |ssh CC| |djm at

This is less of a question and more of just an FYI to any other poor soul that happens to run into the same problem that I just spent 3 hours trying to correct. I was working on getting rsync 3.0.3 compiled on a TRU64 5.1 alpha system, using the provided (compaq?) c-compiler. The first step was to set the compile flags: CC=cc CFLAGS='-std1 -O' export CC CFLAGS Then run the configure

http://bugzilla.mindrot.org/show_bug.cgi?id=533 ------- Additional Comments From djm at mindrot.org 2003-06-04 23:35 ------- Could you try adding a "#define BROKEN_GETADDRINFO 1" to config.h and then doing a "make clean ; make" (don't rerun configure after adding the #define) Please tell us whether or not that helps? ------- You are receiving this mail because:

https://bugzilla.mindrot.org/show_bug.cgi?id=1007 --- Comment #16 from Darren Tucker <dtucker at zip.com.au> 2008-01-01 04:57:07 --- Created an attachment (id=1431) --> (http://bugzilla.mindrot.org/attachment.cgi?id=1431) Make ssh-rand-helper close all fds above STDERR Random thought: I wonder if some commands are making unwarranted assumptions about the descriptors they inherit?

https://bugzilla.mindrot.org/show_bug.cgi?id=1007 --- Comment #17 from Damien Miller <djm at mindrot.org> 2009-08-18 11:12:32 EST --- Can't replicate this and can't diagnose without a truss or similar; ssh-rand-helper includes subcommand timeout logic that should avoid this. Please reopen if it recurs and you can trace it. -- Configure bugmail: