I try to start some command from ssh non-interactive ssh connection. I use ant-sshexec connection for that.
In order to set everything up I used this article:
http://www.raphink.info/2008/09/forcing-environment-in-ssh.html
I use ~/.ssh/environment.
In order to do that, I set PermitUserEnvironment to "yes" in sshd_config and restarted sshd.
In my .ssh/environment I have this content:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/ubuntu/java/jdk1.6.0_27/bin
JAVA_HOME=/home/ubuntu/java/jdk1.6.0_27
#PATH=/home/ubuntu/java/jdk1.6.0_27/bin:$PATH
#PLAY_HOME=/home/ubuntu/play
and I have the error when try to connect using non-interactive connection:
[sshexec] Could not execute the java executable, please make sure the JAVA_HOME environment variable is set properly (the java executable should reside at JAVA_HOME/bin/java).
But I added the java to the path..
The man page for sshd(8) says this about ~/.ssh/environment:
It can only contain empty lines, comment lines (that start with
‘#’), and assignment lines of the form name=value.
That is, it is not a shell script at all. You have double quotes, variable expansion and an alias definition. None of that will work. Try this:
PATH=/home/ubuntu/java/jdk1.6.0_27/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
JAVA_HOME=/home/ubuntu/java/jdk1.6.0_27
PLAY_HOME=/home/ubuntu/play
Also ensure that the permissions on the ~/.ssh/environment are as described in the man page — no group or other write permissions on the file.
If you are concerned with locking yourself out of the account with a broken environment, test by logging onto the host first and running test commands such like this:
ssh localhost 'echo $JAVA_HOME'
You can ensure that the environment variables are set as you expect them and if something goes wrong, you are still logged onto the host allowing you to reverse your changes.
You used multiple environement variable for path . But don't export from command what i see.
You should do it like that way.
export PATH="A"
export PATH="$PATH:B"
export PATH="$PATH:C"
Also you can get this type of help from there.
So please post it to unix.
https://unix.stackexchange.com/questions/12391/how-to-run-my-c-program-from-anywhere-within-the-system-ubuntu-10-10
Hope it helps.
Related
I am trying to setup svn over ssh on an OS X server. In order to do so, I read that I need a wrapper to set umask and - in my case - to set the repository root. A quick and dirty way to do that is to rename /usr/bin/svnserve and place a wrapper script at that location. However SIP protects that location from any changes, and I would prefer a cleaner solution anyway.
So I created a wrapper script at /usr/local/bin/svnserve and created /etc/ssh/sshrc with
PATH=/usr/local/bin:$PATH
I have verified that this file gets executed when initiating a remote ssh command from my client by writing to a log file. However, the modified PATH does not seem to get passed to the command environment:
ssh hostname 'echo $PATH'
Password:
/usr/bin:/bin:/usr/sbin:/sbin
Am I overlooking something? Or is /etc/ssh/sshrc the wrong place to set a path? If so, what's the right place?
Other places I've tried: /etc/profile and /etc/bashrc, but none of these seem to get executed in connection with an ssh command.
Note: It is not an option to change the client behavior (like, for example, adding the desired path to the command).
/etc/sshrc does not run in the same shell instance with the remotely-issued command, so the PATH update does not persist through.
Some of the available options:
You can set AcceptEnv PATH on the server to configure it to accept a PATH sent by the remote system, and SendEnv PATH on the client (in ~/.ssh/config, or as an argument to ssh passed with -o, or in /etc/ssh/ssh_config).
In /etc/ssh/sshd_config on the server, you can set the option PermitUserEnvironment to yes; with that done, the variable and value can be added to ~/.ssh/environment in the individual user's account on the server.
You can use ForceCommand to override the remotely requested command, either with something like /usr/bin/env PATH=/usr/local/bin:/usr/bin:/bin svnserve or simply /usr/local/bin/svnserve
I'm on Ubuntu 16.10,
When running in terminal:
env | grep proxy
I get:
https_proxy=https://127.0.0.1:8888/
http_proxy=http://127.0.0.1:8888/
I can't find who sets these environment variables.
I've tried all the answers here and could not find anything.
Tried different shells / terminals. Variables are always there.
Any idea what else can it be?
No luck in checking all the usual suspects? Then it's time to use the big gun:
find /etc $HOME /usr/local -type f | xargs grep -E 'https?_proxy'
Run this as root. Add directories to your liking.
An environment variable in your current shell can only be set in the parent process, or in a file sourced by your shell. I would start by turning on the shell trace in the respective rc-files which are sourced when you log in, in your home directory. This is also the place where I would verify whether the environment variables is already set at this point (which would mean that it was set by the global initialization process, for instance in the rc files which reside in /etc). Now log in and check the output.
If the environment variable is already set initially, you can't do much except bugging your admin that he should remove it (which probably won't work). If it is not set initially, you need to look through the output of the shell trace, until you either find the point, where the variable is set, or where you see that some malicious script turns off the trace.
Since you didn't give any information, which shell you are using, I can't go into deeper detail.
In my case those env variables were set by Fiddler web debugger and I was able to remove them manually by editing ~/.bashrc file. There are 2 lines with export http(s)_proxy... located at the end of this file. Hope that it helps!
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).
I am unable to run a remote shell script located on "admin" server with arguments.
ssh koliwada#admin "~/bin/addautomaps $groupentry $homeentry $ticket"
"groupentry" and "homeentry" are as follows
user1:*:52940:OWNER-user1
user1 -rw,intr,hard,rsize=32768,wsize=32768 basinas01:/ifs/basinas01/home/&
the script is located at ~/bin/addautomaps in admin server.
I see the error,
tput: No value for $TERM and no -T specified
I also see the arguments also are not passed correctly.
I also tried using "ssh -t ..." but that doesnt work.
Answering your questions in reverse order (or most serious to least serious).
Your problem with the arguments (with spaces) not being passed correctly is that while you are quoting the command string locally you aren't quoting them when they are actually run by the remote machine.
That is you are generating a single string with the variables expanded but nothing tells the remote system not to split the expanded values on spaces.
The fix for that is that you need to quote the arguments inside the command for the remote shell as well as the entire string for ssh.
My answer here might help explain some (it is a similar issue).
The tput "issue" is likely just a warning that you can probably ignore if you don't care about the colorized/stylized/etc. output that tput is likely being used to create. You could also try forcing a value for $TERM on the remote side like ssh ... "export TERM=dumb; ..." or something like that to silence it.
I have tried exporting my paths and variables and crontab still will not run my script. I'm sure I am doing something wrong.
I have a shell script which runs a jar file. This is not working correctly.
After reading around I have read this is commonly due to incorrect paths due to cron running via its own shell instance and therefore does not have the same preferences setup as my profile does.
Here is what my script looks like today after several modifications:
#!/bin/bash --
. /root/.bash_profile
/usr/bin/java -jar Pharmagistics_auto.jar -o
...
those are the most important pieces of the script, the rest are straightforward shell based.
Can someone tell me what I am doing wrong?
Try specifying the full path to the jar file:
/usr/bin/java -jar /path/to/Pharmagistics_auto.jar -o
I would just tell you what you have already ruled out: Check your path and environment.
Since you have alredy done this, start debugging. Like write checkpoints into a logfile to see how far your script gets (if even started at all), check the cronjob log file for errors, check your mail (cron sends mails on errors) and so on ...
Not very specific, sorry.
"exporting my paths and variables" won't work since crontab runs in a different shell by a different user.
Also, not sure if this is a typo in how you entered the question, but I see:
usr/bin/java
...and I can't help but notice you're not specifying the fully qualified path. It's looking for a directory named "usr" in the current working directory. Oft times for crontab, the cwd is undefined, hence your reference goes nowhere.
Try specifying the full path from root, like so:
/usr/bin/java
Or, if you want to see an example of relative pathing in action, you could also try:
cd /
usr/bin/java
A few thoughts.
Remove the -- after the #!/bin/bash
Make sure to direct script output seen by cron to mail or somewhere else where you can view it (e.g. MAILTO=desiredUser)
Confirm that your script is running and not blocked by a different long-running script (e.g. on the second line, add touch /tmp/MY_SCRIPT_RAN && exit)
Debug the script using set -x and set -v once you know it's actually running
Do you define necessary paths and env vars in your personal .profile (or other script)? Have you tried sourcing that particular file (or is that what you're doing already with /root/.bash_profile?)
Another way of asking this is: are you certain that whatever necessary paths and env vars you expect are actually available?
If nothing else, have you tried echo'ing individual values or just using the "env" command in your script and then reviewing the stdout?
provide full paths to your jar file, and what user are you running the crontab in? If you set it up for a normal user, do you think that user has permission to source the root's profile?