While wanting to put files to a remote host using the fish protocol, it 
prompted as expected the passphrase for the ssh key I use.

MY pass-phrase actually contains non ASCII characters encoded as utf8, 
but the dialog box seems to expect a latin1 string.

Test to reproduce the error:
Precondition: remote account password or ssh key passphrase is "ètr"

Test 1:
  - Use fish to access a remote server using for example Dolphin
  - A dialog prompt for the password (or passphrase of the key)
  - Put "ètr" in the password field and confirm
  - The password is refused and fish ask again for the password


Test 2:
  - Use fish to access a remote server using for example Dolphin
  - A dialog prompt for the password (or passphrase of the key)
  - Put "ètr" in the password field and confirm
  - The password is accepted and fish show files of the remote server

The password is read as Unicode UTF-16 (using QString), then kio_fish 
convert it to latin1 and send it to ssh.

When putting "ètr" in the password prompt, the "è" character is sent to 
ssh as byte 0xE8. ssh read 0xE8 and compare it to the pass-phrase which 
is encoded in utf8, and so fail because "è" in UTF-8 is encoded as bytes 
0xC3 0xA8.

When putting "ètr", "è" is sent to ssh as bytes 0xC3 0xA8. ssh read 
these two bytes and compare them to the passphrase and these bytes match 
to the the UTF-8 character "è" so ssh can use key on go on.

In my case, I created the key using command line, and my system use 
UTF-8, so the passphrase I entered is encoded as UTF-8. ssh does not 
seems to do any character conversion, so the expect encoding is the one 
used at passphrase creation.


I posted a bug report about that:
https://bugs.kde.org/show_bug.cgi?id=332428

After more investigation, it seems that other text strings (username, 
account password, hostname) may be read by ssh as UTF-8 strings too. In 
comment 2 in the bug report, I say that ssh is started with LANG=C 
LC_ALL=C, but it's not the case (I confused ssh arguments with the 
command executed on the remote host when ssh start).

To be sure I checked the environment variables of the ssh spawned by 
kio_fish, and there is LANG=fr_FR.UTF-8.

So as I first thought, username, hostname and password (in case of login 
with password authentication) may also be read as UTF-8 strings by ssh 
but fish send them as latin1 strings.

This issue seems to not be so easy to handle, so can someone confirm 
expected encodings and if username, hostname, password and pass-phrase 
should indeed be send using the local encoding (ie: use toLocal8Bits) 
instead of latin1 (toLatin1).

Cheers,
   Alexis