For years I have had a problem with the "Setting locales failed". I now understood the problem. On my local machine, my LC_TIME is set to a custom file ("custom.UTF-8"). This custom file does not exist on any remote machine I connect to. However, through SSH my locale setting is 'exported' and searched for at the remote machine. So that is why I keep getting:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_TIME = "custom.UTF-8",
LANG = "en_US.UTF-8"
What I want to configure is that the local LC_TIME (or any locale variable) is never exported. I am fine just using the value defined at the remote machine. How should I define this?
Best Answer
The easiest way to prevent "exporting" the environment is to overwrite them on the server side. Create a
.bashrc
file (or the appropriate initialization file for your shell) and overwrite the variables.example: minimal
.bashrc
filealternatively, set the variable to some sane value:
If you really want to prevent sending some environment variables then you will most likely need root access on the client and/or the server machine.
On the client side you can edit
/etc/ssh/ssh_config
and remove or alter theSendEnv
line. Most distributions today have that set up to send the locale environment variables (LC_*
). As user you can only append to this list, not overwrite. That is why you can only disable this option when you have root access to the machine.Alternatively, on the server side you can edit
/etc/ssh/sshd_config
and remove or alter theAcceptEnv
line. Most distributions today have that set up to accept the locale environment variables (LC_*
).Look up the explanations for
SendEnv
in the man page for ssh_config andAcceptEnv
in the man page for sshd_config.For the sake of completeness: there is also a
PermitUserEnvironment
insshd_config
. As the name says, it allows the user to set up some files which will initialize some variables. IfPermitUserEnvironment
is enabled you can take care of the rest as user, but I have never encountered a system withPermitUserEnvironment
enabled.