Accordingly to ssh man page -o allows to set the content of a given ssh client option. I would like to unset SendEnv (or set it to empty) in order to avoid locale setup in server side.
I got the desired effect by commenting SendEnv line in ssh_config file. However, it is not a good option for my application.
How to achieve this when running ssh command? I tried ssh -o SendEnv='' server without success.
It is not possible to do that on the command-line. The SendEnv option does not overwrite, but append to the existing values.
But you can create a different configuration file, which will not have these options and use -F option, which will prevent using the global configuration file:
ssh -F /my/specific_ssh_config server
A bit late but maybe someone can still profit from my answer. According to 'man ssh_config' it is possible to clear SendEnv variables:
It is possible to clear previously set SendEnv variable names by prefixing patterns with -.
So you should basically be able to use your construct with
-o SendEnv=''
But instead of leaving the brackets empty you put the variables which you want to overwrite in the brackets but prefix each of them with a dash.
Or you specify the same in your users own ssh config (usually ~/.ssh/config). Wich if I understand the documentation correctly should also overwrite it.
Related
So i'm trying to move my neovim config over ssh automatically I do this using the following trick in my ssh config:
Host *
SendEnv LC_VIMINIT
RequestTTY yes
RemoteCommand export VIMINIT=$LC_VIMINIT
What I'm doing here is sending the content of the environment variable LC_VIMINIT over ssh and once it's content is moved into the VIMINIT environment variable.
In order to fill the content of LC_VIMINIT I have the following in my fish.config (fish shell)
set -gx LC_VIMINIT (cat ~/.config/nvim/init.vim)
When I connect through ssh and do echo $VIMINIT it works and contains my vim config! When starting neovim however my config is not loaded :(
If I do export VIMINIT='set number' and start neovim it shows line numbers and VIMINIT is properly loaded.
I'm not sure why it's not working, my current hypothesis is that (cat ~/.config/nvim/init.vim) removes the line breaks which causes neovim to ignore it's content?
Maybe someone more experienced can enlighten me?
Put the following in your .ssh/config:
Host *
SendEnv LC_VIMINIT
RequestTTY yes
RemoteCommand export VIMINIT=$LC_VIMINIT
Next put the following in ./config/fish/config.fish:
set -gx LC_VIMINIT (cat ~/.config/nvim/init.vim | grep -P -o '^.*(?=")|^[^"]+$' | awk '{if($1~/autocmd/){ print "execute \""$0"\""} else {print $0}}' | string collect)
What is happening here is that:
The content of ~/.config/nvim/init.vim is stripped from it's comments by grep.
Then each line starting with autcmd is wrapped in execute "<line>"
This is collected into a single string
The string is placed into the LC_VIMINIT environment variable (any LC_* environment variable can be send over ssh).
LC_VIMINIT is send over ssh when connecting to a host because of the setting SendEnv LC_VIMINIT.
Upon connecting to the host the variable VIMINIT is filled with the content of LC_VIMINIT because of RemoteCommand export VIMINIT=$LC_VIMINIT.
I don't think you're going to be able to do what you want. What my copy of Vim says is this:
The value of $VIMINIT is used as an Ex command line.
Notice the article "an". As I read it, you may pass a single command line, not multiple Ex command lines separated by newlines.
You could, of course, try to concatenate them with |, but that won't work for certain Ex commands.
I also don't think you can get a shell and executed a RemoteCommand at the same time, and even if you could, the RemoteCommand would probably be executed in a separate, non-interactive shell.
Most people just create a Git repository and sync their dotfiles that way, which is both easier and more elegant. Of course, that's inconvenient if you're working with many machines, but since I have a custom color scheme and a variety of additional plugins, I just deal with using the defaults in that case.
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 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 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.