NAME

Net::OpenSSH - Perl SSH client package implemented on top of OpenSSH

SYNOPSIS

use Net::OpenSSH;

my $ssh = Net::OpenSSH->new($host);
$ssh->error and
  die "Couldn't establish SSH connection: ". $ssh->error;

$ssh->system("ls /tmp") or
  die "remote command failed: " . $ssh->error;

my @ls = $ssh->capture("ls");
$ssh->error and
  die "remote ls command failed: " . $ssh->error;

my ($out, $err) = $ssh->capture2("find /root");
$ssh->error and
  die "remote find command failed: " . $ssh->error;

my ($rin, $pid) = $ssh->pipe_in("cat >/tmp/foo") or
  die "pipe_in method failed: " . $ssh->error;

print $rin "hello\n";
close $rin;

my ($rout, $pid) = $ssh->pipe_out("cat /tmp/foo") or
  die "pipe_out method failed: " . $ssh->error;

while (<$rout>) { print }
close $rout;

my ($in, $out ,$pid) = $ssh->open2("foo");
my ($pty, $pid) = $ssh->open2pty("foo");
my ($in, $out, $err, $pid) = $ssh->open3("foo");
my ($pty, $err, $pid) = $ssh->open3pty("login");

my $sftp = $ssh->sftp();
$sftp->error and die "SFTP failed: " . $sftp->error;

DESCRIPTION

Net::OpenSSH is a secure shell client package implemented on top of OpenSSH binary client (ssh).

Under the hood

This package is implemented around the multiplexing feature found in later versions of OpenSSH. That feature allows one to run several sessions over a single SSH connection (OpenSSH 4.1 was the first one to provide all the required functionality).

When a new Net::OpenSSH object is created, the OpenSSH ssh client is run in master mode, establishing a persistent (for the lifetime of the object) connection to the server.

Then, every time a new operation is requested a new ssh process is started in slave mode, effectively reusing the master SSH connection to send the request to the remote side.

Net::OpenSSH Vs. Net::SSH::.* modules

Why should you use Net::OpenSSH instead of any of the other Perl SSH clients available?

Well, this is my (biased) opinion:

Net::SSH::Perl is not well maintained nowadays (update: a new maintainer has stepped in so this situation could change!!!), requires a bunch of modules (some of them very difficult to install) to be acceptably efficient and has an API that is limited in some ways.

Net::SSH2 is much better than Net::SSH::Perl, but not completely stable yet. It can be very difficult to install on some specific operating systems and its API is also limited, in the same way as Net::SSH::Perl.

Using Net::SSH::Expect, in general, is a bad idea. Handling interaction with a shell via Expect in a generic way just can not be reliably done.

Net::SSH is just a wrapper around any SSH binary commands available on the machine. It can be very slow as they establish a new SSH connection for every operation performed.

In comparison, Net::OpenSSH is a pure perl module that does not have any mandatory dependencies (obviously, besides requiring OpenSSH binaries).

Net::OpenSSH has a very perlish interface. Most operations are performed in a fashion very similar to that of the Perl builtins and common modules (e.g. IPC::Open2).

It is also very fast. The overhead introduced by launching a new ssh process for every operation is not appreciable (at least on my Linux box). The bottleneck is the latency intrinsic to the protocol, so Net::OpenSSH is probably as fast as an SSH client can be.

Being based on OpenSSH is also an advantage: a proved, stable, secure (to paranoid levels), inseparably and well maintained implementation of the SSH protocol is used.

On the other hand, Net::OpenSSH does not work on Windows, not even under Cygwin.

Net::OpenSSH specifically requires the OpenSSH SSH client (AFAIK, the multiplexing feature is not available from any other SSH client). However, note that it will interact with any server software, not just servers running OpenSSH sshd.

For password authentication, IO::Pty has to be installed. Other modules and binaries are also required to implement specific functionality (for instance Net::SFTP::Foreign, Expect or rsync(1)).

Net::OpenSSH and Net::SSH2 do not support version 1 of the SSH protocol.

API

Optional arguments

Almost all methods in this package accept as first argument an optional reference to a hash containing parameters (\%opts). For instance, these two method calls are equivalent:

my $out1 = $ssh->capture(@cmd);
my $out2 = $ssh->capture({}, @cmd);

Error handling

Most methods return undef (or an empty list) to indicate failure.

The "error" method can always be used to explicitly check for errors. For instance:

my ($output, $errput) = $ssh->capture2({timeout => 1}, "find /");
$ssh->error and die "ssh failed: " . $ssh->error;

Net::OpenSSH methods

These are the methods provided by the package:

Net::OpenSSH->new($host, %opts)

Creates a new SSH master connection

$host can be a hostname or an IP address. It may also contain the name of the user, her password and the TCP port number where the server is listening:

my $ssh1 = Net::OpenSSH->new('jack@foo.bar.com');
my $ssh2 = Net::OpenSSH->new('jack:secret@foo.bar.com:10022');
my $ssh3 = Net::OpenSSH->new('jsmith@2001:db8::1428:57ab'); # IPv6

