Correct way to use Net:SSH2 module

MikeKulls2 has asked for the wisdom of the Perl Monks concerning the following question:

I've been using the SSH2 module for a while and have found it to work quite well. The part I always find difficult is telling when the returned data has complete. For example, this piece of code I find all over the internet

my $ssh2 = new Net::SSH2();
$ssh2->connect('127.0.0.1') or die $!;
$ssh2->auth_password('bob', 'smith');
if(!$ssh2->auth_ok()) { die $!; }
my $channel = $ssh2->channel();
$channel->shell();
print $channel "ls -l\n";
while(<$channel>)
{
  print $_;
}
[download]

This appears to know when the reponse is complete because it returns immediately. What I want to know is how does it know? Does it look for the prompt or via some other means? What happens if the response contains what it is looking for? Will it exit early?

Comment on Correct way to use Net:SSH2 module Download Code

Replies are listed 'Best First'.
Re: Correct way to use Net:SSH2 module by GrandFather (Saint) on Mar 19, 2013 at 03:19 UTC
I use: sub sshSendCommand { my ($self, $cmd, $pollTime) = @_; my $chan = $self->{ssh}->channel(); my $log = ''; my $timeDelta = sprintf "%4d:", time() - $self->{startTime}; $pollTime \|\|= 500; print "$timeDelta ssh: <$cmd> (poll time: $pollTime)\n"; $chan->exec($cmd); my @poll = {handle => $chan, events => ['in']}; while ($self->{ssh}->poll($pollTime, \@poll)) { if ($poll[0]{revents}{channel_closed}) { print "$timeDelta channel closed\n"; last; } next if !$poll[0]{revents}{in}; my $buff; $log .= $buff while $chan->read($buff, 1024); next; } print "$log\n$timeDelta ssh command complete\n"; return $log; } [download] True laziness is hard work	[reply] [d/l]
Re^2: Correct way to use Net:SSH2 module by MikeKulls2 (Novice) on Mar 21, 2013 at 04:04 UTC
OK, I can see how that works. It knows when the response has finished because the remote end disconnects. Interestingly the documentation states that your code won't work if run a second time, although it does appear to work.	[reply]
Re^3: Correct way to use Net:SSH2 module by salva (Canon) on Mar 21, 2013 at 09:30 UTC
No, the documentation says you can not reuse a channel once it has been closed. But you can open several channels, even in parallel, over the same connection. BTW, you should also check Net::SSH::Any.	[reply]
Re^4: Correct way to use Net:SSH2 module by MikeKulls2 (Novice) on Mar 21, 2013 at 22:30 UTC
Re^5: Correct way to use Net:SSH2 module by salva (Canon) on Mar 22, 2013 at 08:11 UTC
Some notes below your chosen depth have not been shown here
Re: Correct way to use Net:SSH2 module by runrig (Abbot) on Mar 18, 2013 at 22:32 UTC
When I had that issue, I wrote an wrapper for executing commands that always followed the command with echo'ing "COMMAND_IS_DONE" or somesuch. Then keep reading until you see your marker. Update: wow...no "echo"?? It's often a shell builtin. My condolences. But I think you could satisfactorily uniquify a "COMMAND_IS_DONE" string by adding a pid or other random digits/characters...	[reply]
Re^2: Correct way to use Net:SSH2 module by MikeKulls2 (Novice) on Mar 18, 2013 at 23:26 UTC
That is what we are doing but it is something I want to eliminate as it has the obvious fault if the command returns COMMAND_IS_DONE for any reason. We are also connecting to a lot of routers that have their own command set which doesn't include echo.	[reply]
Re^2: Correct way to use Net:SSH2 module by MikeKulls2 (Novice) on Mar 19, 2013 at 01:04 UTC
You need to remember that connecting to a shell is only one option with SSH and we might not even be connecting to linux/unix. We are dealing with big network boxes that implement their own environment that is not shell and absolutely zero shell commands works (even if these boxes do have shell it is likely a massive deal getting access to it). Sometimes the boxes talk XML. Other times we avoid shell and communicate directly with our own perl script on the remote server. This works really well because we can give a remote dept access to talk to our script only and we can really control what they can do then. It beats giving them shell access and hoping that we locked everything down correctly. Come to think of it I pretty much never connect to a shell, certainly I would exhaust every other option first. Using shell is generally going to result in code that breaks with different OSes. With regards the uniqueness I think you are correct, it would be possible to get something unique. However, again it is something I would use as a last resort as it is still a hole in the software that could possibly be a security risk.	[reply]