Ticket #213 (closed defect: fixed)

Opened 7 years ago

Last modified 7 years ago

Not working with accentuated characters in password.

Reported by: piotr@regne.net Owned by: alamaison
Priority: critical (affects core workflow) Milestone: 0.9.x Bug sprint
Component: authentication Version: 0.7.0
Keywords: special characters accentuated login password Cc:

Description

Hello,

I can't log to my SSH account with accentuated characters in swish.
I works fine with other accounts, with easier passwords.

I had the same issue with PUTTY, under windows, but PUTTY let me change the CHARSET parameter ( iso-9660 ) or something so the password and login could be typed with special characters in it ( accentuated in my case)

Could you fix that ? Or tell how to parameter this in swish, I haven't figured it out.

Regards.

Pierre

Change History

comment:1 Changed 7 years ago by alamaison

Is it your username or your password (or both) that is using accented characters?

SSH specifies that these are sent as UTF-8 and that's how Swish transmits what you type so perhaps there is a bug in your server.

What SSH server are you connecting to? On what operating system?

comment:2 Changed 7 years ago by piotr@regne.net

Hello,

only my password uses accentuated characters.
I made a mistake, the charset I set in putty to have it work is : ISO-8859-1:1998 (Latin-1, West Europe).

My server is an ubuntu server, I host at home and openssh-server is the ssh server.
I have no issue at all when I am under linux and open SFTP connexion or ssh ones in the shell
nor with putty with the "West europe" Charset under windows.

comment:3 Changed 7 years ago by piotr@regne.net

Anyway, I've just check my locale under my server it is set to

LANG=fr_FR.UTF-8

so this is UTF-8

comment:4 Changed 7 years ago by alamaison

  • Priority changed from blocker (cannot release, e.g. data loss) to minor (e.g. uncommon, cosmetic, has workaround)
  • Status changed from new to accepted

Interesting, I will try to reproduce this but it'll be a few weeks before I have time.

I don't really understand why the charset setting affects anything. That should only change how the Putty terminal interprets characters which is seperate from the login process. The SSH spec doesn't allow clients to pick and choose the charset they use for authentication. Here is the relevant portion of  the spec:

8.  Password Authentication Method: "password"

   Password authentication uses the following packets.  Note that a
   server MAY request that a user change the password.  All
   implementations SHOULD support password authentication.

      byte      SSH_MSG_USERAUTH_REQUEST
      string    user name
      string    service name
      string    "password"
      boolean   FALSE
      string    plaintext password in ISO-10646 UTF-8 encoding [RFC3629]

   Note that the 'plaintext password' value is encoded in ISO-10646
   UTF-8.  It is up to the server how to interpret the password and
   validate it against the password database.  However, if the client
   reads the password in some other encoding (e.g., ISO 8859-1 - ISO
   Latin1), it MUST convert the password to ISO-10646 UTF-8 before
   transmitting, and the server MUST convert the password to the
   encoding used on that system for passwords.

Exactly how did you set this password (details are important)? Remotely from PuTTY? Locally on the terminal of the linux machine? Did you use passwd or something else?

Last edited 7 years ago by alamaison (previous) (diff)

comment:5 follow-up: ↓ 6 Changed 7 years ago by piotr@regne.net

WHat is odd, is that it works fine from Linux ... With any application. ( shell, nautilus, firefox addons, filezilla )

I use "fireftp", a firefox addon to access FTP and SFTP servers, it works fine under linux, not in the Windows version. ( same issue than swish I guess ). Other servers works well ...

Maybe something is not properly set in my Windows parameters.
I use XP professionnal, US version, in english. The regional and keyboard parameters are set to FRENCH.

The password was set on the server directly, with passwd.

The causing problem character is ù. I have the dollar symbol elsewhere in the password but this one is not blocking, as it works for other servers where I used it too ...

If I figure how this is happening, I will let you know too.

Thank you for your time.

comment:6 in reply to: ↑ 5 Changed 7 years ago by alamaison

Replying to piotr@…:

WHat is odd, is that it works fine from Linux ... With any application. ( shell, nautilus, firefox addons, filezilla )

Exactly. Odd.

I use "fireftp", a firefox addon to access FTP and SFTP servers, it works fine under linux, not in the Windows version. ( same issue than swish I guess ). Other servers works well ...

Maybe something is not properly set in my Windows parameters.
I use XP professionnal, US version, in english. The regional and keyboard parameters are set to FRENCH.

Ok, just to double check this, open Notepad, type ù, use Save As to save the file as UTF-8, close the file, open it again (make sure it is opened as UTF-8). Does it look ok? If so I think your Windows config is ok.

