SSH UTF-8 character mangling

Bug #10728 reported by Jan
8
Affects Status Importance Assigned to Milestone
openssh (Ubuntu)
Invalid
Medium
Unassigned

Bug Description

When I do SSH from UTF-8 enabled Hoary box (LANG=cs_CZ.UTF-8) to ISO-8859-2
Warty machine (LANG=cs_CZ) Czech characters are replaced by blanks
(gnome-terminal) or mangled (VGA console).

Revision history for this message
Colin Watson (cjwatson) wrote :

Yes, this is kind of inevitable really ...

The first problem is that ssh doesn't pass locale information across to the
server, and even if it did sshd wouldn't do anything with it. This has been
fixed in OpenSSH 3.9p1; you'll be able to pass selected environment variables to
the server, and we'll probably configure it to pass LANG and LC_* by default.
You'll need a 3.9p1 server to take advantage of that, though.

The second problem, over and above this, is that text doesn't get recoded from
ISO-8859-2 to UTF-8 when it reaches your ssh client. This is much harder to fix,
and I don't think it's likely to be fixed any time soon, because many programs
such as scp expect ssh to be 8-bit-clean. You can use the 'luit' program to work
around this.

Much of this, of course, goes away when we have UTF-8 everywhere, and we're
trying to make a step towards that by defaulting to UTF-8 in Hoary. However, it
will take many, many years to get rid of legacy encodings entirely. :-(

Revision history for this message
Colin Watson (cjwatson) wrote :

OpenSSH 3.9p1 is now in Hoary, fixing the first problem I mentioned. I think
this is about as good as we're likely to get in the medium term.

Revision history for this message
Carthik Sharma (carthik) wrote :

Thank you for reporting this bug.

Has this bug been favorably resolved in the latest Dapper with the changes that Colin mentioned?
If so can we close this bug?

Changed in openssh:
status: Unconfirmed → Needs Info
Revision history for this message
Colin Watson (cjwatson) wrote :

While this bug is better than it used to be, I don't think I can in due conscience claim that it's fixed.

Changed in openssh:
status: Needs Info → Confirmed
Colin Watson (cjwatson)
Changed in openssh:
assignee: kamion → nobody
Revision history for this message
trollord (trollenlord) wrote :

This bug is still valid with Feisty. I am one of those people who are suffering from bone headed admins running ancient software versions, and I get this daily for many occasions.

Revision history for this message
Loye Young (loyeyoung) wrote :

This should be closed as invalid.

This is not really a bug in the first place. It's a consequence of accessing a file encoded in one character set from a terminal / console that uses another. ssh is doing its job exactly as it's supposed to. If the file were on the local machine, but you were using a terminal or console that used a different encoding, you'd have the exact same issue.

To trollord: you can change the charset of the terminal or console you are using. The default consoles tty1 through tty6 can have completely separate fonts and encodings from each other. (See /etc/console-tools/config). Similarly, the various terminal emulators have the ability to change encodings on the fly.

Revision history for this message
rusivi2 (rusivi2-deactivatedaccount) wrote :

Thank you for reporting this issue.

This seems like a wishlist for encoding detection. Should be marked as such.

Revision history for this message
dino99 (9d9) wrote :

abandonware

Changed in openssh (Ubuntu):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.