ssh ignores variables in profile files

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP








up vote
1
down vote

favorite












Apologies for this vague question in advance, but I don't know how to narrow this down.



I'm on Ubuntu 14.04.5 LTS, using OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.10, OpenSSL 1.0.1f 6 Jan 2014 as my ssh client. I set up passwordless ssh according to these instructions: https://help.ubuntu.com/lts/serverguide/openssh-server.html.



Now, ssh works as expected, except all variables that I define in .bashrc or .profile are ignored (yes, I'm aware that .profile sources .bashrc). All posts related to this issue I could find on askubuntu.com, or stackexchange or the like did not solve this issue.



Local variables exist on both the local and the remote machine, but when I ssh into the remote machine, they aren't there, which means they're missing from the output of 'ssh ab.cd.efg.hij env'; likewise, ssh ab.cd.efg.hij 'echo $LOCAL_VARIABLE' gives no output.



What could be the reason for this behavior?



EDIT



I did not have .bash_profile or .bash_login on the remote machine, as asked by steeldriver. I added export LOCAL_VARIABLE=foo to one and then the other, but it's still missing from 'ssh ab.cd.efg.hij env' and ssh ab.cd.efg.hij 'echo $LOCAL_VARIABLE'.










share|improve this question























  • Do you have a ~/.bash_profile or ~/.bash_login on the remote machine?
    – steeldriver
    Mar 21 at 22:05










  • OK I read your question again and now I'm confused - are you expecting your local shell environment to be inherited by the remote shell when you start an SSH session?
    – steeldriver
    Mar 21 at 22:35










  • Yes and no. I'm trying to use openmpi via a proprietary software. I need SSH to recognize $LOCAL_VARIABLE so openmpi works with the application I'm using (proprietary software). Customer support and I have narrowed the issue down to $LOCAL_VARIABLE (which is the path to the license file for the program) not being available via SSH. It doesn't matter to me if $LOCAL_VARIABLE is inherited by SSH, or if it is read (not sure "read" is the proper term) by SSH on the remote machine. Does this make it clearer?
    – Markus Heller
    Mar 21 at 22:43










  • Not for me - sorry. Unless you are asking something like this: When ssh'ing, how can I set an environment variable on the server that changes from session to session?
    – steeldriver
    Mar 21 at 23:04















up vote
1
down vote

favorite












Apologies for this vague question in advance, but I don't know how to narrow this down.



I'm on Ubuntu 14.04.5 LTS, using OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.10, OpenSSL 1.0.1f 6 Jan 2014 as my ssh client. I set up passwordless ssh according to these instructions: https://help.ubuntu.com/lts/serverguide/openssh-server.html.



Now, ssh works as expected, except all variables that I define in .bashrc or .profile are ignored (yes, I'm aware that .profile sources .bashrc). All posts related to this issue I could find on askubuntu.com, or stackexchange or the like did not solve this issue.



Local variables exist on both the local and the remote machine, but when I ssh into the remote machine, they aren't there, which means they're missing from the output of 'ssh ab.cd.efg.hij env'; likewise, ssh ab.cd.efg.hij 'echo $LOCAL_VARIABLE' gives no output.



What could be the reason for this behavior?



EDIT



I did not have .bash_profile or .bash_login on the remote machine, as asked by steeldriver. I added export LOCAL_VARIABLE=foo to one and then the other, but it's still missing from 'ssh ab.cd.efg.hij env' and ssh ab.cd.efg.hij 'echo $LOCAL_VARIABLE'.










share|improve this question























  • Do you have a ~/.bash_profile or ~/.bash_login on the remote machine?
    – steeldriver
    Mar 21 at 22:05










  • OK I read your question again and now I'm confused - are you expecting your local shell environment to be inherited by the remote shell when you start an SSH session?
    – steeldriver
    Mar 21 at 22:35










  • Yes and no. I'm trying to use openmpi via a proprietary software. I need SSH to recognize $LOCAL_VARIABLE so openmpi works with the application I'm using (proprietary software). Customer support and I have narrowed the issue down to $LOCAL_VARIABLE (which is the path to the license file for the program) not being available via SSH. It doesn't matter to me if $LOCAL_VARIABLE is inherited by SSH, or if it is read (not sure "read" is the proper term) by SSH on the remote machine. Does this make it clearer?
    – Markus Heller
    Mar 21 at 22:43










  • Not for me - sorry. Unless you are asking something like this: When ssh'ing, how can I set an environment variable on the server that changes from session to session?
    – steeldriver
    Mar 21 at 23:04













up vote
1
down vote

favorite









up vote
1
down vote

favorite











Apologies for this vague question in advance, but I don't know how to narrow this down.



I'm on Ubuntu 14.04.5 LTS, using OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.10, OpenSSL 1.0.1f 6 Jan 2014 as my ssh client. I set up passwordless ssh according to these instructions: https://help.ubuntu.com/lts/serverguide/openssh-server.html.



Now, ssh works as expected, except all variables that I define in .bashrc or .profile are ignored (yes, I'm aware that .profile sources .bashrc). All posts related to this issue I could find on askubuntu.com, or stackexchange or the like did not solve this issue.



Local variables exist on both the local and the remote machine, but when I ssh into the remote machine, they aren't there, which means they're missing from the output of 'ssh ab.cd.efg.hij env'; likewise, ssh ab.cd.efg.hij 'echo $LOCAL_VARIABLE' gives no output.



What could be the reason for this behavior?



EDIT



I did not have .bash_profile or .bash_login on the remote machine, as asked by steeldriver. I added export LOCAL_VARIABLE=foo to one and then the other, but it's still missing from 'ssh ab.cd.efg.hij env' and ssh ab.cd.efg.hij 'echo $LOCAL_VARIABLE'.










share|improve this question















Apologies for this vague question in advance, but I don't know how to narrow this down.



I'm on Ubuntu 14.04.5 LTS, using OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.10, OpenSSL 1.0.1f 6 Jan 2014 as my ssh client. I set up passwordless ssh according to these instructions: https://help.ubuntu.com/lts/serverguide/openssh-server.html.



Now, ssh works as expected, except all variables that I define in .bashrc or .profile are ignored (yes, I'm aware that .profile sources .bashrc). All posts related to this issue I could find on askubuntu.com, or stackexchange or the like did not solve this issue.



Local variables exist on both the local and the remote machine, but when I ssh into the remote machine, they aren't there, which means they're missing from the output of 'ssh ab.cd.efg.hij env'; likewise, ssh ab.cd.efg.hij 'echo $LOCAL_VARIABLE' gives no output.



What could be the reason for this behavior?



EDIT



I did not have .bash_profile or .bash_login on the remote machine, as asked by steeldriver. I added export LOCAL_VARIABLE=foo to one and then the other, but it's still missing from 'ssh ab.cd.efg.hij env' and ssh ab.cd.efg.hij 'echo $LOCAL_VARIABLE'.







bash ssh environment-variables






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Mar 21 at 22:23









wjandrea

7,19342255




7,19342255










asked Mar 21 at 21:46









Markus Heller

83




83











  • Do you have a ~/.bash_profile or ~/.bash_login on the remote machine?
    – steeldriver
    Mar 21 at 22:05










  • OK I read your question again and now I'm confused - are you expecting your local shell environment to be inherited by the remote shell when you start an SSH session?
    – steeldriver
    Mar 21 at 22:35










  • Yes and no. I'm trying to use openmpi via a proprietary software. I need SSH to recognize $LOCAL_VARIABLE so openmpi works with the application I'm using (proprietary software). Customer support and I have narrowed the issue down to $LOCAL_VARIABLE (which is the path to the license file for the program) not being available via SSH. It doesn't matter to me if $LOCAL_VARIABLE is inherited by SSH, or if it is read (not sure "read" is the proper term) by SSH on the remote machine. Does this make it clearer?
    – Markus Heller
    Mar 21 at 22:43










  • Not for me - sorry. Unless you are asking something like this: When ssh'ing, how can I set an environment variable on the server that changes from session to session?
    – steeldriver
    Mar 21 at 23:04

















  • Do you have a ~/.bash_profile or ~/.bash_login on the remote machine?
    – steeldriver
    Mar 21 at 22:05










  • OK I read your question again and now I'm confused - are you expecting your local shell environment to be inherited by the remote shell when you start an SSH session?
    – steeldriver
    Mar 21 at 22:35










  • Yes and no. I'm trying to use openmpi via a proprietary software. I need SSH to recognize $LOCAL_VARIABLE so openmpi works with the application I'm using (proprietary software). Customer support and I have narrowed the issue down to $LOCAL_VARIABLE (which is the path to the license file for the program) not being available via SSH. It doesn't matter to me if $LOCAL_VARIABLE is inherited by SSH, or if it is read (not sure "read" is the proper term) by SSH on the remote machine. Does this make it clearer?
    – Markus Heller
    Mar 21 at 22:43










  • Not for me - sorry. Unless you are asking something like this: When ssh'ing, how can I set an environment variable on the server that changes from session to session?
    – steeldriver
    Mar 21 at 23:04
















Do you have a ~/.bash_profile or ~/.bash_login on the remote machine?
– steeldriver
Mar 21 at 22:05




Do you have a ~/.bash_profile or ~/.bash_login on the remote machine?
– steeldriver
Mar 21 at 22:05












OK I read your question again and now I'm confused - are you expecting your local shell environment to be inherited by the remote shell when you start an SSH session?
– steeldriver
Mar 21 at 22:35




OK I read your question again and now I'm confused - are you expecting your local shell environment to be inherited by the remote shell when you start an SSH session?
– steeldriver
Mar 21 at 22:35












Yes and no. I'm trying to use openmpi via a proprietary software. I need SSH to recognize $LOCAL_VARIABLE so openmpi works with the application I'm using (proprietary software). Customer support and I have narrowed the issue down to $LOCAL_VARIABLE (which is the path to the license file for the program) not being available via SSH. It doesn't matter to me if $LOCAL_VARIABLE is inherited by SSH, or if it is read (not sure "read" is the proper term) by SSH on the remote machine. Does this make it clearer?
– Markus Heller
Mar 21 at 22:43




Yes and no. I'm trying to use openmpi via a proprietary software. I need SSH to recognize $LOCAL_VARIABLE so openmpi works with the application I'm using (proprietary software). Customer support and I have narrowed the issue down to $LOCAL_VARIABLE (which is the path to the license file for the program) not being available via SSH. It doesn't matter to me if $LOCAL_VARIABLE is inherited by SSH, or if it is read (not sure "read" is the proper term) by SSH on the remote machine. Does this make it clearer?
– Markus Heller
Mar 21 at 22:43












Not for me - sorry. Unless you are asking something like this: When ssh'ing, how can I set an environment variable on the server that changes from session to session?
– steeldriver
Mar 21 at 23:04





Not for me - sorry. Unless you are asking something like this: When ssh'ing, how can I set an environment variable on the server that changes from session to session?
– steeldriver
Mar 21 at 23:04











1 Answer
1






active

oldest

votes

















up vote
1
down vote



accepted










Bash reads .profile* when run as an interactive login shell. When a command is given for execution, or when running a script, it is non-interactive unless you give the -i option, and non-login unless you give the -l option, etc. Neither of this is usually possible when executing commands via SSH.



Bash does read .bashrc when run non-interactively by SSH. However, the default .bashrc includes a check for interactive use:



# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac


So effectively, no variable set in .profile or .bashrc is available when you do ssh foo some-command. You can put the variables in .bashrc before the check for interactive execution. For example:



$ head ~/.bashrc
echo foo
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
$ ssh localhost env
foo
LC_MEASUREMENT=en_GB.UTF-8
SSH_CONNECTION=127.0.0.1 46916 127.0.0.1 22
LC_PAPER=en_GB.UTF-8
LC_MONETARY=en_GB.UTF-8
LANG=en_GB.UTF-8
LC_NAME=en_GB.UTF-8
XDG_SESSION_ID=155
USER=muru
...


The echo foo was executed. If I had export foo=bar, then foo would have showed up in the env output.



* with suitable caveats about the presence of files like .bash_profile, etc.






share|improve this answer




















  • This is the correct answer, thank you very much. Just for others who run into the same problem: in my .bashrc, the check for interactive execution looks like this: [ -z "$PS1" ] && return.
    – Markus Heller
    Mar 22 at 17:52










Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "89"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1018072%2fssh-ignores-variables-in-profile-files%23new-answer', 'question_page');

);

Post as a guest






























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
1
down vote



accepted










Bash reads .profile* when run as an interactive login shell. When a command is given for execution, or when running a script, it is non-interactive unless you give the -i option, and non-login unless you give the -l option, etc. Neither of this is usually possible when executing commands via SSH.



Bash does read .bashrc when run non-interactively by SSH. However, the default .bashrc includes a check for interactive use:



# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac


So effectively, no variable set in .profile or .bashrc is available when you do ssh foo some-command. You can put the variables in .bashrc before the check for interactive execution. For example:



$ head ~/.bashrc
echo foo
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
$ ssh localhost env
foo
LC_MEASUREMENT=en_GB.UTF-8
SSH_CONNECTION=127.0.0.1 46916 127.0.0.1 22
LC_PAPER=en_GB.UTF-8
LC_MONETARY=en_GB.UTF-8
LANG=en_GB.UTF-8
LC_NAME=en_GB.UTF-8
XDG_SESSION_ID=155
USER=muru
...


The echo foo was executed. If I had export foo=bar, then foo would have showed up in the env output.



* with suitable caveats about the presence of files like .bash_profile, etc.






share|improve this answer




















  • This is the correct answer, thank you very much. Just for others who run into the same problem: in my .bashrc, the check for interactive execution looks like this: [ -z "$PS1" ] && return.
    – Markus Heller
    Mar 22 at 17:52














up vote
1
down vote



accepted










Bash reads .profile* when run as an interactive login shell. When a command is given for execution, or when running a script, it is non-interactive unless you give the -i option, and non-login unless you give the -l option, etc. Neither of this is usually possible when executing commands via SSH.



Bash does read .bashrc when run non-interactively by SSH. However, the default .bashrc includes a check for interactive use:



# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac


So effectively, no variable set in .profile or .bashrc is available when you do ssh foo some-command. You can put the variables in .bashrc before the check for interactive execution. For example:



$ head ~/.bashrc
echo foo
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
$ ssh localhost env
foo
LC_MEASUREMENT=en_GB.UTF-8
SSH_CONNECTION=127.0.0.1 46916 127.0.0.1 22
LC_PAPER=en_GB.UTF-8
LC_MONETARY=en_GB.UTF-8
LANG=en_GB.UTF-8
LC_NAME=en_GB.UTF-8
XDG_SESSION_ID=155
USER=muru
...


The echo foo was executed. If I had export foo=bar, then foo would have showed up in the env output.



* with suitable caveats about the presence of files like .bash_profile, etc.






share|improve this answer




















  • This is the correct answer, thank you very much. Just for others who run into the same problem: in my .bashrc, the check for interactive execution looks like this: [ -z "$PS1" ] && return.
    – Markus Heller
    Mar 22 at 17:52












up vote
1
down vote



accepted







up vote
1
down vote



accepted






Bash reads .profile* when run as an interactive login shell. When a command is given for execution, or when running a script, it is non-interactive unless you give the -i option, and non-login unless you give the -l option, etc. Neither of this is usually possible when executing commands via SSH.



Bash does read .bashrc when run non-interactively by SSH. However, the default .bashrc includes a check for interactive use:



# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac


So effectively, no variable set in .profile or .bashrc is available when you do ssh foo some-command. You can put the variables in .bashrc before the check for interactive execution. For example:



$ head ~/.bashrc
echo foo
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
$ ssh localhost env
foo
LC_MEASUREMENT=en_GB.UTF-8
SSH_CONNECTION=127.0.0.1 46916 127.0.0.1 22
LC_PAPER=en_GB.UTF-8
LC_MONETARY=en_GB.UTF-8
LANG=en_GB.UTF-8
LC_NAME=en_GB.UTF-8
XDG_SESSION_ID=155
USER=muru
...


The echo foo was executed. If I had export foo=bar, then foo would have showed up in the env output.



* with suitable caveats about the presence of files like .bash_profile, etc.






share|improve this answer












Bash reads .profile* when run as an interactive login shell. When a command is given for execution, or when running a script, it is non-interactive unless you give the -i option, and non-login unless you give the -l option, etc. Neither of this is usually possible when executing commands via SSH.



Bash does read .bashrc when run non-interactively by SSH. However, the default .bashrc includes a check for interactive use:



# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac


So effectively, no variable set in .profile or .bashrc is available when you do ssh foo some-command. You can put the variables in .bashrc before the check for interactive execution. For example:



$ head ~/.bashrc
echo foo
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
$ ssh localhost env
foo
LC_MEASUREMENT=en_GB.UTF-8
SSH_CONNECTION=127.0.0.1 46916 127.0.0.1 22
LC_PAPER=en_GB.UTF-8
LC_MONETARY=en_GB.UTF-8
LANG=en_GB.UTF-8
LC_NAME=en_GB.UTF-8
XDG_SESSION_ID=155
USER=muru
...


The echo foo was executed. If I had export foo=bar, then foo would have showed up in the env output.



* with suitable caveats about the presence of files like .bash_profile, etc.







share|improve this answer












share|improve this answer



share|improve this answer










answered Mar 22 at 1:45









muru

130k19273463




130k19273463











  • This is the correct answer, thank you very much. Just for others who run into the same problem: in my .bashrc, the check for interactive execution looks like this: [ -z "$PS1" ] && return.
    – Markus Heller
    Mar 22 at 17:52
















  • This is the correct answer, thank you very much. Just for others who run into the same problem: in my .bashrc, the check for interactive execution looks like this: [ -z "$PS1" ] && return.
    – Markus Heller
    Mar 22 at 17:52















This is the correct answer, thank you very much. Just for others who run into the same problem: in my .bashrc, the check for interactive execution looks like this: [ -z "$PS1" ] && return.
– Markus Heller
Mar 22 at 17:52




This is the correct answer, thank you very much. Just for others who run into the same problem: in my .bashrc, the check for interactive execution looks like this: [ -z "$PS1" ] && return.
– Markus Heller
Mar 22 at 17:52

















 

draft saved


draft discarded















































 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1018072%2fssh-ignores-variables-in-profile-files%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

Which professions warranted travel in Medieval times?

How do so many people here on Academia.SE, and in general, afford lavish higher education programs?

Trouble downloading packages list due to a “Hash sum mismatch” error