|
Home > Archive > Unix administration > March 2004 > ssh 2 tunnel to named pipe not working - please help
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
ssh 2 tunnel to named pipe not working - please help
|
|
|
| OK, this is officially escalated to an annoyance. I have previously
been able to set up a scenario as follows:
ssh user@targethost 'cat > inbound_namedpipe' < outbound_namedpipe &
This works as expected under ssh v1 connectivity (i.e., RSA key
exchange method, ssh v1 authorized_keys file etc.). I am now trying
to do this using using ssh v2 (DSA key exchange, authorization file,
etc.) and it won't work . I can execute a remote command with no
problem ( ls -l | ssh user@targethost 'cat > textfile.txt'); but I'm
pretty sure I'm not getting to the named pipe on the target side.
The reasoning behind my diagnosis: The process on either side of the
tunnel is an Oracle export and import; under the ssh1 tunnel I could
see the activity (if you've ever used these utilities you know what I
mean). Under the ssh2 tunnel I see the export start but there is no
activiy on the import side. The named pipe on the outbound side is >
0 bytes while the named pipe on the inbound side stays at zero bytes.
I did a small export/import test using files and it worked fine. The
OS and Oracle versions are identical on both machines.
Here is my setup
TARGET MACHINE:
1. mknod /tmp/inpipe.dmp p
2. imp xxx/xxx (params) file=/tmp/inpipe.dmp &
SOURCE MACHINE
3. mknod /tmp/outpipe.dmp p
4. ssh user@targethost 'cat > /tmp/inpipe.dmp' < /tmp/outpipe.dmp &
5. exp xxx/xxx (params) file=/tmp/outpipe.dmp
As I mentioned above, this works under ssh v1. Is there a syntax
change for v2? I reread the man page but didn't pick up on one.
Please help - I have a data warehouse to move around and don't want to
spend the weekend moving tapes!
Thanks in advance -
Kind regards,
jh
| |
| Richard E. Silverman 2004-02-25, 12:34 pm |
|
Your terminology is confusing; what do you mean by "ssh v1" and "ssh v2"?
Protocol versions? Different implementations? Some of what you wrote
suggests you were using OpenSSH and now are using ssh.com, but it's not
clear. Say exactly what software and OS you're using, on both sides.
--
Richard Silverman
res@qoxp.net
| |
| Per Hedeland 2004-02-25, 3:34 pm |
| In article <480f610.0402250623.245373b@posting.google.com>
jared@hwai.com (Jared) writes:
>4. ssh user@targethost 'cat > /tmp/inpipe.dmp' < /tmp/outpipe.dmp &
Just a stab in the dark, but to eliminate the possibility of any part of
SSH even being aware that named pipes are involved, you could try:
cat /tmp/outpipe.dmp | ssh user@targethost 'cat > /tmp/inpipe.dmp' &
However, a command like yours above worked perfectly for me with:
Client OS: FreeBSD 5.2 OpenSSH: 3.6.1p1
Server OS: RedHat 7.3 OpenSSH: 3.1p1
SSH protocol version: 2
(ok, so I need to upgrade...) Not doing any Oracle stuff though, but
'cat /tmp/pipe > /tmp/file' on server and then 'cat bigfile > /tmp/pipe'
on client.
--Per Hedeland
per@hedeland.org
| |
|
| It is F-Secure's SSH for Solaris. I say 'v2' vs. 'v1' because the
first pair of machines I did this on generated v1-style RSA key pairs
by default, used v1-format authorized_keys files, etc. The machines I
am currently trying to use this on are generating v2-style DSA key
pairs by default, and I had to set up v2-style authorization and
identification files, etc.
I am certain about F-Secure on the machines I am currently using as
when I run in verbose mode I see the header. I will check the other
pair of machines, but that is rather a moot point.
Kind regards,
jh
Richard E. Silverman <res@qoxp.net> wrote in message news:<m2llmr3y8q.fsf@darwin.oankali.net>...
> Your terminology is confusing; what do you mean by "ssh v1" and "ssh v2"?
> Protocol versions? Different implementations? Some of what you wrote
> suggests you were using OpenSSH and now are using ssh.com, but it's not
> clear. Say exactly what software and OS you're using, on both sides.
| |
|
| Thanks for the suggestion, Per, but the point is to exp to the pipe
and have it automatically forward it to the tunnel, so I can
simultaneously export on machine a and import on machine b. Your
technique requires local disk storage that I do not have on the source
machine.
Kind regards,
jh
per@hedeland.org (Per Hedeland) wrote in message news:<c1ivnr$ljp$1@hedeland.org>...
> In article <480f610.0402250623.245373b@posting.google.com>
> jared@hwai.com (Jared) writes:
>
>
> Just a stab in the dark, but to eliminate the possibility of any part of
> SSH even being aware that named pipes are involved, you could try:
>
> cat /tmp/outpipe.dmp | ssh user@targethost 'cat > /tmp/inpipe.dmp' &
>
> However, a command like yours above worked perfectly for me with:
>
> Client OS: FreeBSD 5.2 OpenSSH: 3.6.1p1
> Server OS: RedHat 7.3 OpenSSH: 3.1p1
> SSH protocol version: 2
>
> (ok, so I need to upgrade...) Not doing any Oracle stuff though, but
> 'cat /tmp/pipe > /tmp/file' on server and then 'cat bigfile > /tmp/pipe'
> on client.
>
> --Per Hedeland
> per@hedeland.org
| |
| Richard E. Silverman 2004-02-26, 4:34 pm |
| >>>>> "Jared" == Jared <jared@hwai.com> writes:
Jared> It is F-Secure's SSH for Solaris. I say 'v2' vs. 'v1' because
Jared> the first pair of machines I did this on generated v1-style RSA
Jared> key pairs by default, used v1-format authorized_keys files,
Jared> etc. The machines I am currently trying to use this on are
Jared> generating v2-style DSA key pairs by default, and I had to set
Jared> up v2-style authorization and identification files, etc.
These things don't correspond to "version 1" or "version 2" of anything.
The first pair of machines were using OpenSSH on the server (which is what
comes with Solaris); the second, F-Secure (which is a derivative of the
ssh.com product). They are not versions of one another; the
authorized_keys file could contain keys for either v1 or v2 of the SSH
protocol; etc.
It's not surprising that they might have different behavior around IO to
pipes, since they're entirely different implementations and Unix pipes and
sockets can be tricky things, with various deadlock scenarios and subtly
different semantics among OS variants. When debugging similar problems, I
have made heavy use of process tracing, lsof, the source code, and the
pipes/sockets documentation to find out exactly what is blocking where,
and why.
--
Richard Silverman
res@qoxp.net
| |
| Per Hedeland 2004-02-26, 7:34 pm |
| In article <480f610.0402261010.7360b35c@posting.google.com>
jared@hwai.com (Jared) writes:
>Thanks for the suggestion, Per, but the point is to exp to the pipe
>and have it automatically forward it to the tunnel, so I can
>simultaneously export on machine a and import on machine b. Your
>technique requires local disk storage that I do not have on the source
>machine.
Since you're top-posting it isn't clear exactly what you're refering to
in my posting, but this suggestion:
[color=darkred]
- most certainly does *not* require any more local storage than your
original attempt. And I'll readily agree with Richard that named pipes
can be "tricky things".:-)
The test I reported having done was just to show that named pipes worked
the way you were using them - on the particular OSes I used, with the
particular OpenSSH versions - not a suggestion for you. However
Richard's analysis to figure out what code you were actually using
earlier/currently, combined with this test of mine, could possibly
indicate that the problem is with F-Secure SSH, and could be solved by
using OpenSSH instead. However you could try the above first...
--Per Hedeland
per@hedeland.org
| |
| Jared 2004-03-02, 11:34 am |
| per@hedeland.org (Per Hedeland) wrote in message news:<c1m05b$1aju$1@hedeland.org>...
> The test I reported having done was just to show that named pipes worked
> the way you were using them - on the particular OSes I used, with the
> particular OpenSSH versions - not a suggestion for you. However
> Richard's analysis to figure out what code you were actually using
> earlier/currently, combined with this test of mine, could possibly
> indicate that the problem is with F-Secure SSH, and could be solved by
> using OpenSSH instead. However you could try the above first...
I had a minor discovery today - the machine pairs I have this working
on are running OpenSSH while of the pair I have a problem with, the
'target' machine is running F-Secure's SSH. I'm going to speak to
their tech support.
And I promise not to top-post anymore :-)
Kind regards,
jh
| |
| Per Hedeland 2004-03-03, 5:35 pm |
| In article <480f610.0403020816.53a0716c@posting.google.com>
jared@hwai.com (Jared) writes:
>per@hedeland.org (Per Hedeland) wrote in message
>news:<c1m05b$1aju$1@hedeland.org>...
>
>
>I had a minor discovery today - the machine pairs I have this working
>on are running OpenSSH while of the pair I have a problem with, the
>'target' machine is running F-Secure's SSH.
Hm, that's what Richard told you last week... (the analysis I referred
to above).
--Per Hedeland
per@hedeland.org
| |
| Jared 2004-03-09, 10:35 am |
| per@hedeland.org (Per Hedeland) wrote in message news:<c25k31$25ca$1@hedeland.org>...
> In article <480f610.0403020816.53a0716c@posting.google.com>
> jared@hwai.com (Jared) writes:
>
> Hm, that's what Richard told you last week... (the analysis I referred
> to above).
Yes, he did. I am stubborn and probably do too much checking on my
own. I think I may have an idea of the problem from rereading the
docs - I am going to ensure directory permissions for .ssh's parent is
set to 700 and try again.
|
|
|
|
|