ssh tullen

[Dr Eberhard Lisse]

Hi,

I have a PostgreSQL database behind a firewall which I can access from a
fixed IP address but obviously not while on the road where I must issue
something like:

ssh -N -C (e-mail address removed) -L 5433/localhost/5432

and then run my script to generate the report.

I can in a slightly different context using Net::SSH issue commands
to the remote host, but I have been unable to figure out how to open a
tunnel from within the perl script (preferably with a module, but that's
not really the issue), then do my usual thing, and then close the tunnel
again.

Is this a unique problem? Or can someone point me to a code fragment
that does something like this...

el

 

[Peter J. Holzer]

I have a PostgreSQL database behind a firewall which I can access from a
fixed IP address but obviously not while on the road where I must issue
something like:

ssh -N -C (e-mail address removed) -L 5433/localhost/5432

and then run my script to generate the report.

I can in a slightly different context using Net::SSH issue commands
to the remote host, but I have been unable to figure out how to open a
tunnel from within the perl script (preferably with a module, but that's
not really the issue), then do my usual thing, and then close the tunnel
again.

maybe I misunderstand the problem, but have you tried simply starting
ssh in the background (with open or fork/exec) at the start of your
script and killing it at the end?

hp

 

[Dr Eberhard W Lisse]

Haven't been able to successfully do that.

Have you got a working code fragment?


el

 

[Peter Makholm]

Haven't been able to successfully do that.

What did you try? How did it fail?

Have you got a working code fragment?

I have written a lot of code which rather naïvely uses IPC::Open3 to run
ssh as a background process. It should work for opening a tunnel.

The problems I don't usual handle is that the initial connection often
asks whether to accept the host key. In this scenario the process just
hangs. If you just accept the hostkey by hand it works correctly.

//Makholm

 

[Dr Eberhard W Lisse]

Peter,

reason for failure:

Stupidity and Ignorance of this elderly Gynaecologist -O

I have the key pairs organized -O

el

 

[Peter J. Holzer]

Try system("ssh -f -L... ... sleep 10") instead of open3. It's important
with -f to use 'sleep 10' rather than -N, otherwise the ssh process will
never exit. (It doesn't seem to be very easy to find its pid to kill it
manually.)

open($fh, '-|', ...) returns the pid, so does fork. The following script
works for me, at least on linux:


#!/usr/bin/perl
use warnings;
use strict;
use IO::Socket::INET;

$| = 1;
print "opening tunnel ... ";
my $pid = open(my $fh, '-|',
'ssh', '-N', '(e-mail address removed)', '-L', '10007:chronos.DOMAIN:7'
) or die;
print " done (pid=$pid)\n";

sleep 5;
system('lsof', '-i', ':10007');
sleep 5;

print "opening socket ... ";
my $sock = IO::Socket::INET->new(PeerHost => 'localhost',
PeerPort => 10007,
Proto => 'tcp');
print " done\n";

print "sending request ... ";
print $sock "test123\n";
print " done\n";

print "reading response ... ";
my $resp = <$sock>;
print " done (resp = $resp)\n";

print "closing socket ... ";
close($sock);
print " done\n";

sleep(5);
system('lsof', '-i', ':10007');
sleep(5);

print "closing tunnel ... ";
kill(15, $pid);
my $rc = waitpid($pid, 0);
print " done (rc = $rc)\n";

sleep(5);
system('lsof', '-i', ':10007');
__END__

hp

 

[Peter J. Holzer]

I think you're not realising what the -f argument to ssh does. It makes
ssh put itself in the background, but only after any possible need to
prompt the user has been dealt with.

Yes, but there is no reason to use it. Perl can put processes in the
"background" just fine. You will notice that my little test program
doesn't use it.

hp

 

[Peter J. Holzer]

Perl can put processes in the background just fine, yes. That's not the
issue. The issue is that sometimes ssh needs to prompt, and running it in
the background from Perl doesn't handle that very well.

Prompting doesn't work if the script is run from cron, or from a web
server, or most other situations where I've ever needed to call ssh from
a perl script. Your assumption that it is possible to prompt isn't any
more reasonable than my assumption that the environment has been set up
correctly (remote host key in known_hosts, local public key in remote
authorized_keys, ...).

I took the program you posted and made the following change:

"Doctor, it hurts when I do this!"

"Well, then don't do it!"


hp

 

[C.DeRykus]

What did you try? How did it fail?


I have written a lot of code which rather naïvely uses IPC::Open3 to run
ssh as a background process. It should work for opening a tunnel.

The problems I don't usual handle is that the initial connection often
asks whether to accept the host key. In this scenario the process just
hangs. If you just accept the hostkey by hand it works correctly.

//Makholm

Off-topic a bit, but I seem to recall a workaround with /dev/null...
ah, here's
the incantation:

$ ssh -o UserKnownHostsFile=/dev/null \
-o StrictHostKeyChecking=no \
...

 

[l v]

Hi,

I have a PostgreSQL database behind a firewall which I can access from a
fixed IP address but obviously not while on the road where I must issue
something like:

