implementing eow at

Catalin Patulea cat at
Fri Aug 2 11:33:47 WST 2013

Something else to note about eow at 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 eow at, 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 eow at 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 <cat at> wrote:
> eow at 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 eow at channel request to server
> - sshd handles eow at by closing read side of its pipe
> - 'cat /etc/urandom' itself tries to write(), sees EPIPE and is killed
> dropbear doesn't implement this, so
> ./dbclient localhost cat /dev/urandom | /bin/true
> runs forever.
> eow at is specified here:
> (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 eow at 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.

More information about the Dropbear mailing list