Bug 22182

setup-2.2.11-alt1
openssh-server-5.0p1-alt3

When logging in via ssh from an environment with a different locale (the difference in charmap is important), the remote messages become unreadable, because of charmap mismatch.

It would be convenient, if on the remote end at least the charmap part of all the locale variables would be inherited from the source environment.

(ssh does pass the corresponding environment variables, so it's up to setup to use this information.)

Example:

[ivan@dell ~]$ locale
LANG=ru_RU.KOI8-R
LC_CTYPE="ru_RU.KOI8-R"
LC_NUMERIC="ru_RU.KOI8-R"
LC_TIME="ru_RU.KOI8-R"
LC_COLLATE="ru_RU.KOI8-R"
LC_MONETARY="ru_RU.KOI8-R"
LC_MESSAGES=POSIX
LC_PAPER="ru_RU.KOI8-R"
LC_NAME="ru_RU.KOI8-R"
LC_ADDRESS="ru_RU.KOI8-R"
LC_TELEPHONE="ru_RU.KOI8-R"
LC_MEASUREMENT="ru_RU.KOI8-R"
LC_IDENTIFICATION="ru_RU.KOI8-R"
LC_ALL=
[ivan@dell ~]$ ssh -v linux.local -l imz
OpenSSH_5.0p1, OpenSSL 0.9.8d 28 Sep 2006
debug1: Reading configuration data /home/ivan/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/openssh/ssh_config
debug1: Applying options for *
debug1: Connecting to linux.local [169.254.7.8] port 22.
debug1: Connection established.
debug1: identity file /home/ivan/.ssh/id_rsa type 1
debug1: identity file /home/ivan/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.0
debug1: match: OpenSSH_5.0 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.0
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes256-ctr hmac-md5 zlib@openssh.com
debug1: kex: client->server aes256-ctr hmac-md5 zlib@openssh.com
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<4096<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
The authenticity of host 'linux.local (169.254.7.8)' can't be established.
RSA key fingerprint is bd:4c:3c:40:24:04:8b:b4:b0:07:dd:ad:d9:06:ca:c3.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'linux.local' (RSA) to the list of known hosts.
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/ivan/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Offering public key: /home/ivan/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 817
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key '/home/ivan/.ssh/id_dsa': 
debug1: read PEM private key done: type DSA
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LC_MESSAGES = POSIX
debug1: Sending env LANG = ru_RU.KOI8-R
Last login: Tue Nov  3 12:24:32 2009 from localhost
[imz@localhost ~]$ date
п╖я┌п╡ п²п╬я▐  5 13:36:38 UTC 2009
[imz@localhost ~]$ locale
LANG=ru_RU.UTF-8
LC_CTYPE="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_TIME="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES=POSIX
LC_PAPER="ru_RU.UTF-8"
LC_NAME="ru_RU.UTF-8"
LC_ADDRESS="ru_RU.UTF-8"
LC_TELEPHONE="ru_RU.UTF-8"
LC_MEASUREMENT="ru_RU.UTF-8"
LC_IDENTIFICATION="ru_RU.UTF-8"
LC_ALL=
[imz@localhost ~]$ 

In this example, the printed date is not readable.

It would be more convenient, if the resulting locale had, say, LC_TIME="ru_RU.KOI8-R" -- so that the charmap part is overridden by "KOI8-R" (and it is not so important what happens with the language part).

On the other hand, this might cause wrong formatting of dates in some documents created on the remote side during the ssh-session (UTF-8 is expected in the documents on the remote side, but some programs might print the date according to the overridden LC_TIME). But AFAIU this may happen only in broken programs: for a document, LANGUAGE and the document's meta-information should be taken into account.

(Another solution might be a recoding tool on top of an ssh client; perhapsm screen can do this.)