IPv6 addresses may optionally be enclosed in brackets:

my $ssh4 = Net::OpenSSH->new('jsmith@[::1]:1022');

This method always succeeds in returning a new object. Error checking has to be performed explicitly afterwards:

my $ssh = Net::OpenSSH->new($host, %opts);
$ssh->error and die "Can't ssh to $host: " . $ssh->error;

If you have problems getting Net::OpenSSH to connect to the remote host read the troubleshooting chapter near the end of this document.

Accepted options:

user => $user_name

port => $port

TCP port number where the server is running

password => $password

User given password for authentication.

Note that using password authentication in automated scripts is a very bad idea. When possible, you should use public key authentication instead.

passphrase => $passphrase

Uses given passphrase to open private key.

key_path => $private_key_path

Uses the key stored on the given file path for authentication.

gateway => $gateway

If the given argument is a gateway object as returned by "find_gateway" in Net::OpenSSH::Gateway method, use it to connect to the remote host.

If it is a hash reference, call the find_gateway method first.

For instance, the following code fragments are equivalent:

my $gateway = Net::OpenSSH::Gateway->find_gateway(
        proxy => 'http://proxy.corporate.com');
$ssh = Net::OpenSSH->new($host, gateway => $gateway);

and

$ssh = Net::OpenSSH->new($host,
        gateway => { proxy => 'http://proxy.corporate.com'});

proxy_command => $proxy_command

Use the given command to establish the connection to the remote host (see ProxyCommand on ssh_config(5)).

batch_mode => 1

Disables querying the user for password and passphrases.

ctl_dir => $path

Directory where the SSH master control socket will be created.

This directory and its parents must be writable only by the current effective user or root, otherwise the connection will be aborted to avoid insecure operation.

By default ~/.libnet-openssh-perl is used.

ctl_path => $path

Path to the SSH master control socket.

Usually this option should be avoided as the module is able to pick an unused socket path by itself. An exception to that rule is when the external_master feature is enabled.

Note that the length of the path is usually limited to between 92 and 108 bytes, depending of the underlying operating system.

ssh_cmd => $cmd

Name or full path to OpenSSH ssh binary. For instance:

my $ssh = Net::OpenSSH->new($host, ssh_cmd => '/opt/OpenSSH/bin/ssh');

scp_cmd => $cmd

Name or full path to OpenSSH scp binary.

By default it is inferred from the ssh one.

rsync_cmd => $cmd

Name or full path to rsync binary. Defaults to rsync.

remote_shell => $name

Name of the remote shell. Used to select the argument quoter backend.

timeout => $timeout

Maximum acceptable time that can elapse without network traffic or any other event happening on methods that are not immediate (for instance, when establishing the master SSH connection or inside methods capture, system, scp_get, etc.).

Shell quoting

By default, when invoking remote commands, this module tries to mimic perl system builtin in regard to argument processing. Quoting "system" in perlfunc:

Argument processing varies depending on the number of arguments.  If
there is more than one argument in LIST, or if LIST is an array with
more than one value, starts the program given by the first element
of the list with arguments given by the rest of the list.  If there
is only one scalar argument, the argument is checked for shell
metacharacters, and if there are any, the entire argument is passed
to the system's command shell for parsing (this is "/bin/sh -c" on
Unix platforms, but varies on other platforms).

Take for example Net::OpenSSH "system" method:

$ssh->system("ls -l *");
$ssh->system('ls', '-l', '/');

The first call passes the argument unchanged to ssh and it is executed in the remote side through the shell which interprets metacharacters.

The second call escapes any shell metacharacters so that, effectively, it is equivalent to calling the command directly and not through the shell.

Under the hood, as the Secure Shell protocol does not provide for this mode of operation and always spawns a new shell where it runs the given command, Net::OpenSSH quotes any shell metacharacters in the command list.

All the methods that invoke a remote command (system, open_ex, etc.) accept the option quote_args that allows one to force/disable shell quoting.

For instance:

$ssh->system({quote_args => 1}, "/path with spaces/bin/foo");

will correctly handle the spaces in the program path.

The shell quoting mechanism implements some extensions (for instance, performing redirections to /dev/null on the remote side) that can be disabled with the option quote_args_extended:

$ssh->system({ stderr_discard => 1,
               quote_args => 1, quote_args_extended => 0 },
             @cmd);

The option quote_args can also be used to disable quoting when more than one argument is passed. For instance, to get some pattern expanded by the remote shell:

$ssh->system({quote_args => 0}, 'ls', '-l', "/tmp/files_*.dat");

The method shell_quote can be used to selectively quote some arguments and leave others untouched:

$ssh->system({quote_args => 0},
             $ssh->shell_quote('ls', '-l'),
             "/tmp/files_*.dat");

When the glob option is set in scp and rsync file transfer methods, an alternative quoting method which knows about file wildcards and passes them unquoted is used. The set of wildcards recognized currently is the one supported by bash(1).

Another way to selectively use quote globing or fully disable quoting for some specific arguments is to pass them as scalar references or double scalar references respectively. In practice, that means prepending them with one or two backslashes. For instance:

