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

pylint3 and pip3 broken

Missing snmpget and snmpwalk

How to enroll fingerprints to Ubuntu 17.10 with VFS491