ssh to arch system doesn't set LANG

xnor · 2019-09-15 19:05:32

Hello,

you can test this on your own system, if you have arch running (without SendEnv/AcceptEnv):

$ ssh myuser@localhost locale
LANG=
...

This is even though /etc/locale.conf has LANG=en_US.UTF-8.

I tracked this down to pam.d:
If one replaces

session    required

with

session    required   pam_env.so readenv=1 envfile=/etc/locale.conf

then LANG will be set.

There's no mention of this on the wiki entry on locale or openssh.

I've also compared to a debian system, and there the bash shell that is being executed reads /etc/bash.bashrc while on arch it does not.
Why?

Last edited by xnor (2019-09-15 22:05:42)

loqs · 2019-09-15 19:33:54

Bash#Configuration_files
It is expected that /etc/profile will be sourced which will source /etc/profile.d/locale.sh

Last edited by loqs (2019-09-15 19:34:07)

xnor · 2019-09-15 20:12:45

loqs wrote:

Bash#Configuration_files
It is expected that /etc/profile will be sourced which will source /etc/profile.d/locale.sh

Note that in the case explained above it is execute as

bash -c <command>

.
So it is not a login shell, so no profile file will be sourced.
It is also not interactive, obviously.

jasonwryan · 2019-09-15 20:36:47

Can't replicate on any of my Arch boxes:

┌─[Centurion ~: «SSH»]
└─╼ locale
LANG=en_NZ.utf8
LC_CTYPE="en_NZ.utf8"
LC_NUMERIC="en_NZ.utf8"
LC_TIME="en_NZ.utf8"
LC_COLLATE=C
LC_MONETARY="en_NZ.utf8"
LC_MESSAGES="en_NZ.utf8"
LC_PAPER="en_NZ.utf8"
LC_NAME="en_NZ.utf8"
LC_ADDRESS="en_NZ.utf8"
LC_TELEPHONE="en_NZ.utf8"
LC_MEASUREMENT="en_NZ.utf8"
LC_IDENTIFICATION="en_NZ.utf8"
LC_ALL=

Moving to NC...

seth · 2019-09-15 20:38:51

I'm not entirely sure what the question is here, but ssh allows you to set environment variables as well as run a script (~/.ssh/environment & ~/.ssh/rc on the host) before executing commands (inc. login shells) and there's no reason to assume the environment would be set otherwise or the executing shell to source that config (as seen in the matrix on the wiki) though nb. that if bash can detect that it's invoked remotely, it'll source ~/.bashrc

If you want to know why debian behaves different my best guess is that the configs are explicitly sourced there either by ssh or the shell (so most likely the ~/.bashrc is the cause here)

@Jason, he's not testing that from a login shell but running "locale" as ssh command (and I don't think that your fancy prompt reflects that?)

xnor · 2019-09-15 20:56:39

jasonwryan wrote:

Can't replicate on any of my Arch boxes:

Did you run the command as I've posted in #1 and do you have /bin/bash as the user's login shell? I don't think so...

Last edited by xnor (2019-09-15 21:21:21)

xnor · 2019-09-15 21:10:37

seth wrote:

if bash can detect that it's invoked remotely, it'll source ~/.bashrc

I also read that in the bash manpage, but it doesn't seem to work?

seth wrote:

If you want to know why debian behaves different my best guess is that the configs are explicitly sourced there either by ssh or the shell (so most likely the ~/.bashrc is the cause here)

I've attached to sshd with strace and on Debian I can see that it immediately reads /etc/bash.bashrc and then /home/user/.bashrc before executing the command.

On Arch neither file is read.

loqs · 2019-09-15 21:20:02

@seth https://sources.debian.org/src/bash/5.0 … .diff/#L53

Last edited by loqs (2019-09-15 21:20:57)

xnor · 2019-09-15 21:25:24

loqs wrote:

@seth https://sources.debian.org/src/bash/5.0 … .diff/#L53

