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
Created attachment 947 [details] sshd -d traces and ssh -v traces for problem session & one that works
> 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.
sshd shouldn't be made suid root
Change all RESOLVED bug to CLOSED with the exception of the ones fixed post-4.4.