ssh-connecting to rbash won't source the .profile file

Question

I am using libssh to connect to a remote machine and execute commands.

The connection works fine, but here's the rub: on the distant machine, the bash that is running while I'm connected is a rbash. When I send ps | grep ungreppable_phrase to be executed on the other machine, here is the output:

root 25989 25987 0 07:47 ? 00:00:00 rbash -c ps -ef | grep ungreppable_phrase

(I removed the grep command from that list)

So, obviously, rbash is the remote shell.

Now, rbash man page tells us the startup files are read before any of the rbash restrictions are applied. So, if any of my startup files (/etc/profile, ~/.bash_profile; ~/.bash_user or ~/.profile) contains a definition for PATH, that definition should be visible when I run my commands. Especially, if there are some executable files in one of the directories of PATH, I should be able to run it.

Here's a line from my .profile file:

PATH=/home/my_user/bin

Somehow, I managed to run a ls in there. It does contain executable files.

My ~/.profile is the last file to be sourced, and it doesn't contain any sourcing of another file. Nor any redefinition of PATH.

But I get a "command not found" error (or something that looks like it very much, the echo $? returns 127).

Can someone tell me why it seems that my .profile file isn't sourced when I remotely log in? Is it due to some code in libssh ? I'm trying to explore it to find if there are some special otpions that are passed to rbash that I can't see with the grep above..

(Since we're in rbash mode, I can't simply require the PATH to be changed)

Many thanks, Pascal

Answer 1

Ah, I finally found what was wrong.

After some investigation, it appeared that when I logged into the machine via ssh {username}@{host} (via the libssh API), whoami wouldn't reply username, but, instead, replied root(yes, root. 0:0, allmight, and everything. THE super-user).

I checked the /etc/passwd file, and, at my biggest surprise, username also had 0:0 userid.

root sources bash (whereas {username} would use rbash) in my environment. Hence the problem found above.

Now, why ssh switches to "name1" when "name1" and "name2" are aliases, and you run ssh name2@host via libssh still remains obscure. But at least, I know why my connection above wouldn't work.

Answer 2

The man page you linked indicates that this is regular bash, then it gets restricted. So, how is your bash getting started? How bash starts tells it what files to read. Note also that when it searches for ~/.profile it will only use it if you don't also have a ~/.bash_profile file. It only looks for these files if bash is run as an interactive login shell.

Farther down the page, you can see where it reads ~/.bashrc for shells started by ssh. In summary, the most likely explanation is that none of the files you mention are actually being read, if you have no ~/.bashrc file or it does not source your ~/.profile.