How not to pass the locale through an ssh connection command

Question

I have some aliases for ssh, example:

alias buildWork="ssh work '~/build_app'"

The problem is that the ssh command passes some variables like $LC_CTYPE that causes some errors.

How to prevent that and use the server configurations ?

I don't have a way to test, but `( unset LC_CTYPE ; ssh ..... ) ` might work. This will temporarily unset LC_CTYPE in a sub-shell (the `(...)`) and then run your `ssh ....`command. Good luck. — shellter, Apr 13 '15 at 15:46

Tom Fenech · Accepted Answer · 2016-11-23T14:20:16.357

It sounds like your SSH client is configured to forward the locale settings. You can prevent this by altering your configuration (the global file is typically /etc/ssh/ssh_config):

# comment out / remove the following line
SendEnv LANG LC_*

Alternatively you can change the configuration of the server, by editing /etc/ssh/sshd_config on the remote machine (note the d in sshd_config):

# comment out / remove the following line
AcceptEnv LANG LC_*

Xoozee · Answer 2 · 2020-09-24T12:09:45.357

16

As already explained in other answers, the client will send all environment variables specified via SendEnv in /etc/ssh/ssh_config. You can also force ssh to not send already defined variable names, using your user's configuration.

From OpenSSH man page:

It is possible to clear previously set SendEnv variable names by prefixing patterns with -. The default is not to send any environment variables.

So, to prevent sending your locale, you can put the following into your ~/.ssh/config:

SendEnv -LC_* -LANG*

edited Sep 24 '20 at 12:09

answered Sep 17 '20 at 09:27

Xoozee

370
2
9

4

This seems like the cleanest answer, but I can't get it to work. – xdhmoore Oct 17 '20 at 03:11
4

I finally found this as the reason it didn't work for me. They closed the issue but they didn't really solve the problem AFAICT: https://bugzilla.mindrot.org/show_bug.cgi?id=1285 – xdhmoore Oct 17 '20 at 03:48
2

This is completely bonkers. Debian, and derivatives such as Ubuntu, used to set `SendEnv` in a way regular users can't prevent - only `root` can change that. Clearly a bug. [This was reported in 2010, fixed in 2018](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573316), and the fix still hasn't reached our Ubuntu 18.04 systems as of today (they run openssh 7.6p1). So the actual fix is to upgrade to a newer Debian or Debian-based release - then this answer will work. – reinierpost Apr 09 '21 at 18:47
3

Does not work on Ubuntu 20.04, I reverted to SetEnv instead. – Willem Feb 16 '22 at 19:26
3

@reinierpost: I'm afraid upgrading won't solve the problem. As the default `/etc/ssh/ssh_config` in Debian contains `SendEnv LC_* LANG*`, and it is read *after* `~/.ssh/config`, you'd be basically "unmarking" vars that were not yet marked for sending. `SetEnv` might work, but it requires you to clear all your `LC_`* and both `LANG`*, as it does not accept wildcards by definition. – MestreLion Jul 04 '22 at 01:25
Why? I use a wrapper script `lclessly` that does just that, but it shouldn't be necessary. – reinierpost Jul 04 '22 at 07:55
2

This **does not work**, you can't "unset" the global `SendEnv` because `/etc/ssh/ssh_config` is applied *after* user config. – rustyx Dec 04 '22 at 12:18

score 15 · Answer 3 · edited Apr 13 '17 at 12:22

15

In short:

$ touch ~/.ssh/config
$ ssh -F ~/.ssh/config your_user@your_host

See this answer for details.

edited Apr 13 '17 at 12:22

Community

1
1

answered Jan 22 '17 at 03:18

Rockallite

16,437
7
54
48

1

That one did the trick. question is why is not taking the user configuration but the global one? – crsuarezf Jan 18 '18 at 20:18
3

@crsuarezf is it taking the user configuration, but if you don't use `-F`, it *also* takes the global configuration, instead of ignoring it completely. From the [man page](https://man.openbsd.org/ssh): `If a configuration file is given on the command line, the system-wide configuration file (/etc/ssh/ssh_config) will be ignored` – André Paramés Mar 12 '18 at 08:28
1

