Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have twin Linux servers that should be configured identically, however ssh commands to one of them are failing for commands that require a path that's specified in ~/.bashrc. For example, I can use a command like pwd both interactively and through ssh, but if I try running a program that's located in an application bin folder, it only works in an interactive shell for one of the servers.

The /etc/profile and /etc/environment file on both servers are identical, however $BASH_ENV is set to ~/.bashrc on the server that is working properly. I want to set $BASH_ENV on the server that's not working, but I'd prefer to set it in the same location as it's set in the working server. What are the places that Linux will run at the time of a non-interactive login, such as an ssh command from another computer?

edit: The line in /etc/passwd for the user specifies /bin/bash on both servers. The ~/.bash_profile file for both servers is identical, and contains if [ -f ~/.bashrc ]; then . ~/.bashrc; fi. The only difference between the systems is that $BASH_ENV is a null string on the server that's not working, and I can't find where it's been set in the server that's working.

edit 2: The ~/.ssh/environment file on both servers has BASH_ENV=~/.bashrc

share|improve this question
1  
Is /etc/passwd identical on both servers? If bash is called as "/bin/sh" instead of "/bin/bash" it won't read any bashrc files (only profile files). –  freiheit May 6 at 18:10
    
Not identical, but the user I'm sending commands as has the same line in /etc/passwd on both systems. –  Basil May 6 at 18:18
    
And what about ~/.profile and ~/.bash_profile? –  freiheit May 6 at 18:26
    
they're identical and both contain if [ -f ~/.bashrc ]; then . ~/.bashrc; fi –  Basil May 6 at 18:30
    
You've verified that /etc/bashrc and /etc/profile.d/* are identical? ~/.bash_login? /etc/pam.d/*? /etc/security/pam_env.conf? –  freiheit May 6 at 18:38

1 Answer 1

up vote 11 down vote accepted
+100

BASH_ENV is only going to be set via the environment, or another script that is sourced during initialization. For a non-interactive shell, it will only be trying to source additional files if that shell is also a login shell. (in which case it'll read ~/.bash_profile, ~/.bash_login, and ~/.profile...but if it was doing that, you wouldn't be experiencing an issue)

The first place to look is the environment in which the subshell is being invoked.

  • An exported BASH_ENV variable will be passed through. Keep in mind that this may be buried in a sourced file.
  • It can be fed in as a parameter on the same line calling the script, i.e. BASH_ENV=blah /path/to/somecommand.sh. This stands out like a sore thumb so you probably would have caught it.

If it's being set after you log in but you can't figure out where, you may need to look at what is responsible for constructing the login environment.

  • All of the usual files that get sourced by a login shell. man bash for the exhaustive list.

  • PAM: As freiheit suggested in the comments, check /etc/security/pam_env.conf, and any additional files that are referenced by pam_env.so. Other PAM modules could also be responsible, but if your PAM configs look identical this is probably not the case.

  • sshd: It will scan the following files, in order:

    • ~/.ssh/environment (before changing to the home directory; only if PermitUserEnvironment is enabled in sshd_config)
    • ~/.ssh/rc (after changing to the home directory; always)
    • /etc/ssh/sshrc (if ~/.ssh/rc is not present)

Note: sshd will also scan for environment=value lines in the user's authorized keys file (if PermitUserEnvironment is enabled), but it is not clear from the man page where that step falls in the above sequence.

share|improve this answer
    
I found a difference! PermitUserEnvironment yes is set in /etc/ssh/sshd_config on the working server, but not the problem one. I changed it, but I just tested a command and it didn't work again. Does this file get parsed every time I try to ssh in? I don't have a ~/.ssh/rc for the user I'm working on, and there's no /etc/ssh/sshrc file on either system. –  Basil May 6 at 19:41
    
Oh, I think I need to reinitialize ssh? /etc/init.d/sshd? –  Basil May 6 at 19:46
    
@Basil Yeah, you need to restart sshd. It also means there might be a file on the working server (check the list of ones I gave you for sshd) that is setting the environment. –  Andrew B May 6 at 23:39
    
Yeah, that was the frustrating part- everything I need is set in .bashrc, which was just not being run :) Thanks so much for your help- I'm scheduling a change to reinitialize SSH and I'll report back. I assume it'll work. –  Basil May 7 at 0:31
    
I just finished reinitializing SSH and my non-interactive SSH commands are now working! Thank you so much for your help, I'd have never found that field on my own. –  Basil May 12 at 18:39

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.