I have two servers X(host) and Y(remote). A script abc.sh is saved on Y server. I am running abc.sh from server X using ssh command.
Script is running successfully but the commands which contain the environment variables(kept in /.bash_profile) of server Y are giving blank output.
When I am running abc.sh from server Y itself, all commands running successfully.
My question is how to include the environment variables of remote server(Y) so that full script will execute successfully.
NOTE : I don't have write access to etc directory so I can't change anything in it.
Thanks in advance!
You can include your environment variables like following:
ssh user#host_y 'source ~/.bash_profile; /path/to/your/script/abc.sh'
Since direct command run is not an interactive shell, your variable will not work there. source will run script in your current shell and make visible environment variables in that file to your script.
I run some cron jobs using ssh connect a remote machine. The code can't load all the environment variables. It works if I run the code in that machine.
I tried several ways that doesn't work for me.
Finally, I comment below lines in the ~/.bashrc file. It works for me.
# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
The ssh connect open an no-interactive shell. So it will load the environment variables for an non-interactive shell if you comment or delete this block codes.
Alternatively, you can just put all of your required environment lines code above that line.
Related
I need to run SSH on Linux and execute commands from a local file into the remote machine. This is working fine, but I also need to pass local environment variables to the remote machine, so the commands can use the values.
Here is the command I'm running:
ssh -i ${SSH_PRIV_KEY} ${SSH_USER}#${IP} < setup.sh
I have a bunch of environment variables set and when the remote machine runs the commands in setup.sh file it needs be able to use the env vars from the local machine.
I tried many things, this but solutions from other threads like this don't work correctly:
myVar='4.0.23'
export $myVar
ssh -i ${SSH_PRIV_KEY} ${SSH_USER}#${IP} myVar=myVar < setup.sh
Only thing I can come up with is to append the start of the file and hardcode the values there before executing ssh, but if possible I would like to find a cleaner solution because I want this to be reusable and the only thing that changes for me between runs is the env vars.
I ended up using this code to get the env vars I need to be stored in a file, then combine the files into one and pass that to the ssh as command:
envvars="
envvar='$envvar'
envvar2='$envvar2'
"
echo $envvars > envfile
cat envfile setup.sh > finalScript
cat $()
ssh -i ${SSH_PRIV_KEY} ${SSH_USER}#${IP} < finalScript
I couldnt find answer to this althougth there are many similar questions.I wanted to change colour of my linux command prompt based on the remote host i have ssh to.Since bash environment variables are not preserved over ssh,so how could i do this.There are hundreds of server i login everyday.So changing /.bashrc of each remote host is not possible.is there a way i can pullout a script which can be called each time ssh is done.Can someone please give in detail of which file and how it should be edited.gnome,openssh etc are not supprted.
during ssh execution,a new login shell was executed.
during shell login the *rc files are not executed,only *profile was executed.
so place your code in /etc/profile or ~/.bash_profile.
"Since bash environment variables are not preserved over ssh..."
man ssh
Additionally, ssh reads ~/.ssh/environment, and adds lines of the format
“VARNAME=value” to the environment if the file exists and users are
allowed to change their environment. For more information, see the
PermitUserEnvironment option in sshd_config(5).
No where online can i find a way to run a shell script on a remote server from another script. This is for automation, so the script on the host machine will automatically trigger another script on a different server. The server that my script will ssh to will either have a password prompt or have RSA key pair set up
Thanks!
Just pass the command as an argument to ssh.
ssh someserver /path/to/some/script.bsh
Let's say you want to execute a script on node2 but you have your script on node1 file name of script is sp over location /home/user/sp. Simply
ssh node2 < /path-of-the-script-including-the-filename
Another way, using expect package.
Disclaimer: This you can use for testing environments since it has an
open password. but depends on your usecase
If your server does not have expect, you may add the package then. run the command. You can also put this command inside an .sh script.
expect -c 'spawn ssh user#10.11.12.13 "/path/to/my.sh"; expect "assword:"; send "Y0urp#ssw0rd\r"; interact'
I have two following commands which I manually run when I connect on my VPS:
eval ssh-agent $SHELL
ssh-add /home/duvdevan/.ssh/id_rsa
I tried adding them into a ssh.sh and run it within that directory using:
./ssh.sh
But nothing happends.
I'm not that bash-savvy so any help is appreciated.
Instead of running, you need to source the script:
. ./ssh.sh
Otherwise, the environment variables set by the eval command will not be visible in your current shell, and so it cannot know where to find the running ssh agent.
To give a bit more background, here's how this works:
the ssh-agent command starts an ssh agent, and prints to stdout the environment variables you need to set to connect to the agent. The output is formatted as commands to execute. For a test, you can just run this command and see what it prints
the eval command executes the commands printed by ssh-agent. As mentioned earlier, these are commands to set environment variables. After these are executed, the ssh commands you will run in this shell will know where to find the agent
the ssh-add command is able to find the agent, thanks to the environment variables set earlier
these variables are set until the script exits. When you run ./ssh.sh, the variables are set inside the process of that script, and longer available after the script is finished
by sourcing the ssh.sh script using ., the commands inside will be executed in the current shell, and therefore the environment variables are still set, and so your ssh related command can find the agent
I'm trying to interactively test code before I put it into a script and was wondering if there are any things that behave differently in a script?
When you execute a script it has its own environment variables which are inherited from the parent process (the shell from which you executed the command). Only exported variables will be visible to the child script.
More information:
http://en.wikipedia.org/wiki/Environment_variable
http://www.kingcomputerservices.com/unix_101/understanding_unix_shells_and_environment_variables.htm
By the way, if you want your script to run in the same environment as the shell it is executed in, you can do it with the point command:
. script.sh
This will avoid creating a new process for you shell script.
A script runs in exactly the same way as if you typed the content in at a shell prompt. Even loops and if statements can be typed in at the shell prompt. The shell will keep asking for more until it has a complete statement to execute.
As David rightly pointed out, watch out for environment variables.
Depending on how you intend to launch your script, variables set in .profile and .bashrc may not be available. This is subject to whether the script is launched in interactive mode and whether it was a login shell. See Quick Startup File Reference.
A common problem I see is scripts that work when run from the shell but fail when run from another application (cron, nagios, buildbot, etc.) because $PATH was not set.
To test if a command/script would work in a clean session, you can login using:
ssh -t localhost "/bin/bash --noprofile --norc"
This ensures that we don't inherit any exported variables from the parent shell, and nothing from .profile or .rc.
If it works in a clean session and none of you're commands expect to be in interactive mode, then you're good to go!