Backspace via SSH only deletes last byte of characters (no IUTF8 handling, requires standardisation work)

Bug #394570 reported by AZaharia
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
openssh (Debian)
Fix Released
Unknown
openssh (Ubuntu)
Fix Released
Low
Unassigned

Bug Description

Binary package hint: openssh-client

This is not a terminal-related problem: regardless of the terminal used and the way the backspace key is supposed to behave (ASCII DEL, escape sequence, Control+H), what happens is that via SSH the backspace key only deletes the last byte of a character, not the whole character itself.

You can notice this when you use UTF-8 characters that are encoded on more than 1 byte. Some diacritics from the Latin alphabet are encoded on 2 bytes, whereas some Japanese characters are encoded on 3.

As an example, assume the following scenario: the letter "ș" is encoded as "c8 99" and endline is encoded as "0a":

user@host:~$ cat > ș.txt
ș
^d
user@host:~$ hexdump -C ș.txt
00000000 c8 99 0a |...|
00000003

Now, assume you write "testș[hit backspace]test[endline]". On the physical host (i.e. without being SSH-ed into it), the hexdump of that file will be:

user@host:~$ cat > test.txt
testș[backspace]test
^d
user@host:~$ hexdump -C test.txt
00000000 74 65 73 74 74 65 73 74 0a |testtest.|
00000009

whereas the *same* thing via SSH would lead you to having the following hexdump:

user@host:~$ ssh user@localhost
user@localhost's password:
user@host:~$ cat > test.txt
testș[backspace]test
^d
user@host:~$ hexdump -C test.txt
00000000 74 65 73 74 c8 74 65 73 74 0a |test.test.|
0000000a

So notice how backspace only deleted via SSH the last byte of "ș" i.e. only the "99" out of "c8 99"; compare the expected hexdump:

74 65 73 74 74 65 73 74 0a

with the actual hexdump:

74 65 73 74 c8 74 65 73 74 0a

locale is set to en_US.UTF-8; changing it to ro_RO.UTF-8 (both on the host and via SSH) yields the same results.

Finally, last details:

Ubuntu 9.04
Kernel 2.6.28-13-generic
openssh-client: Installed: 1:5.1p1-5ubuntu1
openssh-server: Installed: 1:5.1p1-5ubuntu1

L.E.: I also tried the same thing using dropbear instead of OpenSSH.

Revision history for this message
In , Colin Watson (cjwatson) wrote : Re: Bug#337041: openssh: ssh doesn't retain the IUTF8 flag

On Wed, Nov 02, 2005 at 12:25:54PM +0100, Vincent Lefevre wrote:
> When I do a ssh from a terminal with IUTF8 flag set, this flag is
> no longer set on the other side. The easiest way to test this is
> to do a ssh to localhost.

Sorry, I'm not familiar with the IUTF8 flag; as far as I know, the
terminal emulator I generally use (pterm) doesn't support it. What
terminal are you using?

--
Colin Watson [<email address hidden>]

Revision history for this message
In , Vincent Lefevre (vincent-vinc17) wrote :

On 2005-11-02 18:13:32 +0000, Colin Watson wrote:
> Sorry, I'm not familiar with the IUTF8 flag; as far as I know, the
> terminal emulator I generally use (pterm) doesn't support it. What
> terminal are you using?

xterm, with the patch I posted here:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=319237

--
Vincent Lefèvre <email address hidden> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Revision history for this message
In , Colin Watson (cjwatson) wrote : IUTF8 pseudo-terminal mode

