Toni L. Harbaugh-Blackford
2002-Aug-28 22:33 UTC
patch almost works on 5.1A openssh 3.4p1 - get in, but get kicked out (fwd)
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 isatty debug1: fd 13 setting O_NONBLOCK debug2: fd 12 is O_NONBLOCK debug1: Setting controlling tty using TIOCSCTTY. debug3: mm_answer_pty: tty /dev/pts/2 ptyfd 4 debug3: mm_request_receive entering debug3: monitor_read: checking request 38 Error in terminal setup. Couldn't establish session for harbaugh from ncihp1.ncifcrf.gov debug1: Calling cleanup 0x120055cac(0x140031cc8) debug1: session_pty_cleanup: session 0 release /dev/pts/2 debug1: Calling cleanup 0x12005d934(0x0) Connection closed by remote host. debug1: channel_free: channel 0: server-session, nchannels 2 debug3: channel_free: status: The following connections are open: #0 server-session (t4 r0 i0/0 o0/0 fd 13/12) debug3: channel_close_fds: channel 0: r 13 w 12 e -1 debug1: channel_free: channel 1: X11 inet listener, nchannels 1 debug3: channel_free: status: The following connections are open: debug3: channel_close_fds: channel 1: r 14 w 14 e -1 debug1: session_close: session 0 pid 16039 debug3: mm_request_send entering: type 27 mm_request_send: write debug1: Calling cleanup 0x12006c9f4(0x0) debug1: Calling cleanup 0x12005d934(0x0) I added some debugging to session.c, so on the client side it looks like this: . . . debug3: tty_make_modes: 91 1 debug3: tty_make_modes: 92 0 debug3: tty_make_modes: 93 0 debug2: x11_get_proto /usr/bin/X11/xauth list 129.43.3.127:10.0 2>/dev/null debug1: Requesting X11 forwarding with authentication spoofing. debug1: channel request 0: x11-req debug1: channel request 0: shell debug1: fd 4 setting TCP_NODELAY debug2: callback done debug1: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 debug3: in do_child before PRIVSEP setup_sia, options.use_login=0,use_privsep=1 debug3: before PRIVSEP setup_sia, use_privsep=1 debug3: mm_setup_sia entering debug3: mm_request_send entering: type 38 Compaq Tru64 UNIX V5.1A (Rev. 1885); Fri Aug 23 13:12:42 EDT 2002 On Wed Nov 21 14:03:06 EST 2001 your system was successfully updated from: Compaq Computer Corporation Tru64 UNIX V5.1 (Rev. 732) On Wed Nov 21 11:06:42 EST 2001 your system was successfully updated from: Compaq Computer Corporation Tru64 UNIX V4.0G (Rev. 1530) On Wed Dec 13 12:44:21 EST 2000 your system was successfully updated from: Digital UNIX V4.0D [Rev. 878]; Tue Jun 6 16:09:57 EDT 2000 Environment: USER=harbaugh LOGNAME=harbaugh HOME=/users/primgr/harbaugh PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/inst/openssh-3.4p1/bin MAIL=/var/spool/mail/harbaugh SHELL=/bin/csh SSH_CLIENT=129.43.3.127 49978 22 SSH_TTY=/dev/pts/2 TERM=xterm DISPLAY=localhost:10.0 debug3: channel_close_fds: channel 0: r -1 w -1 e -1 debug3: channel_close_fds: channel 1: r 14 w 14 e -1 Running /usr/bin/X11/xauth add unix:10.0 MIT-MAGIC-COOKIE-1 d87847e37dc8566520d60c3c3fbb7318 debug1: Received SIGCHLD. debug1: channel_free: channel 0: client-session, nchannels 1 debug3: channel_free: status: The following connections are open: #0 client-session (t4 r0 i0/0 o0/0 fd 5/6) debug3: channel_close_fds: channel 0: r 5 w 6 e 7 Connection to fchelp closed by remote host. Connection to fchelp closed. debug1: Transferred: stdin 0, stdout 0, stderr 75 bytes in 0.4 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 177.9 debug1: Exit status -1 Do you have some idea where the 'Error in terminal setup' is coming from? Since the debug messages I added to session.c are going to the client, something is happening to the tty outside of the mm_setup_sia function. It doesn't seem right that the server is disconnecting at this point, since the environment is already setup. Any ideas or suggestions? Thanks, Toni On Wed, 28 Aug 2002, Ben Lindstrom wrote: > > I'm sorry people like you have to suffer for this.. But the decision was > made that this patch won't make it into OpenSSH 3.5p1. If enough people > test it and verify that it is correct then it will go into 3.6p1. > > I've spent 3 months working on this harassing five different people for > testing, and only one of those five bothered to confirm in private it > worked. Which was not enough for it to go in. I stated I required two to > three people to sign off on it. > > www.mindrot.org has instructions on joining openssh-unix-dev at mindrot.org > list. When you get done testing (including, if you can, the regress/ > tests) post your results to that list. > > But someone from HP/Compaq or the Tru64 community is going to have to take > an active support role for their platform. I neither have the time nor > energy to do so since I'm suppose to be offically doing care and feeding > of AIX (4.x and 5.x) and NeXTStep. > > - Ben > > On Wed, 28 Aug 2002, Toni L. Harbaugh-Blackford wrote: > > > Ben- > > > > On Wed, 28 Aug 2002, Ben Lindstrom wrote: > > > > > > > > http://bugzilla.mindrot.org/show_bug.cgi?id=296 > > > > > > Points to the last patch I'll do for the Tru64 community due to their lack > > > of interest. I won't go into it because I just got down screaming at the > > > top of my lungs at openssh-unix-dev at mindrot.org about lack of Tru64 > > > community support. > > > > I'M INTERESTED !!!! :D > > > > We'll be running alphas at our sight for the forseeable future, and infact we > > are hoping to get some EV7 systems in here by November. So I'll have to > > keep building openssh for the duration. > > > > I don't use the ssh that our 'vendor of the moment' HP provides, because it > > does not include tcp wrappers support. > > > > Who are these people who are *NOT* interested?!! >:-( > > > > Yes, the OS is not going to get new features, but for as long as there are > > new alpha systems shipped it WILL continue on. > > > > > > > > I've gotten good feedback. The patch is against the --current tree, but > > > may apply without too much of a problem for 3.4p1. > > > > > > - Ben > > > > > > > I'll give it a shot. Thanks! > > Toni > > > > > On Wed, 28 Aug 2002, Toni L. Harbaugh-Blackford wrote: > > > > > > > Hi-- > > > > > > > > I was just wondering if anyone has gotten any further with fixing > > > > the problem with privilege separation and tru64 SIA. > > > > > > > > Thanks, > > > > Toni > > > > > > > > On Sun, 30 Jun 2002, Ben Lindstrom wrote: > > > > > > > > > > > > > > The issue is in how SIA does it's work. Under privsep by time the session > > > > > is being initialized it is no longer root. Which causes it to throw a > > > > > fit. > > > > > > > > > > I have a partial patch which implement SIA session handling in the same > > > > > way PAM is done, but I'm still running into problems with the SIA session > > > > > not accepting the sia session establish command. > > > > > > > > > > You can gain pre-authenation privsep security by setting > > > > > 'BROKEN_FD_PASSING' in config.h and recompiling. This will do privillege > > > > > seperation up through the login screen, but it will then revert back to > > > > > standard way of handling SSH sessions afterwards (single process). > > > > > > > > > > I have a few people gathering eror messages for me so hopefully we can > > > > > solve this problem. I can provide you with what I have of the patch, but > > > > > it does not get you any farther at this point. > > > > > > > > > > - Ben > > > > > > > > > > On Thu, 27 Jun 2002, Toni L. Harbaugh-Blackford wrote: > > > > > > > > > > > Hi- > > > > > > > > > > > > FYI, the failure appears to be related to privilege separation. > > > > > > > > > > > > Setting 'UsePrivilegeSeparation no' in sshd_config allows sshd to work > > > > > > properly. > > > > > > > > > > > > ---------- previous message ---------- > > > > > > Date: Thu, 27 Jun 2002 11:29:42 -0400 (EDT) > > > > > > From: Toni L. Harbaugh-Blackford <harbaugh at nciaxp.ncifcrf.gov> > > > > > > To: secureshell at securityfocus.com > > > > > > Cc: Toni L. Harbaugh-Blackford <harbaugh at nciaxp.ncifcrf.gov> > > > > > > Subject: openssh 3.4p1 + Tru64 4.0G + SIA = "Account is disabled -- see Account > > > > > > Administrator" > > > > > > > > > > > > Hi- > > > > > > > > > > > > I just built openssh 3.4p1 on Tru64 4.0G with Enhanced Security. > > > > > > I set up the privilege separation stuff as directed, but I get the message > > > > > > > > > > > > Account is disabled -- see Account Administrator > > > > > > > > > > > > after giving my password when I attempt to log in. I am running the new > > > > > > version on an alternate port while the old version is still running on > > > > > > the standard port. > > > > > > > > > > > > Has anyone seen this problem? > > > > > > > > > > ----------------------------------------------------------------------- > > Toni Harbaugh-Blackford harbaugh at nciaxp.ncifcrf.gov > > AlphaServer 8400 System Administrator > > SAIC/NCI Frederick Advanced Biomedical Computing Center > > > > > > ----------------------------------------------------------------------- Toni Harbaugh-Blackford harbaugh at nciaxp.ncifcrf.gov AlphaServer 8400 System Administrator SAIC/NCI Frederick Advanced Biomedical Computing Center
Seemingly Similar Threads
- tru64 patch: openssh-SNAP-20020826.tar.gz does not contain 'configure', so how to build?
- interested tru64 unix person - privsep patch against 3.4p1 + howto /regress
- uid transition and post-auth privsep (WAS Re: possible fundamental problem with tru64 patch) (fwd)
- tru64 sia: move call of session_setup_sia() to do_setusercontext(), letting grantpty() and friends handle pty perms
- openssh-3.0p1 + Tru64 4.0G: sia_ses_authent() always returns 0 (failure)