Use command 2 incase command 1 fails

Applications Cybersecurity
1

I try to fire grep command on remote servers using ssh like below:

sshpass -p mypassword ssh -t user1@mach2 "grep -e word1 -e word2 /var/out.txt"

The issue is that i wish to run the same grep command which searches for multiple strings in a file on remote servers with different Operating Systems as below.

Linux mach1 2.6.18-436.el5 #1 SMP Thu Nov 22 06:38:01 EST 2018 x86_64 x86_64 x86_64 GNU/Linux

SunOS mach2 5.10 Generic_150400-63 sun4u sparc SUNW,SPARC-Enterprise

On SunOS grep fails however /usr/xpg4/bin/grep works fine.

How can i tweak my ssh command to switch between grep and /usr/xpg4/bin/grep so it works without failing on both flavors of OS ?

2

Just use the full path of grep in your script.

sshpass -p mypassword ssh -t user1@mach2 "/full/path/to/grep -e word1 -e word2 /var/out.txt"

Run a different script for different classes of servers.

You really like to make very complex solutions to very easy problems. If I worked like you, I would never get anything done because you always try to create some overly complex solution to a very easy to solve problem.

You have been working on this for weeks, but if you built a simple solution, you could finish in a few hours !!! !!!

You have nothing else to do at work but make things more complex than they need to be??

3

This would fail on Linux servers where only grep works and not the one with the full path.

Hence, i would need to use the full path only if grep command fails & if my memory helps me I guess there should be a way to achieve this.

4

It does not fail if you use a different script for each major class of server like I said in my reply.

5

There is a common method:
specify a PATH that works on all systems - knowing that non-existing PATH components are skipped.

sshpass -p mypassword ssh -t user1@mach2 "PATH=/usr/xpg4/bin:/bin grep -e word1 -e word2 /var/out.txt"

The PATH= is a sh construct. If the remote user has a csh login shell, use the external command /usr/bin/env PATH=/usr/xpg4/bin:/bin grep ...

6

This problem with this method is that it can create a security vulnerability to be searching paths which do not exist on machines. It's dangerous on production systems in high risk environments (like financial services systems).

So, if anyone in his company (which in the case of this poster, is a major investment bank) purposely or accidentally injects a faux grep in the path, it could easily be exploited and cause problems.

So creating solutions passing a PATH which we know is going to traverse non-existant commands "is a kludge" which is not necessary (because there are better solutions) and adds a security vulnerability for the sake of sticking with a poor implementation. It is better to build simple, secure solutions, not kludges when working on "high risk" systems.

The solution is for the poster to stop using sshpass (as we have told him many times), and user password-less SSH (with shared encryption keys) and to build a secure solution and to STOP kludging things together because......

I think the poster is just lazy to set up the keys on 300 servers, and so because of this "laziness" (for a lack of better word or visibility into his workplace) he is making the company he works for more vulnerable to attackers.

The same is true for trying to come up with a one-liner that works for all systems which traverses the filesystem. It just creates vulnerabilities, unnecessarily.

We cannot condone or support creating vulnerabilities here when we know the poster is creating solutions for his employer, a major financial institution.

7

I do not agree regarding the PATH setting.
A given PATH with /usr/... or /bin/... components can be trusted more than a PATH that might come from the remote user's .bashrc.
For the same reason a script should set PATH at the beginning.