patch almost works on 5.1A openssh 3.4p1 - get in, but get kicked out (fwd)
Toni L. Harbaugh-Blackford
harbaugh at nciaxp.ncifcrf.gov
Thu Aug 29 08:33:58 EST 2002
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
More information about the openssh-unix-dev
mailing list