Thanks, that explains the difference in the Debian bash. Digging in the code, this not just loads ~/.bashrc but also the SYS_BASHRC.

xnor · 2019-09-15 21:29:26

As for LANG never being set, should I create a bug in the openssh package? Or pam?

Last edited by xnor (2019-09-15 21:30:32)

Swiggles · 2019-09-15 21:30:43

/etc/ssh/ssh_config

Host *
    SendEnv LANG LC_*

/etc/ssh/sshd_config

AcceptEnv LANG LC_*

Output:

➜ ssh localhost locale     
swiggles@localhost's password: 
LANG=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=

Ubuntu and I suspect Debian already contain these configs. Anyway, Arch requires you to setup the tools properly!

xnor · 2019-09-15 21:41:32

@Swiggles I'm well aware of SendEnv/AcceptEnv - should have mentioned it in #1 - but that just uses the clients LANG, not the one configured on the server / for the server's user.

Swiggles · 2019-09-15 22:45:22

The environment or pam is used for the other cases. When you read the man page of bash closely you notice that in this case no file is read or executed:

man bash wrote:

When bash is started non-interactively, to run a shell script, for example, it looks for the variable BASH_ENV in the environment, expands its value if it appears there, and uses
the expanded value as the name of a file to read and execute. Bash behaves as if the following command were executed:
if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi
but the value of the PATH variable is not used to search for the filename.
Bash attempts to determine when it is being run with its standard input connected to a network connection, [...]

Emphasis mine. Because this is the case (non-interactively, no standard input connected to a network connection) no bash(rc) and especially no profile file is run.
sshd itself only handles its own environment and rc files as described in its man page. Therefore the behavior is in line with the documentation.

The proper way to setup a command environment in ssh is via .ssh/environment. So I think pam_env is actually the correct way to set this up if PermitUserEnvironment is not wanted.

My conclusion is that debian is doing it actually wrong (italic!) by adding this behavior in their ssh package.

Anyway, this topic is a lot more interesting than I thought at first.

Last edited by Swiggles (2019-09-15 22:51:53)

loqs · 2019-09-16 00:40:01

@Swiggles how would you implement the XDG path support /etc/profile.d/locale.sh implements using pam_env?

Swiggles · 2019-09-16 01:19:30

/etc/environment

LANG=C
# ...

$HOME/.pam_environment

LANG=en_US.utf8

Or ln -s $HOME/.config/locale.conf $HOME/.pam_environment

Assuming XDG_CONFIG_HOME is defined like this, but does not matter, we do not run anything!
/etc/security/pam_env.conf

XDG_CONFIG_HOME   DEFAULT=@{HOME}/.config

If you really need full feature parity pam_exec might be a solution, but there are some security related caveats.
Honestly I don't know what you are trying to achieve at this point. Do you have an actual use case?

loqs · 2019-09-16 01:28:30

xnor wrote:

I tracked this down to pam.d:
If one replaces
session    required 
with
session    required   pam_env.so readenv=1 envfile=/etc/locale.conf

That is in /etc/pam.d/system-login. Is that not where you are making the change?

xnor · 2019-09-16 18:55:22

loqs wrote:

That is in /etc/pam.d/system-login. Is that not where you are making the change?

Just appending that line to /etc/pam.d/sshd should do.

I think this is the best solution, as it doesn't require hardcoding LANG=... anywhere else besides /etc/locale.conf

What I find funny is that the issue went over the head of the mod that moved this to NC, and another member insinuated I don't know how to setup the system properly when both of them weren't even aware of the issues raised ... seemingly still aren't.
Topic can be closed, thanks for the help @loqs.

Last edited by xnor (2019-09-16 18:56:42)

Swiggles · 2019-09-16 19:11:20

I still stand by it that for all use-cases I can think of the AcceptEnv option is correct, especially when using ssh in scripts.
The "problem" is a custom quirk by debian added to the package and anything else can be found in the docs.

Anyway, great attitude. You know how to make people feel like they wasted their time on you.

