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?


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 file

unset LC_TIME

alternatively, set the variable to some sane value:

export LC_TIME=en_US.UTF-8

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 the SendEnv 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 the AcceptEnv 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 and AcceptEnv in the man page for sshd_config.

For the sake of completeness: there is also a PermitUserEnvironment in sshd_config. As the name says, it allows the user to set up some files which will initialize some variables. If PermitUserEnvironment is enabled you can take care of the rest as user, but I have never encountered a system with PermitUserEnvironment enabled.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.