openssh bugs - Aug 2005 - [Bug 1069] session being terminated after succesful authentication

http://bugzilla.mindrot.org/show_bug.cgi?id=1069

           Summary: session being terminated after succesful authentication
           Product: Portable OpenSSH
           Version: 4.1p1
          Platform: UltraSparc
        OS/Version: Solaris
            Status: NEW
          Severity: major
          Priority: P2
         Component: sshd
        AssignedTo: bitbucket at mindrot.org
        ReportedBy: shespelt at bear.com


Hi,
I'm very new to using/configuring/testing OpenSSH & I'm trying to do
some testing of sshd/ssh 4.1p1 to determine the correct configuration
settings, etc. to get an ssh gateway working on an intermediate host
between 1 sshd host and another ssh client host.

I'm not empowered with root privileges [when deployed, the sshd daemon
will be run as root] but I've convinced our SA group to at least chown
root:sys the sshd & ssh binaries and to set the setuid bit on those
binaries (this is needed as the geteuid checking in login_write() causes
the daemon to exit if running in -D mode). 
Unfortunately, using the setuid approach to get around a non-root
account running the binary prevents me from dbx/truss'ing the process. 
I'm confused as to the SIGCHLD - the man page for sshd [and the
indicates no forking is done for connections if run in -D mode but the
output suggests otherwise - or does this mean the process doesn't fork
in order to daemonize but still forks for each incoming connection?

The SIGCHLD signal received by the parent process for session pid 2566
tells me the child process is terminating for some yet unknown reason. 
Per an earlier posting, I checked my .cshrc to make sure that
non-interactive logins are not performing any terminal io that would
disrupt the SSH2 protocol io. I've used ldd -v to ensure that all
dynamically loaded libraries are present via LD_LIBRARY_PATH

Short of getting root privileges or even just a temporary root login
session to debug/truss the child process, what should I be looking for
as possible causes? The below sshd & ssh debug output doesn't really
tell me much beyond the debug output indicating some read operation
failed. Whose read, the parent or the child & what was the reason for
the read - based on the 2nd paragraph of the description section in the
sshd man page [once the connection request is accepted all key
negotiation, authentication,etc. is handled by the forked process] - I'm
assuming the read is being done by the child process and 
debug2: channel 0: read<=0 rfd 9 len 0
debug2: channel 0: read failed
Or is my whole problem due to not running as root? But the setuid
establishes the effective uid as root so that should take care of that
issue...

The same ssh binary can succesfully connect to a 3.6.1p2 sshd process
I will attach the debug traces for both the sshd process & both ssh client
sessions shortly.

MTIA.
-steve



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1069





------- Additional Comments From shespelt at bear.com  2005-08-12 05:00 -------
Created an attachment (id=947)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=947&action=view)
sshd -d traces and ssh -v traces for problem session & one that works




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1069





------- Additional Comments From djm at mindrot.org  2005-08-12 08:25
-------
> I'm not empowered with root privileges [when deployed, the sshd daemon
> will be run as root] but I've convinced our SA group to at least chown
> root:sys the sshd & ssh binaries and to set the setuid bit on those
> binaries (this is needed as the geteuid checking in login_write() causes
> the daemon to exit if running in -D mode). 
Don't do that. sshd isn't designed to be run setuid root.

You can run sshd without root privileges under your own uid, providing a) you
set UsePAM=no and you stick to pubkey or hostbased authentication. Obviously you
will not be able to authenticate as a different user.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1069


djm at mindrot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




------- Additional Comments From djm at mindrot.org  2005-08-27 01:13 -------
sshd shouldn't be made suid root



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.