The password was set on the server directly, with passwd.

Interesting. Do you know what the locale was set to at the time you set this password. Was it fr_FR.UTF-8?

The causing problem character is ù. I have the dollar symbol elsewhere in the password but this one is not blocking, as it works for other servers where I used it too ...

It would be helpful if you could test how your linux machine is interpreting your keystrokes under the same circumstances under which you set the password.

Could you log into you Ubuntu box using the same command line environment you used to set the password (or even set the password again so the circumstances match).

Then type touch ù to create a file with that filename.

Does the character show up correctly when you type it?

If you type ls, does the filename show correctly?

If you now change the password to something that Swish can log in as and you look at the directory with Swish, does Swish display the filename correctly?

How about with PuTTY if you ask it to use UTF-8 as the charset (not Western Europe)?

If I figure how this is happening, I will let you know too.

Thanks for helping.

comment:7 follow-up: ↓ 8 Changed 7 years ago by lanagram

Hello Alamaison,
I have exactly the same problem.
I attempt to connect on my private network on a ssh server hosted by ubuntu from a Windows vista computer (passwords set on the server using passwd). I have some problems of special characters encoding between windows and linux ssh server. Using PuTTY, I can connect to my SSH server provided I select the UTF-8 encoding as remote character set, I can either transfert files using Filezilla in ssh/FTP mode. Is it possible to add an option to select the remote character set in the same way than in PuTTY or a configuration interface for the connection ?
Thanks in advance, except this small problem to fix Swish-ftp is a really nice software.
Regards

comment:8 in reply to: ↑ 7 Changed 7 years ago by alamaison

Replying to lanagram:

I attempt to connect on my private network on a ssh server hosted by ubuntu from a Windows vista computer (passwords set on the server using passwd). I have some problems of special characters encoding between windows and linux ssh server.

What is the locale on your linux SSH server?
How did you use passwd, while logged in remotely using PuTTY or from a keyboard directly attached to the linux server?

Using PuTTY, I can connect to my SSH server provided I select the UTF-8 encoding as remote character set, I can either transfert files using Filezilla in ssh/FTP mode.

So what happens with Swish? It won't let you log in? Are the non-ASCII characters in your username or your password? Can you give an example of a character that causes your problem.

Is it possible to add an option to select the remote character set in the same way than in PuTTY or a configuration interface for the connection ?

Even if we did, it doesn't sound like it would solve your problem because Swish already uses UTF-8 for the username and password. The SSH protocol requires it so I'm puzzled that the PuTTY setting can change this. PuTTY's setting exists because you log into a text terminal which can use any character encoding. Swish doesn't have a terminal.

comment:9 Changed 7 years ago by Lanagram

Hello,
On my home network I have a Windows Vista client and a Ubuntu 12.04 ssh server. I use mainly the server for backups. I have no problem for accessing the server from a remote client (in both case, remote access from internet or from the home network client). Connection with PuTTY or file transfers with Filezilla installed on Vista (provided I use the UTF-8 encoding option) work fine.

A small exemple, if I attempt to connect using PuTTY from the Vista client without the UTF-8 option, sshd writes the following lines in the /var/log/auth.log logfile read on the Ubuntu server:

Dec 17 13:10:31 VistaClient sshd[2101]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ComputerName  user=UserName
Dec 17 13:10:33 VistaClient sshd[2101]: Failed password for UserName from XXX.XXX.XXX.XXX port YYYY ssh2
Dec 17 13:10:44 VistaClient sshd[2101]: Received disconnect from XXX.XXX.XXX.XXX: 13: Unable to authenticate [preauth]

Now these are the lines of the log file for a unsuccessfull Swish access request for a password which includes special characters:

Dec 19 12:21:11 VistaClient sshd[3404]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ComputerName  user=UserName2
Dec 19 12:21:13 VistaClient sshd[3404]: Failed password for UserName2 from XXX.XXX.XXX.XXX port YYYY ssh2
Dec 19 12:21:35  sshd[3404]: last message repeated 2 times
Dec 19 12:21:35 VistaClient sshd[3404]: Received disconnect from XXX.XXX.XXX.XXX: 11: Swish says goodbye. [preauth]
Dec 19 12:21:35 VistaClient sshd[3404]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=ComputerName user=UserName2

And for a succesfull access of Swish for a password without special caracters:

