Something else to note about e...@openssh.com is that OpenSSH only sends this request to peer implementations which are whitelisted (currently only "OpenSSH*"). Historicaly, other impls have been buggy to the point of crashing when they receive e...@openssh.com, so they set up this whitelist to reduce interop issues.
In fact dropbear is one of the bad impls, because when the client sees a channel request it doesn't recognize, it always does send_msg_channel_failure. It should instead look at 'wantreply' and if it's FALSE, it should drop the request silently. The patch dropbear-eow.patch fixes this. But all this to say that vanilla OpenSSH cannot be used to test this feature because it won't send e...@openssh.com. OpenSSH would need to be patched to include dropbear in the whitelist for testing. On Wed, Jul 24, 2013 at 9:21 PM, Catalin Patulea <c...@vv.carleton.ca> wrote: > e...@openssh.com is an extension that allows EPIPE to propagate through > SSH sessions. For example: > ssh localhost cat /dev/urandom | /bin/true > will very quickly exit because /bin/true does not consume its stdin. > > The mechanism is: > - /bin/true calls exit(0), closing the last remaining ref to its stdin pipe > - ssh tries to write() and gets EPIPE > - ssh sends e...@openssh.com channel request to server > - sshd handles e...@openssh.com by closing read side of its pipe > - 'cat /etc/urandom' itself tries to write(), sees EPIPE and is killed > by SIGPIPE > > dropbear doesn't implement this, so > ./dbclient localhost cat /dev/urandom | /bin/true > runs forever. > > e...@openssh.com is specified here: > http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL?rev=HEAD;content-type=text/plain > (section 2.1) > > I have a draft implementation of this in dropbear (attached), but > there is one significant issue: > > In cli-session.c, stdin, stdout and stderr are dup()'ed in order to be > able to restore file flags at the end of the session. This means that > if the client gets e...@openssh.com from the server and close(0), this > is actually not the last outstanding ref to the pipe. There's still an > fd 4 or so, which means the writer actually doesn't see EPIPE. So a > case like this is still broken: > <producer> | ./dbclient <host> <remote command that closes stdin> > > On my ubuntu dev machine I could just comment the dup()/flags hack > out, which made this work. But I'm not sure whether this is really > still needed at all. > > What is the history behind this? The comment says: > /* We store std{in,out,err}'s flags, so we can set them back on exit > * (otherwise busybox's ash isn't happy */ > > but that's not much detail and I'm not sure if it's really still needed.