Recent versions of the Linux kernel support an IUTF8 flag (see
http://www.cl.cam.ac.uk/~mgk25/unicode.html#mod) which allows the
character-erase function in cooked mode to handle UTF-8 characters
correctly. I would like to allow this mode to be preserved by SSH, but
there is no assignment for it at present.

Could this line be added to the appropriate place in
draft-ietf-secsh-connect and draft-ietf-secsh-assignednumbers to create
this assignment? 42 seems like a reasonable place for it.

          42 IUTF8 Assume input characters are UTF-8 encoded.

Thanks,

--
Colin Watson [<email address hidden>]

Revision history for this message
In , Bill Sommerfeld (sommerfeld-sun) wrote :

On Sat, 2005-12-31 at 11:05, Colin Watson wrote:
> Recent versions of the Linux kernel support an IUTF8 flag (see
> http://www.cl.cam.ac.uk/~mgk25/unicode.html#mod) which allows the
> character-erase function in cooked mode to handle UTF-8 characters
> correctly. I would like to allow this mode to be preserved by SSH, but
> there is no assignment for it at present.
>
> Could this line be added to the appropriate place in
> draft-ietf-secsh-connect and draft-ietf-secsh-assignednumbers to create
> this assignment? 42 seems like a reasonable place for it.
>
> 42 IUTF8 Assume input characters are UTF-8 encoded.

as others have suggested, it's already too late to modify -connect and
-assignednumbers.

So what needs to happen to get this standardized is for someone to write
an internet-draft documenting this extension and advance it as either a
working group item or as an individual submission.

In response to later messages:
> While setting LANG et al is indeed useful, it's not enough to make the
> kernel's terminal driver do the right thing when erasing characters in
> cooked mode. That's why the termios flag was invented.

I think Nicolas was implying that a request from the client to use a
UTF8 locale would cause the server to set up the pseudoterminal it
creates/allocates/... appropriately for the requested locale. But
that's perhaps at odds with the existing strategy within the protocol of
making termios-level details visible on the wire.

      - Bill

Revision history for this message
In , Nicolas Williams (nicolas-williams-sun) wrote :

On Mon, Jan 02, 2006 at 05:29:40PM -0500, Bill Sommerfeld wrote:
> In response to later messages:
> > While setting LANG et al is indeed useful, it's not enough to make the
> > kernel's terminal driver do the right thing when erasing characters in
> > cooked mode. That's why the termios flag was invented.
>
> I think Nicolas was implying that a request from the client to use a
> UTF8 locale would cause the server to set up the pseudoterminal it
> creates/allocates/... appropriately for the requested locale. But
> that's perhaps at odds with the existing strategy within the protocol of
> making termios-level details visible on the wire.

I think I was a bit more explicit about this, but, yes, this would be a
hack, and very POSIX-specific (and I was explicit about that too). But
such a hack would also probably make most users happy :^/ at the expense
of elegance and code complexity for SSHv2 servers running on POSIXy
platforms.

SSHv2's pty negotiation could certainly improve in this regard, I don't
deny it!

But I suspect saying "UTF-8" is not enough here. What options are
there? Should the pty driver reject non-UTF-8 sequences? Should it
normalize? Pass input through raw? I suspect most users wouldn't want
much of a pty UTF-8 input mechanism as their clients, presumably, have a
decent UTF-8 input method already -- but then, maybe they don't.

I definitely think this should be a WG work item, if nothing else to
ensure it gets more eyeballs because I18N requires care.

Nico
--

Revision history for this message
In , Jeffrey Hutzelman (jhutz) wrote :

On Monday, January 02, 2006 04:43:58 PM -0600 Nicolas Williams
<email address hidden> wrote:

> On Mon, Jan 02, 2006 at 05:29:40PM -0500, Bill Sommerfeld wrote:
>> In response to later messages:
>> > While setting LANG et al is indeed useful, it's not enough to make the
>> > kernel's terminal driver do the right thing when erasing characters in
>> > cooked mode. That's why the termios flag was invented.
>>
>> I think Nicolas was implying that a request from the client to use a
>> UTF8 locale would cause the server to set up the pseudoterminal it
>> creates/allocates/... appropriately for the requested locale. But
>> that's perhaps at odds with the existing strategy within the protocol of
>> making termios-level details visible on the wire.
>
> I think I was a bit more explicit about this, but, yes, this would be a
> hack, and very POSIX-specific (and I was explicit about that too). But
> such a hack would also probably make most users happy :^/ at the expense
> of elegance and code complexity for SSHv2 servers running on POSIXy
> platforms.
>
> SSHv2's pty negotiation could certainly improve in this regard, I don't
> deny it!
>
> But I suspect saying "UTF-8" is not enough here. What options are
> there? Should the pty driver reject non-UTF-8 sequences? Should it
> normalize? Pass input through raw? I suspect most users wouldn't want
> much of a pty UTF-8 input mechanism as their clients, presumably, have a
> decent UTF-8 input method already -- but then, maybe they don't.
>
> I definitely think this should be a WG work item, if nothing else to
> ensure it gets more eyeballs because I18N requires care.

The original request wasn't really about standardizing handling of UTF-8 in
SSH data streams. That's really outside the scope of the protocol --
unlike telnet, SSH doesn't provide a "virtual terminal"; it connects the
shell running on the server to the user's real terminal, and experience has
shown this is basically the right thing to do.

The request here was to enable SSH to pass a platform-specific TTY mode bit
which it doesn't currently handle. The bit in question causes the tty
driver on Linux systems to behave in a particular way; specifically, it
tells the driver that the user is typing in UTF-8, and that when the user
types the ERASE character, the driver should remove a complete character
(possibly a multi-byte UTF-8 sequence) from the input buffer.

One could argue that an SSH server running on such a system should look at
the configured locale and configure the PTY appropriately, and that's
probably even a good idea. However, a user using 'stty' to change terminal
modes at the remote end of an ssh connection has an expectation that the
change will propagate to the local terminal as much as possible, and the
point of defining a bit for IUTF8 is to help make that possible.

-- Jeff

Revision history for this message
In , Nicolas Williams (nicolas-williams-sun) wrote :

On Mon, Jan 02, 2006 at 06:20:50PM -0500, Jeffrey Hutzelman wrote:
> The original request wasn't really about standardizing handling of UTF-8 in
> SSH data streams. That's really outside the scope of the protocol --
> unlike telnet, SSH doesn't provide a "virtual terminal"; it connects the
> shell running on the server to the user's real terminal, and experience has
> shown this is basically the right thing to do.

Well, yes, but I'm not entirely sure one wouldn't want to negotiate
additional behaviours -- I'm not saying one should as I've not really
thought this through.

> The request here was to enable SSH to pass a platform-specific TTY mode bit
> which it doesn't currently handle. The bit in question causes the tty
> driver on Linux systems to behave in a particular way; specifically, it
> tells the driver that the user is typing in UTF-8, and that when the user
> types the ERASE character, the driver should remove a complete character
> (possibly a multi-byte UTF-8 sequence) from the input buffer.

Got it.

> One could argue that an SSH server running on such a system should look at
> the configured locale and configure the PTY appropriately, and that's
> probably even a good idea. However, a user using 'stty' to change terminal
> modes at the remote end of an ssh connection has an expectation that the
> change will propagate to the local terminal as much as possible, and the
> point of defining a bit for IUTF8 is to help make that possible.

Did you switch local/remote here?

Nico
--

Revision history for this message
In , Vincent Lefevre (vincent-vinc17) wrote :

On 2006-01-02 18:20:50 -0500, Jeffrey Hutzelman wrote:
> One could argue that an SSH server running on such a system should look
> at the configured locale and configure the PTY appropriately, and that's
> probably even a good idea.

What "configured locale"? The user may use a locale which is not the
default one at the system level. Perhaps you mean that the SSH client
should propagate the locale (more precisely, the charmap) to the
remote side, so that the SSH server can use it (in which case the
server should make this information available at the user level too,
as it can be useful to set up the LC_CTYPE environment variable).

--
Vincent Lefèvre <email address hidden> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Revision history for this message
In , Nicolas Williams (nicolas-williams-sun) wrote :

On Mon, May 12, 2008 at 02:00:56AM +0200, Vincent Lefevre wrote:
> On 2006-01-02 18:20:50 -0500, Jeffrey Hutzelman wrote:
> > One could argue that an SSH server running on such a system should look
> > at the configured locale and configure the PTY appropriately, and that's
> > probably even a good idea.
>
> What "configured locale"? The user may use a locale which is not the

Whatever the locale for that channel/session/whatever.

> default one at the system level. Perhaps you mean that the SSH client
> should propagate the locale (more precisely, the charmap) to the

SunSSH 1.1 does (by having the client set per-channel LANG/LC_*
environment variables).

It's less than perfect: the client has no idea what a client-side locale
maps to on the server side.

Also, it's not just character sets that matter, but language for
localization of messages, date formats, etc...

Nico
--

Revision history for this message
In , Vincent Lefevre (vincent-vinc17) wrote :

On 2008-05-11 21:00:55 -0500, Nicolas Williams wrote:
> On Mon, May 12, 2008 at 02:00:56AM +0200, Vincent Lefevre wrote:
> > default one at the system level. Perhaps you mean that the SSH client
> > should propagate the locale (more precisely, the charmap) to the
>
> SunSSH 1.1 does (by having the client set per-channel LANG/LC_*
> environment variables).

I meant in a way that always works in practice.

> It's less than perfect: the client has no idea what a client-side
> locale maps to on the server side.

Yes, that's the problem: it's not always possible to rebuild a correct
LC_CTYPE on the remote side, e.g. if LC_CTYPE is "en_US", one doesn't
have information about the charset on the remote side.

> Also, it's not just character sets that matter, but language for
> localization of messages, date formats, etc...

Well, localization of messages and date formats are just a user choice.
If they are different on the remote side, this isn't really a problem.
Concerning the character set, the remote one must be compatible with
the local one, at least when a terminal is used (ditto for the IUTF8
pseudo-terminal mode). Otherwise the user can't view or edit non-ASCII
characters correctly.

--
Vincent Lefèvre <email address hidden> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

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

On Mon, May 12, 2008 at 10:07:47AM +0200, Vincent Lefevre wrote:
> On 2008-05-11 21:00:55 -0500, Nicolas Williams wrote:
> > On Mon, May 12, 2008 at 02:00:56AM +0200, Vincent Lefevre wrote:
> > > default one at the system level. Perhaps you mean that the SSH client
> > > should propagate the locale (more precisely, the charmap) to the
> >
> > SunSSH 1.1 does (by having the client set per-channel LANG/LC_*
> > environment variables).

OpenSSH, as configured in Debian, does this too.

> I meant in a way that always works in practice.
>
> > It's less than perfect: the client has no idea what a client-side
> > locale maps to on the server side.
>
> Yes, that's the problem: it's not always possible to rebuild a correct
> LC_CTYPE on the remote side, e.g. if LC_CTYPE is "en_US", one doesn't
> have information about the charset on the remote side.

Locale names are indeed opaque as far as POSIX is concerned, so there's
no portable way to pick them apart. But even if locale names are in
principle identical (i.e. client and server running the same release of
the same operating system), there's a further problem. With glibc,
locale definitions are quite large (thus inconvenient to distribute in
pre-generated form) and take some time to generate, so it's fairly
common for distributions to set things up so that you only generate the
locale definitions you need. The locale you're using on the client may
simply not exist on the server.

Now, in some ways this does end up invoking undefined behaviour; you're
asking for a locale that doesn't exist. Messages will of course end up
being output in the C locale, and so on. But it is *terribly* useful to
at least get the character encoding right, as otherwise you get hopeless
garbage on the screen and it may well not be very obvious what the
problem is.

This is compounded by the fact that there is no equivalent of "C" for
UTF-8 in glibc: that is, there's no way to say "I just want a basically
unlocalised system that happens to use the UTF-8 encoding for
everything". Thus even people who don't care about localisation have to
select something like en_US.UTF-8 or en_GB.UTF-8, and any time they ssh
to a server that doesn't have those locales generated they end up with
screwed-up output from full-screen terminal applications.

> > Also, it's not just character sets that matter, but language for
> > localization of messages, date formats, etc...
>
> Well, localization of messages and date formats are just a user choice.
> If they are different on the remote side, this isn't really a problem.
> Concerning the character set, the remote one must be compatible with
> the local one, at least when a terminal is used (ditto for the IUTF8
> pseudo-terminal mode). Otherwise the user can't view or edit non-ASCII
> characters correctly.

Absolutely.

--
Colin Watson [<email address hidden>]

Revision history for this message
In , Nicolas Williams (nicolas-williams-sun) wrote :

On Mon, May 12, 2008 at 10:07:47AM +0200, Vincent Lefevre wrote:
> On 2008-05-11 21:00:55 -0500, Nicolas Williams wrote:
> > SunSSH 1.1 does (by having the client set per-channel LANG/LC_*
> > environment variables).
>
> I meant in a way that always works in practice.

It tends to, though only by dint of luck.

> > It's less than perfect: the client has no idea what a client-side
> > locale maps to on the server side.
>
> Yes, that's the problem: it's not always possible to rebuild a correct
> LC_CTYPE on the remote side, e.g. if LC_CTYPE is "en_US", one doesn't
> have information about the charset on the remote side.

There should be a way. SSHv2 already negotiates languages. A
negotiation of charsets per-channel wouldn't be too difficult to add.

> > Also, it's not just character sets that matter, but language for
> > localization of messages, date formats, etc...
>
> Well, localization of messages and date formats are just a user choice.

Yes, but the user doesn't want to be making that choice all the time.

What if the user reads three languages and doesn't know which the remote
server has localizations for? What if the user doesn't have "dot files"
on the server? It'd be nice if the client and server could just settle
on a locale that meets the user's needs with no additional input from
the user.

> If they are different on the remote side, this isn't really a problem.

Yes it is.

> Concerning the character set, the remote one must be compatible with
> the local one, at least when a terminal is used (ditto for the IUTF8
> pseudo-terminal mode). Otherwise the user can't view or edit non-ASCII
> characters correctly.

I agree with the first point, but not necessarily with the second (the
client can always put the local terminal into raw mode and let the
server-side IUTF8 mode take over).

Nico
--

Revision history for this message
In , Vincent Lefevre (vincent-vinc17) wrote :

On 2008-05-12 09:35:46 -0500, Nicolas Williams wrote:
> What if the user reads three languages and doesn't know which the remote
> server has localizations for? What if the user doesn't have "dot files"
> on the server?

There's also the problem that if the user shell is bash, the .bashrc
(or .bash_profile) isn't always read (fortunately, Debian's bash doesn't
have this problem).

> It'd be nice if the client and server could just settle on a locale
> that meets the user's needs with no additional input from the user.

If full locale negociation could be added to SSH, this would be great.

> > If they are different on the remote side, this isn't really a problem.
>
> Yes it is.

Well, less than the charset problem. BTW, I generally want some of my
locales to be defined locally on each machine. For instance, I use
LC_TIME=en_DK (to have ISO-8601 dates) under Linux, but this locale
doesn't exist under Mac OS X; worse than that, if I try to use it
under Mac OS X, it makes a terrible mess.

> > Concerning the character set, the remote one must be compatible with
> > the local one, at least when a terminal is used (ditto for the IUTF8
> > pseudo-terminal mode). Otherwise the user can't view or edit non-ASCII
> > characters correctly.
>
> I agree with the first point, but not necessarily with the second (the
> client can always put the local terminal into raw mode and let the
> server-side IUTF8 mode take over).

I don't understand, or is it just that this isn't implemented in
OpenSSH yet?

--
Vincent Lefèvre <email address hidden> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Revision history for this message
AZaharia (f0rg3r) wrote : Backspace via SSH only deletes last byte of characters

Binary package hint: openssh-client

This is not a terminal-related problem: regardless of the terminal used and the way the backspace key is supposed to behave (ASCII DEL, escape sequence, Control+H), what happens is that via SSH the backspace key only deletes the last byte of a character, not the whole character itself.

You can notice this when you use UTF-8 characters that are encoded on more than 1 byte. Some diacritics from the Latin alphabet are encoded on 2 bytes, whereas some Japanese characters are encoded on 3.

As an example, assume the following scenario: the letter "ș" is encoded as "c8 99" and endline is encoded as "0a":

user@host:~$ cat > ș.txt
ș
^d
user@host:~$ hexdump -C ș.txt
00000000 c8 99 0a |...|
00000003

Now, assume you write "testș[hit backspace]test[endline]". On the physical host (i.e. without being SSH-ed into it), the hexdump of that file will be:

user@host:~$ cat > test.txt
testș[backspace]test
^d
user@host:~$ hexdump -C test.txt
00000000 74 65 73 74 74 65 73 74 0a |testtest.|
00000009

whereas the *same* thing via SSH would lead you to having the following hexdump:

user@host:~$ ssh user@localhost
user@localhost's password:
user@host:~$ cat > test.txt
testș[backspace]test
^d
user@host:~$ hexdump -C test.txt
00000000 74 65 73 74 c8 74 65 73 74 0a |test.test.|
0000000a

So notice how backspace only deleted via SSH the last byte of "ș" i.e. only the "99" out of "c8 99"; compare the expected hexdump:

74 65 73 74 74 65 73 74 0a

with the actual hexdump:

74 65 73 74 c8 74 65 73 74 0a

locale is set to en_US.UTF-8; changing it to ro_RO.UTF-8 (both on the host and via SSH) yields the same results.

Finally, last details:

Ubuntu 9.04
Kernel 2.6.28-13-generic
openssh-client: Installed: 1:5.1p1-5ubuntu1
openssh-server: Installed: 1:5.1p1-5ubuntu1

AZaharia (f0rg3r)
description: updated
Revision history for this message
Chuck Short (zulcss) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue that you reported is one that should be reproducible with the live environment of the Desktop CD of the development release - Karmic Koala. It would help us greatly if you could test with it so we can work on getting it fixed in the next release of Ubuntu. You can find out more about the development release at http://www.ubuntu.com/testing/. Thanks again and we appreciate your help.

Changed in openssh (Ubuntu):
importance: Undecided → Low
status: New → Incomplete
Revision history for this message
Chuck Short (zulcss) wrote :

We'd like to figure out what's causing this bug for you, but we haven't heard back from you in a while. Could you please provide the requested information? Thanks!

Revision history for this message
AZaharia (f0rg3r) wrote :

Hello Chuck,

I'm sorry for having taken so long to answer.

Here's the status: I re-tested this issue on two Ubuntu 9.10 machines. It's the same as in the original description (even after setting the locales to a particular language).

UTF-8 characters that are encoded on more than 1 byte are not fully deleted when pressing the backspace key, under SSH; only the last byte is deleted.

For instance, some Chinese/Japanese (?) characters are encoded on 3 bytes. Here is an example: "構" should be encoded as "e6 a7 8b". When you type and then delete this character via SSH, the file still contains the first 2 bytes of this character (i.e. "e6 a7").

Revision history for this message
Chuck Short (zulcss) wrote :

Thanks for the information.

Regards
chuck

Changed in openssh (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Colin Watson (cjwatson) wrote :

You can work around this by running 'stty iutf8' on the server each time you ssh somewhere. Unfortunately fixing this requires an extension to the SSH protocol - see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=337041 for the gory details - so it won't be a quick process.

Changed in openssh (Ubuntu):
status: Confirmed → Triaged
Changed in openssh (Debian):
status: Unknown → New
Colin Watson (cjwatson)
summary: - Backspace via SSH only deletes last byte of characters
+ Backspace via SSH only deletes last byte of characters (no IUTF8
+ handling, requires standardisation work)
Revision history for this message
Egmont Koblinger (egmont-gmail) wrote :

I don't understand: why does it require an extension to SSH protocol?

Sure, one possible way would be to make ssh forward this bit of information. However, the IUTF8 flag should be set consistently with the locale (the character set part), which is not forwarded by ssh either - but still set on the server.

Another approach could be to do whatever happens to the locale: when you log on remotely, someone sets this environment variable for you. Whoever does this (pam, login script, whatever) could also modify the terminal settings, couldn't it? Taking this approach, you don't need to modify the protocol, just make sure that whenever someone logs in via ssh, they don't only get $LANG and stuff but also the stty iutf8 bit set correctly.

Moreover, I believe the meaning of /sys/module/vt/parameters/default_utf8 is that every newly allocated terminal gets the iutf8 flag set automatically to this value by the kernel. Should the ssh server or login procedure be unable to get the locale information, they ought to respect whatever is set here. This yet again doesn't require extending the protocol.

Changed in openssh (Debian):
status: New → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (3.3 KiB)

This bug was fixed in the package openssh - 1:7.3p1-1

---------------
openssh (1:7.3p1-1) unstable; urgency=medium

  * New upstream release (http://www.openssh.com/txt/release-7.3):
    - SECURITY: sshd(8): Mitigate a potential denial-of-service attack
      against the system's crypt(3) function via sshd(8). An attacker could
      send very long passwords that would cause excessive CPU use in
      crypt(3). sshd(8) now refuses to accept password authentication
      requests of length greater than 1024 characters.
    - SECURITY: ssh(1), sshd(8): Fix observable timing weakness in the CBC
      padding oracle countermeasures. Note that CBC ciphers are disabled by
      default and only included for legacy compatibility.
    - SECURITY: ssh(1), sshd(8): Improve operation ordering of MAC
      verification for Encrypt-then-MAC (EtM) mode transport MAC algorithms
      to verify the MAC before decrypting any ciphertext. This removes the
      possibility of timing differences leaking facts about the plaintext,
      though no such leakage has been observed.
    - ssh(1): Add a ProxyJump option and corresponding -J command-line flag
      to allow simplified indirection through a one or more SSH bastions or
      "jump hosts".
    - ssh(1): Add an IdentityAgent option to allow specifying specific agent
      sockets instead of accepting one from the environment.
    - ssh(1): Allow ExitOnForwardFailure and ClearAllForwardings to be
      optionally overridden when using ssh -W.
    - ssh(1), sshd(8): Implement support for the IUTF8 terminal mode as per
      draft-sgtatham-secsh-iutf8-00 (closes: #337041, LP: #394570).
    - ssh(1), sshd(8): Add support for additional fixed Diffie-Hellman 2K,
      4K and 8K groups from draft-ietf-curdle-ssh-kex-sha2-03.
    - ssh-keygen(1), ssh(1), sshd(8): Support SHA256 and SHA512 RSA
      signatures in certificates.
    - ssh(1): Add an Include directive for ssh_config(5) files (closes:
      #536031).
    - ssh(1): Permit UTF-8 characters in pre-authentication banners sent
      from the server.
    - ssh(1), sshd(8): Reduce the syslog level of some relatively common
      protocol events from LOG_CRIT.
    - sshd(8): Refuse AuthenticationMethods="" in configurations and accept
      AuthenticationMethods=any for the default behaviour of not requiring
      multiple authentication.
    - sshd(8): Remove obsolete and misleading "POSSIBLE BREAK-IN ATTEMPT!"
      message when forward and reverse DNS don't match.
    - ssh(1): Deduplicate LocalForward and RemoteForward entries to fix
      failures when both ExitOnForwardFailure and hostname canonicalisation
      are enabled.
    - sshd(8): Remove fallback from moduli to obsolete "primes" file that
      was deprecated in 2001 (LP: #1528251).
    - sshd_config(5): Correct description of UseDNS: it affects ssh hostname
      processing for authorized_keys, not known_hosts.
    - sshd(8): Send ClientAliveInterval pings when a time-based RekeyLimit
      is set; previously keepalive packets were not being sent.
    - sshd(8): Whitelist more architectures to enable the seccomp-bpf
      sandbox.
    - scp(1): Respect the local user's LC_CTYPE locale (clos...

Read more...

Changed in openssh (Ubuntu):
status: Triaged → Fix Released
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.