Ssh call in a script invoked from .bashrc

This is the 2nd ssh-related issue for which I cannot seem to find a solution that I ran into, but it is more immediate so I will start with it.

We have a script (call it env, since it is setting up some env vars) that gets invoked from .bashrc when a user U1 (not really U1, but that shouldn't make any difference) logs in.

Before my change, env was setting some env variable (call it VAR) to a fixed string. Because of some changes that I have been working on, we can no longer set it to a fixed string. Instead, we need to set it to a string returned by

$(ssh -oStrictHostKeyChecking=no U2@$HOSTNAME "sudo ls -l /proc/$PID/cwd 2>/dev/null" | awk '{print $11}'|sed 's/\/dbs//')

I am forced to use ssh because

• only root can examine /proc/$PID/cwd and
• U1 cannot sudo to root but U2 can, and U1 can ssh as U2

When one logs in as U1 (e.g. by issuing sudo su -l U1) , everything works exactly as intended (including VAR getting set to a correct value), but if a user who has privileges to sudo to U1 tries to issue

sudo su - U1 <<EOF 
 pwd 
EOF

no output is produced. I know that the problem does not lie with sudo in the above expression because when I replaced the above expression used to set VAR with

$(ssh -oStrictHostKeyChecking=no U2@$HOSTNAME "echo some_string 2>/dev/null")

the problem did not go away, but when I replaced it with

$(echo /u02/app/oracle/product/19.0.0.0/dbhome_1 2>/dev/null)

sudo su - U1 <<EOF 
 pwd 
EOF

produced

/home/U1

which is what was expected.

Any thoughts, suggestions, pointers?

Many thanks

Welcome!
ssh by default fills a buffer from stdin, so might read from the "here document" after
<<EOF
Try ssh -n

Ideas for smplification:
sudo ls -l /proc/$PID/cwd
Perhaps
pwd
?
sudo su - U1 <<EOF
Perhaps
sudo -iu U1 <<EOF
?

Here are the arguments I use for the ssh command:
-o NumberOfPassWordPrompts=0 -o PasswordAuthentication=no -o StrictHostChecking=no -o CheckHostIP=no -o ConnectTimeout=20 -o ServerAliveInterval=35
Note: Doub;e check theses name, cannot copy & paste so there may be typoes.

Of note: This is NOT a good idea! If something goes wrong, it will mess up your login. I have lots of users who put dependencies on other things in their .bashrc and it causes problems (sometimes).

Here's why I use all those arguments in my ssh command:
I have a program that ssh's into a list of machines and does 'something' (i.e. install software, start services, etc.). If the host keys in /etc/ssh/ssh_known host aren't correct (and I have that check turned on), or the IP address changes, or the SSH keys are messed up, or the ssh hangs, it stops everything from running. These options allow the ssh to just return an error and not hang the whole process.

Q: What happens if the ssh fails? Or it returns nothing? Or someone has removed the NOPASSWD option from the sudoers file (proper hardening requires it to be removed), etc. What happens to your login process?
If there is a failure, or an invalid return, can you set a default value? Even if it is INVALID or UNKNOWN, which can alert the user that it didn't work?

My suggestion would be to do something like this:
The user Root on $HOSTNAME runs the ls command and stores the output in a file:
ls -l /proc/$PID/cwd 2>/dev/null | awk '{print $11}'|sed 's/\/dbs//' > /share/env_file
Where /share/env_file is a file with a mount point shared amongst all the users (like /home/share).
Then, you .bashrc only needs to read the file to get its value, such as:
*env*=$(</share/env_file)

This is much safer & faster

@akruglik ,coming late to this ....

I may be missing 'the obvious', but ...

Why not have an entry in the sudoers file that allows user U1 run the commands under U2 account ....

Feel free to ignore if the above is not possible/irrelevant/misunderstanding ....

Thank you for your suggestions.

You are right in that using ssh during login is not the best idea. However, my lengthy dive into other suggestions for determining ORA_PMON's path came with exactly one promising solution, which I saw little choice but to borrow.

The problem that your solution (caching the path in /share/env_file) does not address (and there is no reason why you should have been aware of it) is that the process whose PID I am using may get bounced and come up with a different path (I could explain, but it gets long) which makes caching that value not very reliable.

What I was hoping for was

• an explanation for why the statement(s) in the heredoc did not get executed and
• what I can do about it

As it happens, I got answers to both:

• apparently (and I have to take the respondent's word for it), ssh truncates the buffer where heredoc statement(s) are stored, so all of a sudden, there was nothing to execute
• trace file created by ORA_PMON process contains a line describing ORACLE_HOME path (which is what I was after), and that file is guaranteed to exist if ORA_PMON is riunning and there is a well-defined way to locate that file.

And that us how I solved the problem, learning something new in the process.

Regards

Unfortunaely, I do not have the freedom to mess with sudoers. Things are set up the way they are for a reason, and I am just expected to find the way given the existing contraints. Luckily (see my response to [ScottieH]), I came across a solution to my problem that does not require any config changes.

Many thanks

@akruglik , ok, so that's a result for you. Can you do the courtesy and share that solution back to the forum (in this thread), so the forum audience can benefit from that.

As an aside, if you had mentioned the actual goal - getting the ORACLE_HOME path, to begin with you may have been given different advice.

thks