Bug 1549

Summary:	change in remote command execution behavior
Product:	Portable OpenSSH	Reporter:	kaizaad
Component:	sshd	Assignee:	Assigned to nobody <unassigned-bugs>
Status:	CLOSED WORKSFORME
Severity:	normal	CC:	djm
Priority:	P2
Version:	5.1p1
Hardware:	amd64
OS:	Linux

Description kaizaad 2009-01-08 07:29:57 AEDT

I have sent the following info the the list:

http://marc.info/?l=openssh-unix-dev&m=122901533604841&w=2

but have not heard anything. Can this be classified as a bug, even though it is working as documented _but_ is a drastic change in behavior from the previous versions (don't know how far this goes back)?

I have reproduced the output here:

OS and kernel:
Red Hat Enterprise Linux AS release 4 (Nahant Update 5)
Linux host135 2.6.9-67.9hp.7sp.XCsmp #1 SMP Thu Jul 3 18:55:59 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux


built both openssh-5.0p1 and openssh-5.1p1 with the following options:
./configure --prefix=/usr --libexecdir=/usr/libexec/openssh --localstatedir=/var/empty/sshd \
--sysconfdir=/etc/ssh --with-pam --with-md5-passwords --with-zlib=/home/XXX/software/zlib-1.2.3 \
--with-tcp-wrappers


With everything else being identical and just swapping the sshd binaries, 
I noticed the following:

# ssh -v host135
debug1: match: OpenSSH_5.0 pat OpenSSH*
...snip
# ssh host135 'echo $PATH'
/opt/octave/current:/opt/mpiblast/current/bin:/opt/lammps/current/bin:/opt/dlpoly/current/execute:
...snip

# ssh -v host135
debug1: match: OpenSSH_5.1 pat OpenSSH*
...snip
# ssh host135 'echo $PATH'
/usr/bin:/bin:/usr/sbin:/sbin


According to the docs, the behavior exhibited by v5.1 is correct, remote 
command execution should not process the user's login shell and env. But 
why was this happening in v5.0? I can't find anything in the 5.1 change 
log that explains this change in behavior.

Comment 1 Damien Miller 2009-01-21 22:15:15 AEDT

This is due to a change in sshd interacting with a hack in bash. 

sshd used to spawn session shells and communicate with them over a socketpair() on some platforms but in 5.1 we changed this to pipe()s everwhere to support proper half-closed semantics (see bug #85 for the gory details). Apparently bash behaved differently when started when stdin is a pipe to when it is a socket, and would only source .bashrc when it is a socket. I'm not sure the reason for this behaviour - sshd has used pipes to communicate with the shell on some platforms for many years, so at best this only worked by accident.

https://bugzilla.redhat.com/show_bug.cgi?id=458839 has some more details on this. I think the fix needs to be in bash.

Comment 2 kaizaad 2009-01-24 01:25:45 AEDT

Hello Damien,

Appreciate the explanation.

thanks
-k

Comment 3 Damien Miller 2009-02-23 13:36:49 AEDT

Close bugs fixed/reviewed for openssh-5.2 release