Dec 19 12:10:30 VistaClient sshd[3177]: Accepted password for UserName from XXX.XXX.XXX.XXX port YYYY ssh2
Dec 19 12:10:30 VistaClient sshd[3177]: pam_unix(sshd:session): session opened for user UserName by (uid=0)
Dec 19 12:10:34 VistaClient sshd[3376]: subsystem request for sftp by user UserName
Dec 19 12:14:39 VistaClient sshd[3177]: pam_unix(sshd:session): session closed for user UserName

Actually special caracters are located in the passwords of the different users, the characters which are not well translated are ù µ § by exemple. The usernames do not include any of this characters.

The way the command "passwd" is used has not effect on password's acceptation or rejection, whether the password is set directly on keyboard attached in a local shell on the Ubuntu server or through a remote shell using a SSH client on linux or PuTTY on Vista. I already changed sometimes the passwords remotely, and succeded to do Rsync transfers with my Ubuntu laptop from abroad.

The following is maybe out of the scope of the discusion: I would like to use Swish to work with Cobian Backup in order to make easyly backups. It failed as I put the path of the Swish connection copied in Explorer adress bar in the target folder of Cobian. I tried with the DokanSSHFS, and this works well (but DokanSSHFS fails for surfing on the symbolic links, Swish don't :-) ). An other suggestion of enhencement should be to be able to browse a batch of pictures or read directly MP3 stored on the remote folder like on a local folder.

Merci encore une fois pour ta réponse, et bon courage pour que ton projet, déjà en très bonne voie, devienne parfaitement fonctionnel. Bonnes fêtes de fin d'année.

comment:10 Changed 7 years ago by Lanagram

PS: I use a Ubuntu distro configured in the standard french translation.

comment:11 Changed 7 years ago by alamaison

  • Priority changed from minor (e.g. uncommon, cosmetic, has workaround) to major (affects peripheral workflow)

Thanks for all the feedback. I've found the source of the problem.

It turns out that some very old code in the core of Swish is not properly converting usernames and passwords to UTF8. This will be fixed in the next release.

comment:12 Changed 7 years ago by alamaison

  • Priority changed from major (affects peripheral workflow) to critical (affects core workflow)

comment:13 Changed 7 years ago by Alexander Lamaison

  • Status changed from accepted to closed
  • Resolution set to fixed

Fixed bug with unicode characters in password.

We weren't converting the username and password to UTF-8 and, instead, used the local Windows codepage. SSH requires that they be encoded as UTF-8, so users that tried to use a password with non-ASCII characters in could not log in.

Fixes #213.

Changeset: 840a37f493bc804aec389e469e5f6c882ce1e7b7

comment:14 Changed 7 years ago by Alexander Lamaison

Fixed bug with unicode characters in password.

We weren't converting the username and password to UTF-8 and, instead, used the local Windows codepage. SSH requires that they be encoded as UTF-8, so users that tried to use a password with non-ASCII characters in could not log in.

Fixes #213.

Changeset: 840a37f493bc804aec389e469e5f6c882ce1e7b7

comment:15 follow-ups: ↓ 18 ↓ 19 Changed 7 years ago by piotr@regne.net

Glad to ear that :)

May you produce a nightly built version sometimes ?

Regards.

comment:16 Changed 7 years ago by alamaison

In [840a37f493bc804aec389e469e5f6c882ce1e7b7/swish]:

Fixed bug with unicode characters in password.

We weren't converting the username and password to UTF-8 and, instead, used the local Windows codepage. SSH requires that they be encoded as UTF-8, so users that tried to use a password with non-ASCII characters in could not log in.

Fixes #213.

comment:17 Changed 7 years ago by alamaison

In [840a37f493bc804aec389e469e5f6c882ce1e7b7/swish]:

Fixed bug with unicode characters in password.

We weren't converting the username and password to UTF-8 and, instead, used the local Windows codepage. SSH requires that they be encoded as UTF-8, so users that tried to use a password with non-ASCII characters in could not log in.

Fixes #213.

comment:18 in reply to: ↑ 15 Changed 7 years ago by alamaison

Replying to piotr@…:

May you produce a nightly built version sometimes ?

Building Swish is not as easy as we would like and I don't have this machine set up to do a proper release. Nevertheless, I might try and do so if I get time over the weekend.

comment:19 in reply to: ↑ 15 Changed 7 years ago by alamaison

Replying to piotr@…:

Glad to ear that :)

May you produce a nightly built version sometimes ?

New build with the bugfix  just release as 0.7.2. Reopen this ticket if the bug isn't fixed.

comment:20 Changed 7 years ago by piotr@regne.net

This works flawlessly. ( In my case )

Thank you !!

That's a nice present for Christmas :S



Pierre

Note: See TracTickets for help on using tickets.