A far better strategy, if you absolutely must use a programmatic login or su, is to arrange for login to occur using SSH public/private keys.   The script would present its key to avoid the possibility of an actual password challenge.

Naturally, I am extraordinarily uncomfortable with the idea of a script logging on as root...   Almost as uncomfortable as I am with the notion of a script possessing credentials that would allow (anyone) to do so.

sundialsvc++!!

Login as an untrusted user and drop stuff off. The working user (probably does not need to be root) can poll for the submission and then "do stuff".

crontab is your friend here.

David.

It uses Net::OpenSSH to establish the connection to the remote host and Expect to handle the interaction with sudo.

#!/usr/bin/perl

use strict;
use warnings;

use Net::OpenSSH;
use Expect;

select STDOUT; $| = 1;
select STDERR; $| = 1;

my $password = $ARGV[0];
my $timeout = 20;

my $debug = 0;

my $ssh = Net::OpenSSH->new('test@127.0.0.1', password => $password);

# my ($pty, $pid) = $ssh->open2pty("sudo cat /etc/shadow")

# After a successful sudo operation, it doesn't request the password
# again until some time after, handling this undeterministic behaviour
# is a pain in the ass, so we just clear any cached credentials
# calling "sudo -k" first as follows:
my ($pty, $pid) = $ssh->open2pty("sudo -k; sudo cat /etc/shadow")
    or die "open2pty failed: " . $ssh->error . "\n";

my $expect = Expect->init($pty);
$expect->raw_pty(1);
$debug and $expect->log_user(1);

$debug and print "waiting for password prompt\n";
$expect->expect($timeout, ':')
    or die "expect failed\n";
$debug and  print "prompt seen\n";

$expect->send("$password\n");
$debug and print "password sent\n";

$expect->expect($timeout, "\n")
    or die "bad password\n";
$debug and print "password ok\n";

while(<$pty>) {
    print "$. $_"
}
[download]

Highly speculative reply (since I don't use Net::SSH::Perl) ...

If there's any substantive basis for your supposition, "(m)ay be the password is sent too early and not recognized," then it may be worth your while to sleep 1 (or more) between sending the su - and the password (or, if that's not feasible, separate into two transmissions. Any system I'm familiar with will throw up a prompt for the password).

Alternately, you may want to consider whether there's a clue in the disparity between narrative and code: "/r/n" versus \r\n.

I believe that the tool to be used here is sudo.

If I may hazard a general statement here... I rather think that too many developers “routinely” have access to root.   And they (so to speak) “lazily” write code that “merely assumes it.”   They write code that does things as they would (can...) do it.   And this quickly leads to trouble.

The “principle of least privilege” needs to apply to every privileged thing that you do.   I happen to think that it is an excellent practice to dictate that no developer shall have access to root.   If you impose that restriction upon them (also building the restriction that “developers have no way to reach the production databases, directories and files,” no matter how loudly they whine), that restriction becomes reflected in their code.   Necessity is the mother of invention.   Even a self-imposed version of that discipline is beneficial.   This point-of-view needs to be something that is “in your blood.”

I have used Net::SSH::Expect to perform this task with both key-based and password authentication.

Any expect-capable script should resolve any of your timing concerns.