# quote the last argument for globing:
$ssh->system('ls', '-l', \'/tmp/my files/filed_*dat');

# append a redirection to the remote command
$ssh->system('ls', '-lR', \\'>/tmp/ls-lR.txt');

# expand remote shell variables and glob in the same command:
$ssh->system('tar', 'czf', \\'$HOME/out.tgz', \'/var/log/server.*.log');

As shell quoting is a tricky matter, I expect bugs to appear in this area. You can see how ssh is called, and the quoting used setting the following debug flag:

$Net::OpenSSH::debug |= 16;

By default, the module assumes the remote shell is some variant of a POSIX or Bourne shell (bash, dash, ksh, etc.). If this is not the case, the construction option remote_shell can be used to select an alternative quoting mechanism.

For instance:

$ssh = Net::OpenSSH->new($host, remote_shell => 'csh');
$ssh->system(echo => "hard\n to\n  quote\n   argument!");

Currently there are quoters available for POSIX (Bourne) compatible shells, csh and the two Windows variants MSWin (for servers using Win32::CreateProcess, see Net::OpenSSH::ShellQuoter::MSWin) and MSCmd (for servers using cmd.exe, see Net::OpenSSH::ShellQuoter::MSCmd).

In any case, you can always do the quoting yourself and pass the quoted remote command as a single string:

# for VMS
$ssh->system('DIR/SIZE NFOO::USERS:[JSMITH.DOCS]*.TXT;0');

Note that the current quoting mechanism does not handle possible aliases defined by the remote shell. In that case, to force execution of the command instead of the alias, the full path to the command must be used.

Timeouts

In order to stop remote processes when they timeout, the ideal approach would be to send them signals through the SSH connection as specified by the protocol standard.

Unfortunately OpenSSH does not implement that feature so Net::OpenSSH has to use other imperfect approaches:

close slave I/O streams

Closing the STDIN and STDOUT streams of the unresponsive remote process will effectively deliver a SIGPIPE when it tries to access any of them.

Remote processes may not access STDIN or STDOUT and even then, Net::OpenSSH can only close these channels when it is capturing them, so this approach does not always work.
killing the local SSH slave process

This action may leave the remote process running, creating a remote orphan so Net::OpenSSH does not use it unless the construction option kill_ssh_on_timeout is set.

Luckily, future versions of OpenSSH will support signaling remote processes via the mux channel.

Variable expansion

The variable expansion feature allows one to define variables that are expanded automatically inside command arguments and file paths.

This feature is disabled by default. It is intended to be used with Net::OpenSSH::Parallel and other similar modules.

Variables are delimited by a pair of percent signs (%), for instance %HOST%. Also, two consecutive percent signs are replaced by a single one.

The special variables HOST, USER and PORT are maintained internally by the module and take the obvious values.

Variable expansion is performed before shell quoting (see "Shell quoting").

Some usage example:

my $ssh = Net::OpenSSH->new('server.foo.com', expand_vars => 1);
$ssh->set_var(ID => 42);
$ssh->system("ls >/tmp/ls.out-%HOST%-%ID%");

will redirect the output of the ls command to /tmp/ls.out-server.foo.com-42 on the remote host.

Tunnels

Besides running commands on the remote host, Net::OpenSSH also allows one to tunnel TCP connections to remote machines reachable from the SSH server.

That feature is made available through the tunnel option of the "open_ex" method, and also through wrapper methods "open_tunnel" and "capture_tunnel" and most others where it makes sense.

Example:

$ssh->system({tunnel => 1,
              stdin_data => "GET / HTTP/1.0\r\n\r\n",
              stdout_file => "/tmp/$server.res"},
             $server, 80)
    or die "unable to retrieve page: " . $ssh->error;

or capturing the output of several requests in parallel:

my @pids;
for (@servers) {
  my $pid = $ssh->spawn({tunnel => 1,
                         stdin_file => "/tmp/request.req",
                         stdout_file => "/tmp/$_.res"},
                        $_, 80);
  if ($pid) {
    push @pids, $pid;
  }
  else {
    warn "unable to spawn tunnel process to $_: " . $ssh->error;
  }
}
waitpid ($_, 0) for (@pids);

Under the hood, in order to create a tunnel, a new ssh process is spawned with the option -W${address}:${port} (available from OpenSSH 5.4 and upwards) making it redirect its stdio streams to the remote given address. Unlike when ssh -L options is used to create tunnels, no TCP port is opened on the local machine at any time so this is a perfectly secure operation.

The PID of the new process is returned by the named methods. It must be reaped once the pipe or socket handlers for the local side of the tunnel have been closed.

OpenSSH 5.4 or later is required for the tunnels functionality to work. Also, note that tunnel forwarding may be administratively forbidden at the server side (see sshd(8) and sshd_config(5) or the documentation provided by your SSH server vendor).

Tunnels targeting UNIX sockets

When connecting to hosts running a recent version of OpenSSH sshd, it is also possible to open connections targeting Unix sockets.

For instance:

my $response = $ssh->capture({tunnel => 1, stdin_data => $request },
                             "/tmp/socket-foo");

Currently, this feature requires a patched OpenSSH ssh client. The patch is available as patches/openssh-fwd-stdio-to-streamlocal-1.patch.

Port forwarding

Net::OpenSSH does not offer direct support for handling port forwardings between server and client. But that can be done easily anyway passing custom SSH options to its methods.

For instance, tunnel creation options can be passed to the constructor:

my $ssh = Net::OpenSSH->new(...
                  master_opts => -Llocalhost:1234:localhost:3306');

The port forwardings can also be changed for a running SSH connection using a Control command:

# setting up a tunnel:
$ssh->system({ssh_opts => ['-O','forward',
                           '-L127.0.0.1:12345:127.0.0.1:3306']});

# canceling it:
$ssh->system({ssh_opts => ['-O', 'cancel',
                           '-L127.0.0.1:12345:127.0.0.1:3306']});

Data encoding

Net::OpenSSH has some support for transparently converting the data send or received from the remote server to Perl internal unicode representation.

The methods supporting that feature are those that move data from/to Perl data structures (e.g. capture, capture2, capture_tunnel and methods supporting the stdin_data option). Data accessed through pipes, sockets or redirections is not affected by the encoding options.

It is also possible to set the encoding of the command and arguments passed to the remote server on the command line.

By default, if no encoding option is given on the constructor or on the method calls, Net::OpenSSH will not perform any encoding transformation, effectively processing the data as latin1.

When data can not be converted between the Perl internal representation and the selected encoding inside some Net::OpenSSH method, it will fail with an OSSH_ENCODING_ERROR error.

The supported encoding options are as follows:

stream_encoding => $encoding: sets the encoding of the data send and received on capture methods.
argument_encoding => $encoding: sets the encoding of the command line arguments
encoding => $encoding: sets both argument_encoding and stream_encoding.

The constructor also accepts default_encoding, default_stream_encoding and default_argument_encoding that set the defaults.

Diverting `new`

When a code ref is installed at $Net::OpenSSH::FACTORY, calls to new will be diverted through it.

That feature can be used to transparently implement connection caching, for instance:

my $old_factory = $Net::OpenSSH::FACTORY;
my %cache;

sub factory {
  my ($class, %opts) = @_;
  my $signature = join("\0", $class, map { $_ => $opts{$_} }, sort keys %opts);
  my $old = $cache{signature};
  return $old if ($old and $old->error != OSSH_MASTER_FAILED);
  local $Net::OpenSSH::FACTORY = $old_factory;
  $cache{$signature} = $class->new(%opts);
}

$Net::OpenSSH::FACTORY = \&factory;

... and I am sure it can be abused in several other ways!

3rd PARTY MODULE INTEGRATION

Expect

Sometimes you would like to use Expect to control some program running in the remote host. You can do it as follows:

my ($pty, $pid) = $ssh->open2pty(@cmd)
    or die "unable to run remote command @cmd";
my $expect = Expect->init($pty);

Then, you will be able to use the new Expect object in $expect as usual.

Net::Telnet

This example is adapted from Net::Telnet documentation:

my ($pty, $pid) = $ssh->open2pty({stderr_to_stdout => 1})
  or die "unable to start remote shell: " . $ssh->error;
my $telnet = Net::Telnet->new(-fhopen => $pty,
                              -prompt => '/.*\$ $/',
                              -telnetmode => 0,
                              -cmd_remove_mode => 1,
                              -output_record_separator => "\r");

$telnet->waitfor(-match => $telnet->prompt,
                 -errmode => "return")
  or die "login failed: " . $telnet->lastline;

my @lines = $telnet->cmd("who");

...

$telnet->close;
waitpid($pid, 0);

mod_perl and mod_perl2

mod_perl and mod_perl2 tie STDIN and STDOUT to objects that are not backed up by real file descriptors at the operating system level. Net::OpenSSH will fail if any of these handles is used explicitly or implicitly when calling some remote command.

The work-around is to redirect them to /dev/null or to some file:

open my $def_in, '<', '/dev/null' or die "unable to open /dev/null";
my $ssh = Net::OpenSSH->new($host,
                            default_stdin_fh => $def_in);

my $out = $ssh->capture($cmd1);
$ssh->system({stdout_discard => 1}, $cmd2);
$ssh->system({stdout_to_file => '/tmp/output'}, $cmd3);

Also, note that from a security stand point, running ssh from inside the web server process is not a great idea. An attacker exploiting some Apache bug would be able to access the SSH keys and passwords and gain unlimited access to the remote systems.

If you can, use a queue (as TheSchwartz) or any other mechanism to execute the ssh commands from another process running under a different user account.

At a minimum, ensure that ~www-data/.ssh (or similar) is not accessible through the web server!

Net::SFTP::Foreign

See method sftp.

Net::SSH::Any

See method any.

Object::Remote

See method object_remote.

AnyEvent (and similar frameworks)

Net::OpenSSH provides all the functionality required to be integrated inside event oriented programming framework such as AnyEvent or IO::Async in the following way:

1. Create a disconnected Net::OpenSSH object:

my $ssh = Net::OpenSSH->new($host, async => 1, ...);

2. Let the object connect to the remote host:

Use a timer to call the wait_for_master method in async mode repeatedly until it returns a true value indicating success.

Also, the object error state needs to be checked after every call in order to detect failed connections. For instance:

my $ssh = Net::OpenSSH->new(..., async => 1);
my $w;
$w = AE::timer 0.1, 0.1, sub {
  if ($ssh->wait_for_master(1)) {
    # the connection has been established!
    # remote commands can be run now
    undef $w;
    on_ssh_success(...);
  }
  elsif ($ssh->error) {
    # connection can not be established
    undef $w;
    on_ssh_failure(...);
  }
}

3. Use the event framework to launch the remote processes:

Call Net::OpenSSH make_remote_command to construct commands which can be run using the framework regular facilities for launching external commands.

Error checking should also be performed at this point because the SSH connection could be broken.

For instance:

if (defined(my $cmd = $ssh->make_remote_command(echo => 'hello!')) {
  AnyEvent::Util::run_cmd($cmd, %run_cmd_opts);
}
else {
  # something went wrong!
}

Alternatively, any of the open* methods provided by Net::OpenSSH could also be used to launch remote commands.

4. When finished, disconnect asynchronously

After initiating an asynchronous disconnect with disconnect(1), repeatedly call wait_for_master until you get a defined but false value:

$ssh->disconnect(1);

my $w; $w = AE::timer 0.1, 0.1, sub {
  my $res = $ssh->wait_for_master(1);

  if (defined $res && !$res) {
    undef $w;
    undef $ssh;
  }
};

Be careful not to let the $ssh object go out of scope until the disconnection has finished, otherwise its destructor will wait and block your program until the disconnection has completed.

Other modules

CPAN contains several modules that rely on SSH to perform their duties as for example IPC::PerlSSH or GRID::Machine.

Often, it is possible to instruct them to go through a Net::OpenSSH multiplexed connection employing some available constructor option. For instance:

use Net::OpenSSH;
use IPC::PerlIPC;
my $ssh = Net::OpenSSH->new(...);
$ssh->error and die "unable to connect to remote host: " . $ssh->error;
my @cmd = $ssh->make_remote_command('/usr/bin/perl');
my $ipc = IPC::PerlSSH->new(Command => \@cmd);
my @r = $ipc->eval('...');

or...

use GRID::Machine;
...
my @cmd = $ssh->make_remote_command('/usr/bin/perl');
my $grid = GRID::Machine->new(command => \@cmd);
my $r = $grid->eval('print "hello world!\n"');

In other cases, some kind of plugin mechanism is provided by the 3rd party modules to allow for different transports. The method open2 may be used to create a pair of pipes for transport in these cases.

TROUBLESHOOTING

Usually, Net::OpenSSH works out of the box, but when it fails, some users have a hard time finding the cause of the problem. This mini troubleshooting guide should help you to find and solve it.

1 - check the error message

Add in your script, after the Net::OpenSSH constructor call, an error check:

$ssh = Net::OpenSSH->new(...);
$ssh->error and die "SSH connection failed: " . $ssh->error;

The error message will tell what has gone wrong.

2 - Check the connection parameters

Believe it or not, passing bad parameters to Net::OpenSSH turns to be one of the top causes of failures so check that you are using the right parameters.

Specifically, if you are obtaining them from the outside, ensure that they don't have extra spaces or new lines attached (do you need to chomp?).

Passwords and URIs may contain $ or @ characters. If you have then hardcoded in your script, check that those are quoted properly (and BTW, use strict).

3 - OpenSSH version

Ensure that you have a version of ssh recent enough:

$ ssh -V
OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8g 19 Oct 2007

OpenSSH version 4.1 was the first to support the multiplexing feature and is the minimal required by the module to work. I advise you to use the latest OpenSSH (currently 7.5).

The ssh_cmd constructor option lets you select the ssh binary to use. For instance:

$ssh = Net::OpenSSH->new($host,
                         ssh_cmd => "/opt/OpenSSH/5.8/bin/ssh")

Some hardware vendors (e.g. Sun, err... Oracle) include custom versions of OpenSSH bundled with the operating system. In principle, Net::OpenSSH should work with these SSH clients as long as they are derived from some version of OpenSSH recent enough. Anyway, my advise is to use the real OpenSSH software if you can!

4 - run ssh from the command line

Check you can connect to the remote host using the same parameters you are passing to Net::OpenSSH. In particular, ensure that you are running ssh as the same local user.

If you are running your script from a web server, the user would probably be www, apache or something alike.

Common problems are:

Remote host public key not present in known_hosts file.

The SSH protocol uses public keys to identify the remote hosts so that they can not be supplanted by some malicious third parties.

For OpenSSH, usually the server public key is stored in /etc/ssh/ssh_host_dsa_key.pub or in /etc/ssh/ssh_host_rsa_key.pub and that key should be copied into the ~/.ssh/known_hosts file in the local machine (other SSH implementations may use other file locations).

Maintaining the server keys when several hosts and clients are involved may be somewhat inconvenient, so most SSH clients, by default, when a new connection is established to a host whose key is not in the known_hosts file, show the key and ask the user if he wants the key copied there.
Wrong remote host public key in known_hosts file.

This is another common problem that happens when some server is replaced or reinstalled from scratch and its public key changes becoming different to that installed on the known_hosts file.

The easiest way to solve that problem is to remove the old key from the known_hosts file by hand using any editor and then to connect to the server replying yes when asked to save the new key.
Wrong permissions for the ~/.ssh directory or its contents.

OpenSSH client performs several checks on the access permissions of the ~/.ssh directory and its contents and refuses to use them when misconfigured. See the FILES section from the ssh(1) man page.
Incorrect settings for password or public key authentication.

Check that you are using the right password or that the user public key is correctly installed on the server.

5 - security checks on the multiplexing socket

Net::OpenSSH performs some security checks on the directory where the multiplexing socket is going to be placed to ensure that it can not be accessed by other users.

The default location for the multiplexing socket is under ~/.libnet-openssh-perl. It can be changed using the ctl_dir and ctl_path constructor arguments.

The requirements for that directory and all its parents are:

They have to be owned by the user executing the script or by root
Their permission masks must be 0755 or more restrictive, so nobody else has permissions to perform write operations on them.

The constructor option strict_mode disables these security checks, but you should not use it unless you understand its implications.

6 - file system must support sockets

Some file systems (as for instance FAT or AFS) do not support placing sockets inside them.

Ensure that the ctl_dir path does not lay into one of those file systems.

DEBUGGING

Debugging of Net::OpenSSH internals is controlled through the variable $Net::OpenSSH::debug. Every bit of this variable activates debugging of some subsystem as follows:

bit 1 - errors: Dumps changes on the internal object attribute where errors are stored.
bit 2 - ctl_path: Dumps information about ctl_path calculation and the tests performed on that directory in order to decide if it is secure to place the multiplexing socket inside.
bit 4 - connecting: Dumps information about the establishment of new master connections.
bit 8 - commands and arguments: Dumps the command and arguments for every system/exec call.
bit 16 - command execution: Dumps information about the progress of command execution.
bit 32 - destruction: Dumps information about the destruction of Net::OpenSSH objects and the termination of the SSH master processes.
bit 64 - IO loop: Dumps information about the progress of the IO loop on capture operations.
bit 128 - IO hexdumps: Generates hexdumps of the information that travels through the SSH streams inside capture operations.
bit 512 - OS tracing of the master process: Use the module Net::OpenSSH::OSTracer to trace the SSH master process at the OS level.

For instance, in order to activate all the debugging flags, you can use:

$Net::OpenSSH::debug = ~0;

Note that the meaning of the flags and the information generated is only intended for debugging of the module and may change without notice between releases.

If you are using password authentication, enabling debugging for IO::Tty may also show interesting information:

$IO::Tty::DEBUG = 1;

Finally, by default debugging output is sent to STDERR. You can override it pointing $Net::OpenSSH::debug_fh to a different file handle. For instance:

BEGIN {
  open my $out, '>', '/tmp/debug.txt' or warn $!;
  $Net::OpenSSH::debug_fh = $out;
  $Net::OpenSSH::debug = -1;
}

SECURITY

Q: Is this module secure?

A: Well, it tries to be!

From a security standpoint the aim of this module is to be as secure as OpenSSH, your operating system, your shell and in general your environment allow it to be.

It does not take any shortcut just to make your life easier if that means lowering the security level (for instance, disabling StrictHostKeyChecking by default).

In code supporting features that are not just proxied to OpenSSH, the module tries to keep the same standards of security as OpenSSH (for instance, checking directory and file permissions when placing the multiplexing socket).

On the other hand, and keeping with OpenSSH philosophy, the module lets you disable most (all?) of those security measures. But just because it lets you do it it doesn't mean it is a good idea to do so!!!

If you are a novice programmer or SSH user, and googling you have just found some flag that you don't understand but that seems to magically solve your connection problems... well, believe me, it is probably a bad idea to use it. Ask somebody how really knows first!

Just to make thinks clear, if your code contains any of the keywords from the (non-exclusive) list below and you don't know why, you are probably wrecking the security of the SSH protocol:

strict_mode
StrictHostKeyChecking
UserKnownHostsFile

Other considerations related to security you may like to know are as follows:

Taint mode

The module supports working in taint mode.

If you are in an exposed environment, you should probably enable it for your script in order to catch any unchecked command for being executed in the remote side.

Web environments

It is a bad idea to establish SSH connections from your webserver because if it becomes compromised in any way, the attacker would be able to use the credentials from your script to connect to the remote host and do anything he wishes there.

Command quoting

The module can quote commands and arguments for you in a flexible and powerful way.

This is a feature you should use as it reduces the possibility of some attacker being able to inject and run arbitrary commands on the remote machine (and even for scripts that are not exposed it is always advisable to enable argument quoting).

Having said that, take into consideration that argument-quoting is just a hack to emulate the invoke-without-a-shell feature of Perl builtins such as system and alike. There may be bugs(*) on the quoting code, your particular shell may have different quoting rules with unhandled corner cases or whatever. If your script is exposed to the outside, you should check your inputs and restrict what you accept as valid.

[* even if this is one of the parts of the module more intensively tested!]

Shellshock

(see Shellshock)

When executing local commands, the module always avoids calling the shell so in this way it is not affected by Shellshock.

Unfortunately, some commands (scp, rsync and ssh when the ProxyCommand option is used) invoke other commands under the hood using the user shell. That opens the door to local Shellshock exploitation.

On the remote side invocation of the shell is unavoidable due to the protocol design.

By default, SSH does not forward environment variables but some Linux distributions explicitly change the default OpenSSH configuration to enable forwarding and acceptance of some specific ones (for instance LANG and LC_* on Debian and derivatives, Fedora does alike) and this also opens the door to Shellshock exploitation.

Note that the shell used to invoke commands is not /bin/sh but the user shell as configured in /etc/passwd, PAM or whatever authentication subsystem is used by the local or remote operating system. Debian users, don't think you are not affected because your /bin/sh points to dash!

FAQ

Frequent questions about the module:

Connecting to switches, routers, etc.

Q: I can not get the method system, capture, etc., to work when connecting to some router, switch, etc. What I am doing wrong?

A: Roughly, the SSH protocol allows for two modes of operation: command mode and interactive mode.

Command mode is designed to run single commands on the remote host. It opens a SSH channel between both hosts, asks the remote computer to run some given command and when it finishes, the channel is closed. It is what you get, for instance, when you run something as...

$ ssh my.unix.box cat foo.txt

... and it is also the way Net::OpenSSH runs commands on the remote host.

Interactive mode launches a shell on the remote hosts with its stdio streams redirected to the local ones so that the user can transparently interact with it.

Some devices (as probably the one you are using) do not run an standard, general purpose shell (e.g. bash, csh or ksh) but some custom program specially targeted and limited to the task of configuring the device.

Usually, the SSH server running on these devices does not support command mode. It unconditionally attaches the restricted shell to any incoming SSH connection and waits for the user to enter commands through the redirected stdin stream.

The only way to work-around this limitation is to make your script talk to the restricted shell (1-open a new SSH session, 2-wait for the shell prompt, 3-send a command, 4-read the output until you get to the shell prompt again, repeat from 3). The best tool for this task is probably Expect, used alone or combined with Net::OpenSSH (see "Expect").

There are some devices that support command mode but that only accept one command per connection. In that cases, using Expect is also probably the best option.

Nowadays, there is a new player, Net::CLI::Interact that may be more suitable than Expect, and Net::Appliance::Session for working specifically with network devices.

Connection fails

Q: I am unable to make the module connect to the remote host...

A: Have you read the troubleshooting section? (see "TROUBLESHOOTING").

Disable StrictHostKeyChecking

Q: Why is ssh not run with StrictHostKeyChecking=no?

A: Using StrictHostKeyChecking=no relaxes the default security level of SSH and it will be relatively easy to end with a misconfigured SSH (for instance, when known_hosts is unwritable) that could be forged to connect to a bad host in order to perform man-in-the-middle attacks, etc.

I advice you to do not use that option unless you fully understand its implications from a security point of view.

If you want to use it anyway, past it to the constructor:

$ssh = Net::OpenSSH->new($host,
         master_opts => [-o => "StrictHostKeyChecking=no"],
         ...);

child process STDIN/STDOUT/STDERR is not a real system file handle

Q: Calls to system, capture, etc. fail with the previous error, what's happening?

A: The reported stdio stream is closed or is not attached to a real file handle (e.g. it is a tied handle). Redirect it to /dev/null or to a real file:

my $out = $ssh->capture({stdin_discard => 1, stderr_to_stdout => 1},
                        $cmd);

BUGS AND SUPPORT

Experimental features

Support for the restart feature is experimental.

Object::Remote integration is highly experimental.

Support for tunnels targeting Unix sockets is highly experimental.

Support for the setpgrp feature is highly experimental.

Support for the gateway feature is highly experimental and mostly stalled.

Support for taint mode is experimental.

Known issues

Net::OpenSSH does not work on Windows. OpenSSH multiplexing feature requires passing file handles through sockets, something that is not supported by any version of Windows.

It does not work on VMS either... well, probably, it does not work on anything not resembling a modern Linux/Unix OS.

Old versions of OpenSSH ssh may leave stdio streams in non-blocking mode. That can result on failures when writing to STDOUT or STDERR after using the module. In order to work-around this issue, Perl "fcntl" in perlfunc can be used to unset the non-blocking flag:

use Fcntl qw(F_GETFL F_SETFL O_NONBLOCK);
my $flags = fcntl(STDOUT, F_GETFL, 0);
fcntl(STDOUT, F_SETFL, $flags & ~O_NONBLOCK);

Reporting bugs and asking for help

To report bugs send an email to the address that appear below or use the CPAN bug tracking system at http://rt.cpan.org.

Post questions related to how to use the module in PerlMonks http://perlmonks.org/, you will probably get faster responses than if you address me directly and I visit PerlMonks quite often, so I will see your question anyway.

Commercial support

Commercial support, professional services and custom software development around this module are available through my current company. Drop me an email with a rough description of your requirements and we will get back to you ASAP.

My wishlist

If you like this module and you are feeling generous, take a look at my Amazon Wish List: http://amzn.com/w/1WU1P6IR5QZ42.

Also consider contributing to the OpenSSH project this module builds upon: http://www.openssh.org/donations.html.

TODO

- Tests for scp_*, rsync_* and sftp methods

- Make "pipe_in" and "pipe_out" methods "open_ex" based

- auto_discard_streams feature for mod_perl2 and similar environments

- Refactor open_ex support for multiple commands, maybe just keeping tunnel, ssh and raw

Send your feature requests, ideas or any feedback, please!

CONTRIBUTING CODE

The source code of this module is hosted at GitHub: http://github.com/salva/p5-Net-OpenSSH.

Code contributions to the module are welcome but you should obey the following rules:

Only Perl 5.8.4 required

Yes, that's pretty old, but Net::OpenSSH is intended to be also used by system administrators that sometimes have to struggle with old systems. The reason to pick 5.8.4 is that it has been the default perl on Solaris for a long time.

Avoid the "All the world's a Linux PC" syndrome

The module should work on any (barely) sane Unix or Linux operating system. Specially, it should not be assumed that the over-featured GNU utilities and toolchain are available.

Dependencies are optional

In order to make the module very easy to install, no mandatory dependencies on other CPAN modules are allowed.

Optional modules, that are loaded only on demand, are acceptable when they are used for adding new functionality (as it is done, for instance, with IO::Pty).

Glue code for integration with 3rd party modules is also allowed (as it is done with Expect).

Usage of language extension modules and alike is not acceptable.

Tests should be lax

We don't want false negatives when testing. In case of doubt tests should succeed.

Also, in case of tests invoking some external program, it should be checked that the external program is available and that it works as expected or otherwise skip those tests.

Backward compatibility

Nowadays Net::OpenSSH is quite stable and there are lots of scripts out there using it that we don't want to break, so, keeping the API backward compatible is a top priority.

Probably only security issues could now justify a backward incompatible change.

Follow my coding style

Look at the rest of the code.

I let Emacs do the formatting for me using cperl-mode PerlStyle.

Talk to me

Before making a large change or implementing a new feature get in touch with me.

I may have my own ideas about how things should be done. It is better if you know them before hand, otherwise, you risk getting your patch rejected.

Well, actually you should know that I am quite good at rejecting patches but it is not my fault!

Most of the patches I get are broken in some way: they don't follow the main module principles, sometimes the author didn't get the full picture and solved the issue in a short-sighted way, etc.

In any case, you should not be discouraged to contribute. Even if your patch is not applied directly, seeing how it solves your requirements or, in the case of bugs, the underlying problem analysis may be very useful and help me to do it... my way.

I always welcome documentation corrections and improvements.

COPYRIGHT AND LICENSE

This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself, either Perl version 5.10.0 or, at your option, any later version of Perl 5 you may have available.

To install Net::OpenSSH, copy and paste the appropriate command in to your terminal.

cpanm

cpanm Net::OpenSSH

CPAN shell

perl -MCPAN -e shell
install Net::OpenSSH

For more information on module installation, please visit the detailed CPAN module installation guide.

	Global
`s`	Focus search bar
`?`	Bring up this help dialog

	GitHub
`g` `p`	Go to pull requests
`g` `i`	go to github issues (only if github is preferred repository)

	POD
`g` `a`	Go to author
`g` `c`	Go to changes
`g` `i`	Go to issues
`g` `d`	Go to dist
`g` `r`	Go to repository/SCM
`g` `s`	Go to source
`g` `b`	Go to file browse

	Search terms
module: (e.g. module:Plugin)
distribution: (e.g. distribution:Dancer auth)
author: (e.g. author:SONGMU Redis)
version: (e.g. version:1.00)

NAME

SYNOPSIS

DESCRIPTION

Under the hood

Net::OpenSSH Vs. Net::SSH::.* modules

API

Optional arguments

Error handling

Net::OpenSSH methods

Shell quoting

Timeouts

Variable expansion

Tunnels

Tunnels targeting UNIX sockets

Port forwarding

Data encoding

Diverting new

3rd PARTY MODULE INTEGRATION

Expect

Net::Telnet

mod_perl and mod_perl2

Net::SFTP::Foreign

Net::SSH::Any

Object::Remote

AnyEvent (and similar frameworks)

Other modules

TROUBLESHOOTING

DEBUGGING

SECURITY

FAQ

SEE ALSO

BUGS AND SUPPORT

Experimental features

Known issues

Reporting bugs and asking for help

Commercial support

My wishlist

TODO

CONTRIBUTING CODE

COPYRIGHT AND LICENSE

Module Install Instructions

Diverting `new`