Hi,

I do not know if this classifies as a bug or feature request and if
there are any security implications from the problem below.

I noticed that sshd does not encode the banner file in ISO-10646 UTF-8
before sending it to the client as specified in
draft-ietf-secsh-userauth-27.txt. Instead it seems to send the file as
is.

It also seems as the client does not convert the banner from UTF-8 to
the codepage it runs in.

To test that the server does not encode the banner properly one can
create a banner with non-ascii characters and save it with a non
ISO-10646 UTF-8 codepage (iso-8859-1 in my case). Then connect to the
server with a ssh client running in a UTF-8 environment.

To test that the client does not convert the banner to the current
codepage one can create a banner same as above, but save it in UTF-8
(with gedit for instance) and then connect to the server using a ssh
client running in a non UTF-8 environment.


/Lars.

To be honest, I think this is rather optimistic. How is the server
supposed to know what character set the file is encoded in, if it isn't
UTF-8? For example, you can't tell the difference between ISO-8859-1 and
ISO-8859-2 unless you understand the language in question.

At best, perhaps, the server could strip out characters not valid in
UTF-8, or make a wild guess at ISO-8859-1, or similar.

This seems like a legitimate bug, though.

Thanks,