Home
|
FAQ
|
Feedback
|
Licence
|
Updates
|
Mirrors
|
Keys
|
Links
|
Team
Download:
Stable
·
Pre-release
·
Snapshot
|
Docs
|
Privacy
|
Changes
|
Wishlist
All of the human-readable and human-supplied strings in SSH-2, including user names, passwords, banners, and error messages, are specified to be encoded in UTF-8. PuTTY currently ignores this and uses whatever character-set the terminal happens to be configured to use instead. This is likely to cause trouble with passwords containing non-ASCII characters, for instance.
Fixing this is relatively easy in PuTTY, where it's possible for the SSH code to poke around in the terminal's state. It's not so easy for plink and PSFTP, which will need to gain an understanding of character sets.
The OpenSSH client, which has much the same problem as plink, doesn't attempt to have an opinion on character sets (at least as of 5.1p1); everything will work according to the standard if the user's terminal is in UTF-8 mode, and not otherwise, regardless of the locale that OpenSSH is running in.
So it's possible to end up with a setup that mostly works but strictly breaches the standard. For instance, a multi-hop scenario where the user's terminal is in ISO-8859-1, and the end server's banner (say) is also in that character set (illegally), but an intermediate client/server running the OpenSSH client (or Plink) has a UTF-8 locale, works today but would break if the intermediate client started having an opinion on character sets.
Given this, if we fix this item, will we need an option to revert to our old (non-standard) behaviour -- using the configured terminal character set -- to cope with setups that have ended up looking like this?
Update, March 2019: we still don't force interpretation of these strings as UTF-8 -- it's still up to the terminal or locale configuration -- but we've at least made our code to strip control characters from many of these strings more sophisticated; so if the server sends UTF-8 printable characters in something like an authentication prompt, and the terminal or locale are configured to accept UTF-8, the PuTTY tools will no longer gratuitously mangle them.
Update, November 2024: it's now possible to enter strings such as usernames/passwords, and have them transmitted to the server as UTF-8, in some contexts such as GUIs and the Windows console. However, this work is still incomplete (notably, saved settings are not yet Unicode-clean).