Bug#264024: propagate locale across ssh logins
Package: ssh
Version: 1:3.8.1p1-8
Severity: wishlist
I recently started using the en_US.UTF-8 locale. I was surprised that when
I logged in from one Debian system with LANG=en_US.UTF-8, to another Debian
system that supports this locale, that the LANG variable was empty. This
causes a problem with remote applications, because they don't know the
encoding being used by the terminal.
I would think this issue would come up often, but my web searches didn't
reveal much. The behavior I would expect is that locale environment
variables would be preserved, as long as the remote system supports that
locale. If not, a warning should perhaps be printed.
Andrew
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.7-1-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8
Versions of packages ssh depends on:
ii adduser 3.59 Add and remove users and groups
ii debconf 1.4.30 Debian configuration management sy
ii dpkg 1.10.23 Package maintenance system for Deb
ii libc6 2.3.2.ds1-15 GNU C Library: Shared libraries an
ii libpam-modules 0.76-22 Pluggable Authentication Modules f
ii libpam-runtime 0.76-22 Runtime support for the PAM librar
ii libpam0g 0.76-22 Pluggable Authentication Modules l
ii libssl0.9.7 0.9.7d-5 SSL shared libraries
ii libwrap0 7.6.dbs-5 Wietse Venema's TCP wrappers libra
ii zlib1g 1:1.2.1.1-5 compression library - runtime
-- debconf information:
ssh/insecure_rshd:
ssh/ssh2_keys_merged:
ssh/user_environment_tell:
* ssh/forward_warning:
ssh/insecure_telnetd:
ssh/new_config: true
* ssh/use_old_init_script: true
* ssh/protocol2_only: true
ssh/encrypted_host_key_but_no_keygen:
* ssh/run_sshd: true
* ssh/SUID_client: false
Reply to: