2

I have a target AIX 6.1 server where I need to execute a script.

The ~/.bashrc on my target server is configured to add a variable MACHINE=1

When I ssh the server and connect I effectively view the ~/.bashrc variables in my env:

[user@source ~]$ ssh user@10.10.10.10
[user@target]
$env |grep "MACHINE"
MACHINE=1
[user@target]
$

But when I execute directly the env command in the ssh the variable is not set:

[user@source ~]$ ssh user@10.10.10.10 "env" |grep MACHINE
[user@source ~]$

Is there something to configure more on the server?

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
Pilou
  • 1,398
  • 13
  • 24
  • What does `ssh user@10.10.10.10 "env"` print out. I mean without `grep` – Sakthi Kumar Jul 05 '13 at 13:30
  • It print a lot of variables exept the ones defined in ~/.bashrc – Pilou Jul 05 '13 at 13:31
  • 1
    This link also deals a similar problem http://stackoverflow.com/questions/1198378/ssh-command-execution-doesnt-consider-bashrc-bash-login-ssh-rc – Sakthi Kumar Jul 05 '13 at 13:33
  • As specified at http://mywiki.wooledge.org/DotFiles, behavior on non-login non-interactive shells is implementation-defined; there's a non-default compile-time option which enables sourcing of `~/.bashrc` on these systems, but whether it's enabled is under your OS vendor's control. – Charles Duffy Jul 05 '13 at 14:04

2 Answers2

2

ssh remote command execution happens in a non-interactive shell. As such, your ${HOME}/.bashrc, /etc/bashrc aren't read.

If you want ssh commands to read environment variables, add those to /etc/profile.

Alternatively, try hacks:

ssh user@10.10.10.10 'source ${HOME}/.bashrc; echo ${MACHINE}'
devnull
  • 118,548
  • 33
  • 236
  • 227
  • In reality I have an old target server who's working and there is nothing in /etc/profile, so I don't know how this old server is working. – Pilou Jul 05 '13 at 13:39
  • For the alternative I allready think on that but i can't because the ssh command is realized by an external program – Pilou Jul 05 '13 at 13:40
  • It doesn't even happen in a shell. After connecting, the remote `sshd` is executing an instance of `env`, not a shell. – chepner Jul 05 '13 at 13:40
  • Wouldn't `ssh user@10.10.10.10 "source ${HOME}/.bashrc; echo ${MACHINE}` work? – devnull Jul 05 '13 at 13:42
  • @chepner Would that it were. `sshd` doesn't `execve()` directly, but always invokes a shell. – Charles Duffy Jul 05 '13 at 13:44
  • Yes it works with escaped dollars. But i can't use this I have no hand on the ssh call. – Pilou Jul 05 '13 at 13:44
  • @devnull You'd need to use single quotes, not double quotes. – Charles Duffy Jul 05 '13 at 13:47
  • ...that is to say: `ssh user@10.10.10.10 'source ${HOME}/.bashrc; echo ${MACHINE}'` – Charles Duffy Jul 05 '13 at 13:48
  • @CharlesDuffy yes, thanks. prevent local shell from expanding! – devnull Jul 05 '13 at 13:49
  • @Pierre-LouisLaffont If the client is using double-quotes, then their shell is expanding the variables before the command is ever given to ssh, so the replacements are already done before the server sees it. If that's the problem, it's not something you can fix from the server side. – Charles Duffy Jul 05 '13 at 13:51
  • yes no problem with expanding shells, the problem is server side – Pilou Jul 05 '13 at 13:53
  • I need to execute a command on the server with a variable defined on the server. But executed remotely by a client I can't modify. There is allready working on an old server so it's possible (with the existing client command). I'm now looking on server conf a way to set variable when a command is executed directly by ssh. – Pilou Jul 05 '13 at 13:55
2

One option you have is to tell sshd to set the environment variables for you. In /etc/sshd_config:

PermitUserEnvironment yes

In ~/.ssh/environment:

MACHINE=1
Charles Duffy
  • 280,126
  • 43
  • 390
  • 441
  • In my config the `sshd_config` was not here but this solution worked as an alternative. That's doesn't explains how it worked on my old server but this solution might be cleaner. Thanks. – Pilou Jul 08 '13 at 15:29
  • 1
    @Pierre-LouisLaffont Some operating systems enable a non-default compile-time flag causing `.bashrc` to be sourced even on non-interactive, non-login shells. This may be why your old system worked. – Charles Duffy Jul 08 '13 at 20:09