Take the following configuration: local$ echo $LANG;locale charmap pl_PL UTF-8 local$ ssh user@remote [...] remote$ echo $LANG;locale charmap pl_PL ISO-8859-2 Now, if I invoke any locale-aware application on the remote machine (tar --help is enough), any non-ASCII letter it sends over the net (try to) appear on my console encoded in ISO-8859-2, that is, contrary to my terminal's settings. Note that it's perfectly valid in glibc to pick any character encoding for the locale one wants to use. I believe that the client and the server should agree on a common interpretation of the octets sent over the net (server->client or vice versa) as characters and provide some sort of on-the-fly conversion.
The protocol doesn't include transmission of environment variables. You should set it at the remote end in .profile or similar.
Mass change of RESOLVED bugs to CLOSED
I wonder why this bug has been closed as wontfix. FYI, there has been some discussions about locale/charset negociation here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=337041 (with a Cc to ietf-ssh at NetBSD.org). Also, setting environment variables on the remote end is not always possible when a command is used. I've reported bug 1504 about that.