I already had an `~/.ssh/config` file, so all this does is update the time on that file. And the unrecognized local variables are still passed through to the host. At least now I have something to look for in the `man` page. – Vince Jan 27 '21 at 23:40
@Vince the reason that this works is the -F option. It forces ssh to not use the system-wide config. This is most often the file that contains a setting like "Host \*\n. SendEnv LANG LC_*" – Douwe van der Leest Jul 28 '21 at 13:16
1

To not type that every time you could create an alias: `alias ssh='ssh -F ~/.ssh/config $@'` – cstoll Dec 12 '22 at 15:32

score 5 · Answer 4 · answered Nov 24 '17 at 19:01

5

Accepted answer is correct, but, if you don't want to change your config files, you can override specific locale on the command line

LC_TIME="en_US.UTF-8" ssh user@example.com

answered Nov 24 '17 at 19:01

LMC

10,453
2
27
52

This doesn't work for me. I use `LC_ALL="en_US.UTF-8" ssh xxx@xxxx` instead. – VincentHuang Sep 03 '21 at 12:34

score 0 · Answer 5 · answered May 21 '20 at 19:52

I was facing the issue that I attributed to ssh passing the locale settings, so I tried with disabling it on client site, then on server site as well (as advised above) and still the locale was complaining after logging in.

Turned out to be a messy locale on the destination server itself, where the setting was taken from /etc/default/locale

I had to clean it completely, run # dpkg-reconfigure locales which fixed the issue.

score -3 · Answer 6 · answered Apr 27 '22 at 01:04

-3

To not send our Local Environment (SendEnv) which is the default behaviour since it is specified in /etc/ssh/ssh_config you have to:

Create a config file for your user ~/.ssh/config
Add these lines

Host *
   SendEnv !LANG !LC_*

Reload your shell sudo su - $YourSelf (or logout/login)

a bit of explanation

! == means not
* == means all

so

!LANG == don't send the variable LANG
!LC_* == dont send all variable started with LC_

source: https://bugzilla.mindrot.org/show_bug.cgi?id=1285#c8

Remember that not everyone with this issue will have the power of editing /etc/ssh/ssh_config

answered Apr 27 '22 at 01:04

JOduMonT

41
3

2

Have you actually tested this? By reading the very bug report you cited as source, this `!PATTERN` seems to be just a patch that was never accepted/merged. – MestreLion Jul 03 '22 at 23:40
@MestreLion is right, this answer is wrong. – Tamás Zahola Sep 04 '22 at 12:34

score -6 · Answer 7 · answered Sep 22 '17 at 11:40

   To stop sending Environment Variables via sftp 
   Tested on CENTOS 7
 - create file config in ~/xyzuser/.ssh/config
 - set permission to 600 ~/xyzuser/.ssh/config
 - Put the following content in the file

   comment the below lines commented to disable env variables#########

 - Send locale-related environment variables
        SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY 
       SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE
       SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE
       SendEnv XMODIFIERS

  Running without the ~/xyzuser/.ssh/config
   sftp -v   xyzuser@destinationhost
     -------------------truncated output--------
     debug1: Requesting no-more-sessions@openssh.com
     debug1: Entering interactive session.
     debug1: Sending environment.
     debug1: Sending env LANG = en_US.UTF-8
     debug1: Sending subsystem: sftp

  Running with the ~/xyzuser/.ssh/config

    sftp -v -F /home/xyzuser/.ssh/config  xyzuser@destinationhost

     ----truncated----------
     debug1: channel 0: new [client-session]
     debug1: Requesting no-more-sessions@openssh.com
     debug1: Entering interactive session.
     debug1: Sending subsystem: sftp
     Connected to destinationhost

Please actually try to answer the question instead of copy-pasting. — iceman, Sep 22 '17 at 11:52

How not to pass the locale through an ssh connection command

7 Answers7

a bit of explanation

so

Linked