Can't authenticate with password containing non-ASCII characters

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Change your password the one that includes non-ASCII characters, like é, 
ł, đ, etc.
2. Try to log in with password authentication.
3. You'll get a password failed message.

What is the expected output? What do you see instead?
You should be able to log in with a correct password, even if it contains 
non-ASCII characters. Instead, you get a password failed message in ConnectBot 
and in the security log of the host.

What version of the product are you using (you can see this by using Menu
-> About in the Host List)?
v1.7.1 2010.10.08
It's the most recent version from the Market as far as I know.

What type of system are you trying to connect to?
I tried to connect to Ubuntu 11.04 and Fedora 15.
These systems use UTF-8 encoding, just like ConnectBot.

Original issue reported on code.google.com by kovacs.b...@gmail.com on 16 Oct 2011 at 12:02

[GoogleCodeExporter]

Happy to find someone with the same problem as me. 

I can see the issue is from October 2011. Can we expect the problem to be 
solved? Won't it be for any reason?

Anyway thanks a lot for the app.

Cheers.

Original comment by alex.pro...@gmail.com on 26 Jul 2012 at 8:10

[GoogleCodeExporter]

I just did the same, e.g. change my password to non-ASCII on ubuntu 12.04.

I tested to the server's terminal, ssh from xterm, chrome's hterm nacl app, 
putty, cygwin's ssh, OSX's ssh, to my surprise, they all worked! Only 
ConnectBot failed to connect.

Looking at the sources, it looks like a problem in 
src/com/trilead/ssh2/packets/PacketUserauthRequestPassword.java line 62, 
tw.writeString() is not using whatever the current code page is set to. Same 
for the username. In general it is utf-8 but let's not assume that.

The problem is in src/com/trilead/ssh2/packets/TypesWriter.java line 139, it's 
assuming ISO-8859-1 all the time.

I guess PacketUserauthRequestPassword should be constructed with the 
connection's encoding and encodes the string in the correct code page itself. 
Does this makes sense?

Original comment by maruel@google.com on 12 Aug 2012 at 1:31