Main Page | Report this Page
Linux Forum Index  »  Linux Setup  »  Trouble with non-ASCII characters over SSH. Help,...
Page 1 of 1    

Trouble with non-ASCII characters over SSH. Help,...

Author Message
Alan Mackenzie...
Posted: Fri Oct 30, 2009 10:01 am
Guest
Hi, everybody!

I typically use Usenet via an SSH link to my ISP. Non-ascii characters
don't make it through to the other end, which is particularly sad when I
want to write in German.

I've looked for stuff to configure in the FM, but nothing I've tried has
worked yet.

I've tried:
ssh -2 -l<username> -e none

, to try and get a "transparent session" in SSH version 2. No joy.

Would somebody please give me some tips on this?

Thanks in advance!

--
Alan Mackenzie (Nuremberg, Germany).
 
James Michael Fultz...
Posted: Fri Oct 30, 2009 6:58 pm
Guest
* Alan Mackenzie <acm at (no spam) muc.de>:
Quote:
Hi, everybody!

I typically use Usenet via an SSH link to my ISP. Non-ascii characters
don't make it through to the other end, which is particularly sad when I
want to write in German.

Sounds like the proper locale ($LANG, etc.) is not setup on the remote
host. Compare the output of the locale command locally and remotely.

--
James Michael Fultz <xyzzy at (no spam) sent.as.invalid>
Remove this part when replying ^^^^^^^^
 
Alan Mackenzie...
Posted: Sat Oct 31, 2009 6:52 am
Guest
Hi, Bill!

Unruh <unruh-spam at (no spam) physics.ubc.ca> wrote:
Quote:
James Michael Fultz <xyzzy at (no spam) sent.as.invalid> writes:

* Alan Mackenzie <acm at (no spam) muc.de>:
Hi, everybody!

I typically use Usenet via an SSH link to my ISP. Non-ascii
characters don't make it through to the other end, which is
particularly sad when I want to write in German.

That makes no sense. ssh does not care what the character is-- it is
just sending bytes. In fact, what is acrtually sent is any one of 256
characters (it is encrypted and encryption spews out all of the
possible bytes.) As below there is almost certainly something else
wrong. Stop looking at ssh as the problem.

Hmm. Ok. I didn't really think ssh was the problem, I was trying to
report accurately what I saw without making guesses.

Do you have any idea what the "something else" might be?

Quote:
Sounds like the proper locale ($LANG, etc.) is not setup on the remote
host. Compare the output of the locale command locally and remotely.

--
Alan Mackenzie (Nuremberg, Germany).
 
Alan Mackenzie...
Posted: Sat Oct 31, 2009 6:58 am
Guest
James Michael Fultz <xyzzy at (no spam) sent.as.invalid> wrote:
Quote:
* Alan Mackenzie <acm at (no spam) muc.de>:
Hi, everybody!

I typically use Usenet via an SSH link to my ISP. Non-ascii
characters don't make it through to the other end, which is
particularly sad when I want to write in German.

Sounds like the proper locale ($LANG, etc.) is not setup on the remote
host. Compare the output of the locale command locally and remotely.

My home box has LANG set to en_GB; None of the LC_* variables are set. I
tried setting LANG on the remote box to en_GB - no joy. I even tried
setting LANG (remote) to de_DE - also nothing.

When on a bash command line on the remote machine, the German characters
do nothing, appart from Eszet ("sharp S"), which brings up the previous
command in the command history. Hmmm. That sounds like a clue. I'll
have to look at that.

--
Alan Mackenzie (Nuremberg, Germany).
 
Unruh...
Posted: Sat Oct 31, 2009 10:42 am
Guest
James Michael Fultz <xyzzy at (no spam) sent.as.invalid> writes:

Quote:
* Alan Mackenzie <acm at (no spam) muc.de>:
Hi, everybody!

I typically use Usenet via an SSH link to my ISP. Non-ascii characters
don't make it through to the other end, which is particularly sad when I
want to write in German.

That makes no sense. ssh does not care what the character is-- it is just sending
bytes. In fact, what is acrtually sent is any one of 256 characters (it is
encrypted and encryption spews out all of the possible bytes.)
As below there is almost certainly something else wrong. Stop looking at ssh as
the problem.


Quote:
Sounds like the proper locale ($LANG, etc.) is not setup on the remote
host. Compare the output of the locale command locally and remotely.

--
James Michael Fultz <xyzzy at (no spam) sent.as.invalid
Remove this part when replying ^^^^^^^^
 
James Michael Fultz...
Posted: Sat Oct 31, 2009 11:00 am
Guest
* Unruh <unruh-spam at (no spam) physics.ubc.ca>:
Quote:
James Michael Fultz <xyzzy at (no spam) sent.as.invalid> writes:
* Alan Mackenzie <acm at (no spam) muc.de>:
I typically use Usenet via an SSH link to my ISP. Non-ascii characters
don't make it through to the other end, which is particularly sad when I
want to write in German.

That makes no sense. ssh does not care what the character is-- it is
just sending bytes. In fact, what is acrtually sent is any one of 256
characters (it is encrypted and encryption spews out all of the
possible bytes.) As below there is almost certainly something else
wrong. Stop looking at ssh as the problem.

Agreed except ssh might be part of the solution, explained below.

Quote:
Sounds like the proper locale ($LANG, etc.) is not setup on the remote
host. Compare the output of the locale command locally and remotely.

There are ssh configuration options for client and server for passing on
environment variables. I was thinking of this earlier having recently
read about it in another discussion but could not clearly recall it at
the time of my reply

Quoting ssh_config(5):

SendEnv
Specifies what variables from the local environ(7) should be sent
to the server. Note that environment passing is only supported
for protocol 2, the server must also support it, and the server
must be configured to accept these environment variables. Refer
to AcceptEnv in sshd_config(5) for how to configure the server.
Variables are specified by name, which may contain the wildcard
characters '*' and '?'. Multiple environment variables may be
separated by whitespace or spread across multiple SendEnv direc-
tives. The default is not to send any environment variables.

Quoting sshd_config(5):

AcceptEnv
Specifies what environment variables sent by the client will be
copied into the session's environ(7). See SendEnv in
ssh_config(5) for how to configure the client. Note that envi-
ronment passing is only supported for protocol 2. Variables are
specified by name, which may contain the wildcard characters '*'
and '?'. Multiple environment variables may be separated by
whitespace or spread across multiple AcceptEnv directives. Be
warned that some environment variables could be used to bypass
restricted user environments. For this reason, care should be
taken in the use of this directive. The default is not to accept
any environment variables.

--
James Michael Fultz <xyzzy at (no spam) sent.as.invalid>
Remove this part when replying ^^^^^^^^
 
 
Page 1 of 1    
All times are GMT - 5 Hours
The time now is Tue Dec 01, 2009 12:24 pm