running rex from another perl script

[David Woodyard]

I am on Fedora 30 and rex 1.5

I have been using rex since v. 0.6x

I have a systemd process that runs a perl script.

If conditions warrant a change on remote computer the following is run from the perl script:

qx{rex -f /home/G/rexfile -H  RemoteComputer TaskName};

it displays the following error:

WARN - Can't authenticate against xxxxxxx (unable to establish master SSH connection: bad password or master process exited unexpectedly)

I use key_auth only.

It never tries to use key_auth or at least not correctly.

running the rex command from command line works correctly.

Appreciate any help with this,

David

[Ferenc Erki]

Hi David,

thanks for your patience on this thread.

On 2020-02-12 12:24, David Woodyard wrote:
>I am on Fedora 30 and rex 1.5

As an aside, that's a bit old rex version. It might be interesting to
reach out to Fedora maintainers to see if they need help with newer
versions.

>I have been using rex since v. 0.6x

I'm very glad to hear that! :)

>I have a systemd process that runs a perl script.
>
>If conditions warrant a change on remote computer the following is run from
>the perl script:
>
>qx{rex -f /home/G/rexfile -H RemoteComputer TaskName};
>
>
>
>it displays the following error:
>
>WARN - Can't authenticate against xxxxxxx (unable to establish master SSH
>connection: bad password or master process exited unexpectedly)
>
>I use key_auth only.
>It never tries to use key_auth or at least not correctly.
>
>running the rex command from command line works correctly.

It might be useful to learn more about the involved Rexfile and
TaskName, but based on these details, I would suspect that the perl
script run by systemd is being executed as a different user and/or with
a different environment, and the built-in auto-discovery of ssh keys
can't find the proper ones, thus leading to authentication failures.

If that's the case, any or all of the following might help:

- specifying the key locations directly in the Rexfile
- making sure systemd runs the perl script as the same user as you use
for manual execution

Hope this helps!

cheers,
FErki

[David Woodyard]

I got your reply when I was out of town.

I tested several settings and have concluded that when I tries to read the config file in the user directory (.ssh of course).

Not always but several times it displayed a permission error for that file. I changed it to 777 and that did not help.

Rex does knows the user name, computer name the private/public files and that it should be using key_auth.

The debug info that start with the following:

 

OpenSSH options:
[2020-03-08 16:45:41] DEBUG - $VAR1 = [

does not convert the computer name to an ip address or set the port to any number.

any ideas for further testing will be appreciated,

David

[Ferenc Erki]

Hi David,

On 2020-03-08 15:30, David Woodyard wrote:
>> I am on Fedora 30 and rex 1.5

FYI, you can now use `dnf -y update Rex --enable-repo=updates-testing`
to install Rex-1.8.2 (current latest) from the updates-testing repos.
Domonic Hopf, the package maintainer, is also looking for feedback/karma
on this link:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-2ad1ed20ac

>> I have a systemd process that runs a perl script.

I don't have a systemd machine at hand, but I assume the following:
systemd runs as the root user, and and it runs your perl script as root
user too.

>> qx{rex -f /home/G/rexfile -H RemoteComputer TaskName};

If th above assumptions are true, then I guess this line is being run as
root too. So by default, rex would look for ssh keys of root. That may
or may not what you want to use.

>> I use key_auth only.

I would recommend running rex from your perl script under systemd with
the debug flag, and it should print the authentication details out. It
should not contains sensitive info like passwords, etc., but please
double check and if its fine, post it to some kind of paste service.
Then share the link with us here or IRC, so more people can look at it.

>> It never tries to use key_auth or at least not correctly.

My hypothesis is that it runs as a different user under systemd and
manually on the command line. And because of that, it picks up the wrong
set of ssh keys.

>> running the rex command from command line works correctly.

Is this successful run being executed as a different user than the perl
script in systemd uses?

>I tested several settings and have concluded that when I tries to read
>the
>config file in the user directory (.ssh of course).
>Not always but several times it displayed a permission error for that file.
>I changed it to 777 and that did not help.

By default, ssh blocks using ssh keys if the ownership and permissions
of the key directory are not correct, so I expect `777` would not work
at all (well, at least not without disabling StrictMode ssh configs).

>Rex does knows the user name, computer name the private/public files
>and
>that it should be using key_auth.

I believe you mean the user rex uses to connect to the remote machine.
And I mean the user in whose name rex is being run as a process. These
might be different when run on the command line as a user, and when run
from systemd.

>The debug info that start with the following:
>
>
>> OpenSSH options:
>> [2020-03-08 16:45:41] DEBUG - $VAR1 = [

Yep, that full debug output would be helpful to better understand what's
happening.

>> does not convert the computer name to an ip address or set the port
>> to any
>number.

I'm not sure I fully understand what this means, but it might also
indicate that the rex command might be being executed as a different
user under systemd than the user used to execute it from the command
line.

>any ideas for further testing will be appreciated,

If you need further help, please ping us on IRC. There are more people
who might help further debugging this, and probably in a more effective
way.

cheers,
FErki

[David Woodyard]

On Wednesday, February 12, 2020 at 2:24:50 PM UTC-6, David Woodyard wrote:

I am on Fedora 30 and rex 1.5

I have been using rex since v. 0.6x

I have a systemd process that runs a perl script.

If conditions warrant a change on remote computer the following is run from the perl script:

qx{rex -f /home/G/rexfile -H  RemoteComputer TaskName};

 

Fedora has updated the Rex package to Rex-1.8.2-1.fc31.noarch.

Testing has shown that running a Rex command from another perl program now works.

I was previously using version 1.5.2. Must have been a bug in that version that has since been fixed.

David

[Ferenc Erki]

Hi David,

On 2020-04-15 20:08, David Woodyard wrote:

> Fedora has updated the Rex package to Rex-1.8.2-1.fc31.noarch.
>
>Testing has shown that running a Rex command from another perl program now
>works.
>I was previously using version 1.5.2. Must have been a bug in that version
>that has since been fixed.

Thanks for keeping us updated, and I'm glad a version upgrade fixed your
use case. Happy Rexing! :)

cheers,
FErki