ewaller · 2019-09-16 19:31:43

Closed. By request,

jasonwryan · 2019-09-16 19:36:22

xnor wrote:

What I find funny is that the issue went over the head of the mod that moved this to NC, and another member insinuated I don't know how to setup the system properly when both of them weren't even aware of the issues raised ... seemingly still aren't.

I did misinterpret your original post. But once it was pointed out to me I did understand, but I didn't care. There is a difference.

# edit: reopened for clarification

Last edited by jasonwryan (2019-09-16 20:23:20)

seth · 2019-09-17 07:11:22

The issue at hand is that arch behaves different from debian but actually neither is inherently "wrong".

From post #8 I'd say the difference is actually in bash rather than in ssh.
This puts the proposed solution into question because it would not create behavioral parity. Not only is questionable whether the locale environment (and only that) should be set at all, but if it's invoked through debians bash behavior, /etc/locale.conf might even be the wrong locale because it relates to the system and not the user.
Permitting the ssh user environment config or accepting vars from the client (depending on preference) seems a closer feature match but would also work regardless of the shell and (afaics) w/o having bashrc sourcing /etc/profile.

Because of the UTF-8 reliance (and maybe other environment vars) of certain programs this sounds like a worthwhile discussion for a global solution (despite only affecting non-interactive shells) and/or notably addressment in the wiki since, as indicated, I'm not certain there's actually a cookie-cutter solution to this.

Swiggles · 2019-09-17 15:03:38

You can actually set system and user files via pam_env. Since they are simple key=value files to set the environment you could reasonably just read the system locale and user locale. This is my proposed solution, but I referenced to the default files instead before:

session    required   pam_env.so readenv=1 envfile=/etc/locale.conf user_readenv=1 user_envfile=$HOME/.config/locale.conf

I don't know whether feature parity is required or not, because I do not understand the use case. Anyway it should be reasonable to write a wrapper for pam_exec in this case.
Why I care about the use case so much is because if your client expects some language it should request it from the server and not the other way around.

Arch Linux

#1 2019-09-15 19:05:32

ssh to arch system doesn't set LANG

#2 2019-09-15 19:33:54

Re: ssh to arch system doesn't set LANG

#3 2019-09-15 20:12:45

Re: ssh to arch system doesn't set LANG

#4 2019-09-15 20:36:47

Re: ssh to arch system doesn't set LANG

#5 2019-09-15 20:38:51

Re: ssh to arch system doesn't set LANG

#6 2019-09-15 20:56:39

Re: ssh to arch system doesn't set LANG

#7 2019-09-15 21:10:37

Re: ssh to arch system doesn't set LANG

#8 2019-09-15 21:20:02

Re: ssh to arch system doesn't set LANG

#9 2019-09-15 21:25:24

Re: ssh to arch system doesn't set LANG

#10 2019-09-15 21:29:26

Re: ssh to arch system doesn't set LANG

#11 2019-09-15 21:30:43

Re: ssh to arch system doesn't set LANG

#12 2019-09-15 21:41:32

Re: ssh to arch system doesn't set LANG

#13 2019-09-15 22:45:22

Re: ssh to arch system doesn't set LANG

#14 2019-09-16 00:40:01

Re: ssh to arch system doesn't set LANG

#15 2019-09-16 01:19:30

Re: ssh to arch system doesn't set LANG

#16 2019-09-16 01:28:30

Re: ssh to arch system doesn't set LANG

#17 2019-09-16 18:55:22

Re: ssh to arch system doesn't set LANG

#18 2019-09-16 19:11:20

Re: ssh to arch system doesn't set LANG

#19 2019-09-16 19:31:43

Re: ssh to arch system doesn't set LANG

#20 2019-09-16 19:36:22

Re: ssh to arch system doesn't set LANG

#21 2019-09-17 07:11:22

Re: ssh to arch system doesn't set LANG

#22 2019-09-17 15:03:38

Re: ssh to arch system doesn't set LANG

Board footer