strange behaviour with ssh / stdin
Laurent Bartholdi
i noted the following strange behaviour using ssh and linux. this is
probably a low-priority bug:
# ssh -V
OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090701f
# uname -a
Linux funnyfarm 2.4.21-20.1.2024.2.1.nptl #1 Fri Jul 11 06:04:52 EDT 2003 i686 i686 i386 GNU/Linux
# echo Hello | ssh frodo 'cat'
Hello
# echo Hello | ssh frodo 'cat /proc/self/fd/0'
cat: /proc/self/fd/0: No such device or address
# ssh frodo 'ls -l /proc/self/fd/0'
lrwx------ 1 root root 64 Oct 13 18:51 /proc/self/fd/0 -> socket:[27105]
this is a bit surprising: some applications require a file as input, and
usually specifying /proc/self/fd/0 allows the standard input to be treated
as a file; e.g. some arguments it tar(1) that require a file list. the
command above, with 'cat /proc/self/fd/0' as argument, could then be
entered as
# echo Hello | ssh frodo 'cat | cat /proc/self/fd/0'
Hello
best, laurent
--
Laurent Bartholdi \ lau...@math.berkeley.E-D-U
1073 Evans Hall, Dept of Mathematics\ Phone: +1 (510) 6423529
U.C. Berkeley, CA 94720-3840, U.S.A. \ Fax: +1 (510) 6428204
_______________________________________________
openssh-unix-dev mailing list
openssh-...@mindrot.org
http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
Damien Miller
> hi,
> i noted the following strange behaviour using ssh and linux. this is
> probably a low-priority bug:
>
> # ssh -V
> OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090701f
> # uname -a
> Linux funnyfarm 2.4.21-20.1.2024.2.1.nptl #1 Fri Jul 11 06:04:52 EDT 2003 i686 i686 i386 GNU/Linux
>
> # echo Hello | ssh frodo 'cat'
> Hello
> # echo Hello | ssh frodo 'cat /proc/self/fd/0'
> cat: /proc/self/fd/0: No such device or address
> # ssh frodo 'ls -l /proc/self/fd/0'
> lrwx------ 1 root root 64 Oct 13 18:51 /proc/self/fd/0 -> socket:[27105]
This is probably some weird Linux race condition. I can't imagine
anything that ssh could do that would cause this.
Does /dev/stdin or /dev/fd/0 work? These are often aliases for the same
purpose.
-d
Darren Tucker
>
> On Mon, 2003-10-13 at 19:56, Laurent Bartholdi wrote:
> > hi,
> > i noted the following strange behaviour using ssh and linux. this is
> > probably a low-priority bug:
> >
> > # ssh -V
> > OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090701f
> > # uname -a
> > Linux funnyfarm 2.4.21-20.1.2024.2.1.nptl #1 Fri Jul 11 06:04:52 EDT 2003 i686 i686 i386 GNU/Linux
> >
> > # echo Hello | ssh frodo 'cat'
> > Hello
> > # echo Hello | ssh frodo 'cat /proc/self/fd/0'
> > cat: /proc/self/fd/0: No such device or address
> > # ssh frodo 'ls -l /proc/self/fd/0'
> > lrwx------ 1 root root 64 Oct 13 18:51 /proc/self/fd/0 -> socket:[27105]
>
> This is probably some weird Linux race condition. I can't imagine
> anything that ssh could do that would cause this.
>
> Does /dev/stdin or /dev/fd/0 work? These are often aliases for the same
> purpose.
On my RH8 box they're all symlinks to the controlling tty if it has one or
to some kind of socket descriptor if not (as you noted). The problem
appears to be Linux-specific.
$ uname -sr; ls -l /dev/stdin /dev/fd/0 /proc/self/fd/0
Linux 2.4.20-20.8
lrwx------ 1 dtucker dtucker 64 Oct 14 22:06 /dev/fd/0 ->
/dev/pts/2
lrwxrwxrwx 1 root root 17 Mar 31 2003 /dev/stdin ->
../proc/self/fd/0
lrwx------ 1 dtucker dtucker 64 Oct 14 22:06 /proc/self/fd/0 ->
/dev/pts/2
In contrast, on Solaris, /dev/fd/0 is a character special device, and your
example works as expected:
$ uname -sr; ls -l /dev/fd/0 /dev/stdin
SunOS 5.8
crw-rw-rw- 1 root root 247, 0 Oct 14 22:09 /dev/fd/0
lrwxrwxrwx 1 root root 6 Apr 2 2002 /dev/stdin -> ./fd/0
$ echo Hello | ssh localhost "cat /dev/fd/0"
Hello
I remember reading an explanation about this someplace but I don't
remember the details and I've been unable to locate it again.
--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
Roumen Petrov
As Laurent show ".../fd/0 -> socket:[27105]", i.e. on linux we have
broken symbolic link - cat ".../fd/0" cannot found
".../fd/socket:[27105]" file.
It is strange that cat without arguments work on linux.
Darren Tucker wrote:
_______________________________________________
Darren Tucker
>
> Might is linux kernel(?), not ssh(!) problem.
Quite possibly. Laurent has opened a kernel Bugzilla bug:
http://bugzilla.kernel.org/show_bug.cgi?id=1357
> As Laurent show ".../fd/0 -> socket:[27105]", i.e. on linux we have
> broken symbolic link - cat ".../fd/0" cannot found
> ".../fd/socket:[27105]" file.
> It is strange that cat without arguments work on linux.
Some food for thought: according to lsof (what did I do without lsof!)
there's a difference the the descriptors:
$ ssh localhost "lsof" | grep lsof |egrep '[012][rwu]'
lsof 4101 dtucker 0u unix 0xc2d2c9e0 2530902 socket
lsof 4101 dtucker 1u unix 0xc2d2c9e0 2530902 socket
lsof 4101 dtucker 2u unix 0xcc975090 2530904 socket
stdin/out are both read-write sockets
$ ssh localhost "cat | lsof | cat" | grep lsof |egrep '[012][rwu]'
lsof 4216 dtucker 0r FIFO 0,5 2533038 pipe
lsof 4216 dtucker 1w FIFO 0,5 2533039 pipe
lsof 4216 dtucker 2u unix 0xcad775a0 2533006 socket
stdin/out are unidirectional pipes.
What does this mean? No idea.
--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
_______________________________________________
Darren Tucker
>
> Roumen Petrov wrote:
> >
> > Might is linux kernel(?), not ssh(!) problem.
>
> Quite possibly. Laurent has opened a kernel Bugzilla bug:
> http://bugzilla.kernel.org/show_bug.cgi?id=1357
Hmm, they closed it because it was a vendor kernel. I've reproduced it
with 2.6.0-test7, made a tiny test case and and opened a new bug (can't
reopen old ones):
http://bugzilla.kernel.org/show_bug.cgi?id=1360
Looking at the code in session.c, since it seems to work with the
descriptors are pipe, try adding "#define USE_PIPES 1" to config.h,
recompile and retest.
Roumen Petrov
===========================================================
echo hello | ssh localhost 'ls -l /dev/fd/; cat /dev/fd/0; zsh -c "ls -l
/dev/fd/"'
total 0
lr-x------ 1 rumen2 rumen 64 Oct 15 18:07 0 -> pipe:[12554]
l-wx------ 1 rumen2 rumen 64 Oct 15 18:07 1 -> pipe:[12555]
l-wx------ 1 rumen2 rumen 64 Oct 15 18:07 2 -> pipe:[12556]
lr-x------ 1 rumen2 rumen 64 Oct 15 18:07 3 -> /proc/1616/fd
cat: /dev/fd/0: Permission denied
total 0
lr-x------ 1 rumen2 rumen 64 Oct 15 18:07 0 -> pipe:[12554]
l-wx------ 1 rumen2 rumen 64 Oct 15 18:07 1 -> pipe:[12555]
l-wx------ 1 rumen2 rumen 64 Oct 15 18:07 2 -> pipe:[12556]
lr-x------ 1 rumen2 rumen 64 Oct 15 18:07 3 -> /proc/1618/fd
===========================================================
Because "cat" (without file) work, "cat | cat /dev/fd/0" work too. For
second cat "/dev/fd/0" should be pipe to stdout of first cat.
Darren Tucker wrote:
>Darren Tucker wrote:
>
>
>>Roumen Petrov wrote:
>>
>>
>>>Might is linux kernel(?), not ssh(!) problem.
>>>
>>Quite possibly. Laurent has opened a kernel Bugzilla bug:
>>http://bugzilla.kernel.org/show_bug.cgi?id=1357
>>
>>
>Hmm, they closed it because it was a vendor kernel. I've reproduced it
>with 2.6.0-test7, made a tiny test case and and opened a new bug (can't
>reopen old ones):
>http://bugzilla.kernel.org/show_bug.cgi?id=1360
>
>Looking at the code in session.c, since it seems to work with the
>descriptors are pipe, try adding "#define USE_PIPES 1" to config.h,
>recompile and retest.
>
_______________________________________________