ssh -N -C (e-mail address removed) -L 5433/localhost/5432

and then run my script to generate the report.

I can in a slightly different context using Net::SSH issue commands
to the remote host, but I have been unable to figure out how to open a
tunnel from within the perl script (preferably with a module, but that's
not really the issue), then do my usual thing, and then close the tunnel
again.

Is this a unique problem? Or can someone point me to a code fragment
that does something like this...

el

How about trying Net::OpenSSH? I have not used this module.

http://search.cpan.org/~salva/Net-OpenSSH-0.57/lib/Net/OpenSSH.pm#Tunnels

<quote>

tunnel => $bool

Instead of executing a command in the remote host, this option instruct
Net::OpenSSH to create a TCP tunnel. The arguments become the target IP
and port.

Example:

my ($in, $out, undef, $pid) = $ssh->open_ex({tunnel => 1}, $IP, $port);

</quote>

 

[Dr Eberhard W Lisse]

Have you got a code fragment for this elderly Gyneaecologist?

Didn't manage to get OpenSSH to work either.

thanks, el

On 2012-01-26 04:34 , l v wrote:
[...]

 

[Dr Eberhard W Lisse]

Thanks, that helps.

el

open($fh, '-|', ...) returns the pid, so does fork. The following script
works for me, at least on linux:


#!/usr/bin/perl
use warnings;
use strict;
use IO::Socket::INET;

$| = 1;
print "opening tunnel ... ";
my $pid = open(my $fh, '-|',
'ssh', '-N', '(e-mail address removed)', '-L', '10007:chronos.DOMAIN:7'
) or die;
print " done (pid=$pid)\n";

sleep 5;
system('lsof', '-i', ':10007');
sleep 5;

print "opening socket ... ";
my $sock = IO::Socket::INET->new(PeerHost => 'localhost',
PeerPort => 10007,
Proto => 'tcp');
print " done\n";

print "sending request ... ";
print $sock "test123\n";
print " done\n";

print "reading response ... ";
my $resp = <$sock>;
print " done (resp = $resp)\n";

print "closing socket ... ";
close($sock);
print " done\n";

sleep(5);
system('lsof', '-i', ':10007');
sleep(5);

print "closing tunnel ... ";
kill(15, $pid);
my $rc = waitpid($pid, 0);
print " done (rc = $rc)\n";

sleep(5);
system('lsof', '-i', ':10007');
__END__

hp

 

[Dr Eberhard Lisse]

And you can go and see Isak N. Jacobsen.

el

Perhaps you do not realize it, but you appear to be rude.

You should learn Usenet manners if you intend to post to Usenet.

Do not top-post.

Do not full-quote.


http://web.presby.edu/~nnqadmin/nnq/nquote.html

 

[Dr Eberhard W Lisse]

Sorry, you didn't realize that you are unconcerned about appearing arrogant.

el

 

[Kaz Kylheku]

Sorry, I did not realize that you are unconcerned about appearing clueless.

Yet, you fixed your top-posting in response to Dr. Lisse, so it was
not entirely in vain.

 

[Kaz Kylheku]

And you can go and see Isak N. Jacobsen.

Doc, it really is better if you trim the quoted material, break it up into
pieces that you want to respond to and reply below those pieces. Try it!

(This is why the > characters are there; to clearly distinguish
between your embedded pieces and the original text.)

It's not "rude" otherwise; it's just a different cultural convention. In the
corporate world of Mirosoft Exchange/Outlook e-mail communication, full quoting
and top-posting is the norm. (And note that > quoting is not used!)

In the classic world of Internet e-mail, mailing lists, Usenet newsgroups
and BBS's, we have > with in-between quoting. It is better suited for complex
discussions with multiple points.

The posting sotware you are using is already doing half the job of sticking to
the convention by inserting the > characters.

Cheers ...

 

[Dr Eberhard W Lisse]

I think you must get out more.

el

^^^
^^^

You are apologizing for me?

That seems a bit presumptuous...




Here I apologized for me.



You apologize for you.

You are not priveleged to apologize for me.

 

[Dr Eberhard W Lisse]

Thank you very much for explaining this to me.


But you see, old habits die hard, been top-posting and full-quoting
now for 30 years or so, initially nn but TBird does this also very
well.

We are now hoever getting well off topic, and though I enjoy a
good flame as the next one I wasn't really trolling.

greetings, el

 

[Dr Eberhard Lisse]

Shmuel,

I agree, but often the same as below happens, the editor used (I use
emacs and AlphaX) don't recognize the kk> for formatting purposes,
wiithout some intervention -O

el

 

[Tim McDaniel]

We are now hoever getting well off topic,

Meta-discussion is related to the topic.

and though I enjoy a
good flame as the next one I wasn't really trolling.

When multiple people tell you about group customs and explain why
they're practical, and you loudly refuse to follow and denigrate the
reasons: yes, you are indeed trolling. Luckily, my news reader has a
"killfile" that can filter by sender.