Can not ssh with tr_TR.UTF-8 locales (Bad configuration options)

Bug #1638338 reported by Numan Demirdöğen on 2016-11-01
This bug affects 4 people
Affects Status Importance Assigned to Milestone
portable OpenSSH
openssh (Ubuntu)

Bug Description

I can not ssh to any host with Turkish locales.

What I expected to happen:

    I expected that 'ssh some_host' command would successfully run.

What actually happened

    'ssh some_host' command failed with an error.

Steps to produce:

1. Open a terminal
2. Run LANG=tr_TR.UTF-8 ssh some_host

If I run ssh with tr_TR.UTF-8 locale, the first error I get is:

    $HOME/.ssh/config: line 7: Bad configuration option: Identityfile
    $HOME/.ssh/config: terminating, 1 bad configuration options

If I commend IdentityFile option from $HOME/.ssh/config file and re-run the command, I get this:

    debug1: Reading configuration data ~/.ssh/config
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: /etc/ssh/ssh_config line 19: Applying options for *
    /etc/ssh/ssh_config: line 55: Bad configuration option: gssapIauthentication
    /etc/ssh/ssh_config: line 56: Bad configuration option: gssapIdelegatecredentials
    /etc/ssh/ssh_config: terminating, 2 bad configuration options

If I commend GSSAPIAuthentication and GSSAPIDelegateCredentials option, I can ssh to a host.

So to ssh to a host with tr_TR.UTF-8 locale, one must commend out IdentityFile, if it is used, GSSAPIAuthentication and GSSAPIDelegateCredentials optons.


    LC_ALL=C ssh some_host

LC_ALL=C apt-cache policy openssh-client
  Installed: 1:7.3p1-1
  Candidate: 1:7.3p1-1
  Version table:
 *** 1:7.3p1-1 500
        500 yakkety/main amd64 Packages
        100 /var/lib/dpkg/status

LC_ALL=C lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.10
Release: 16.10
Codename: yakkety

ProblemType: Bug
DistroRelease: Ubuntu 16.10
Package: openssh-client 1:7.3p1-1
ProcVersionSignature: Ubuntu 4.8.0-26.28-generic 4.8.0
Uname: Linux 4.8.0-26-generic x86_64
ApportVersion: 2.20.3-0ubuntu8
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Nov 1 19:37:35 2016
InstallationDate: Installed on 2016-10-23 (9 days ago)
InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
 ssh-askpass N/A
 libpam-ssh N/A
 keychain N/A
 ssh-askpass-gnome N/A
SSHClientVersion: OpenSSH_7.3p1 Ubuntu-1, OpenSSL 1.0.2g 1 Mar 2016
SourcePackage: openssh
UpgradeStatus: No upgrade log present (probably fresh install)

/etc/default/locale is attached.

/etc/environment is attached.

strace of ssh

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in openssh (Ubuntu):
status: New → Confirmed

Trying to reproduce:
Xenial - all cases working with&without Identity or gsapi configs
Yakkety - login as usual works
Yakkety - Adding LANG=tr_TR.UTF-8 login still works
Yakkety - Adding LANG=tr_TR.UTF-8 and enabling Identity / gssapi configs login still works

I currently have "openssh-client 1:7.3p1-1" on my client (Yakkety).
My server was a 16.04.1 with 1:7.2p2-4ubuntu2.1

Do you have any other parts to your GSSAPI config or such that might be relevant.

If not having anything confidential please share your ~/.ssh/config and /etc/ssh/ssh_config for the error and the "fixed" case by modifying the conf files.

Changed in openssh (Ubuntu):
status: Confirmed → Incomplete

@ChristianEhrhardt, I uploded both of them.

"Do you have any other parts to your GSSAPI config or such that might be relevant."

I don't have anything like that. I event do not touch/modify/edit /etc/ssh/ssh_config file.

Thanks for uploading.
I really see nothing in your files that would cause this.
Still I reproduced your setup on my yakkety machine but run into no issues what so ever when setting tr_TR locales.

I see you also opened a askubuntu thread - linking here as FYI

ATM - I fail to reproduce, but would like to understand what is going on.

@ChristianEhrhardt, you are welcome. I thank you for trying to help me! Yes, I reported this problem in AskUbuntu, then decided to report it as a bug.

Is there a way for me to debug ssh? Or "bisect" it? I am going to try to install a previous version of ssh package.

@ChristianEhrhardt, I installed 1:7.2p2-4ubuntu2.1 version of openssh-client package from Xenial after purging 1:7.3p1-1 version. With this version, I can ssh to any host without using LC_ALL=C variable.

    ssh: connect to host port 22: Connection refused

    Permission denied (publickey).

LC_ALL=C apt-cache policy openssh-client
  Installed: 1:7.2p2-4ubuntu2.1
  Candidate: 1:7.3p1-1
  Version table:
     1:7.3p1-1 500
        500 yakkety/main amd64 Packages
 *** 1:7.2p2-4ubuntu2.1 100
        100 /var/lib/dpkg/status

Robie Basak (racb) wrote :

I'm going to leave this as Incomplete, since it isn't clear to me that this is a bug in Ubuntu at all. If you can provide steps that will produce the problem on a different system, then we can look further. Otherwise, please understand that this bug will not make progress, and that you're more likely to find people to help you outside the bug tracking system, for example in your question.

Onur Güzel (onurguzel) wrote :

I have encountered this bug today. You can reproduce it by launching ssh in Turkish locale environment:

LC_ALL=tr_TR.UTF8 ssh <email address hidden>

Ubuntu version is 16.10, and openssh-client version is 1:7.3p1-1. I guess the client converts parameters in config files to lowercase when parsing and gives error because both GSSAPIAuthentication and GSSAPIDelegateCredentials parameters has "I" character.

Turkish have two separate "i" character dotted and dotless. Per the Unicode standard, our lowercase "i" becomes "İ" (U+0130 "Latin Capital Letter I With Dot Above") when it moves to uppercase. Similarly, our uppercase "I" becomes "ı" (U+0131 "Latin Small Letter Dotless I") when it moves to lowercase.

For additional info, you can check out the links below:

This is an upstream regression very probably caused by:

I'd suggest filing it upstream at - it may
be possible to preserve the intent of the above change by substituting a
deliberately-locale-unaware version of tolower() when parsing
configuration files, or maybe just by calling setlocale() after parsing
configuration files.

 status triaged

Changed in openssh (Ubuntu):
status: Incomplete → Triaged

Thank you @Colin Watson. I reported this to the upstream. Here is the link to the bug:

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package openssh - 1:7.4p1-5

openssh (1:7.4p1-5) unstable; urgency=medium

  * Create mux socket for regression tests in a temporary directory.
  * Work around clock_gettime kernel bug on Linux x32 (closes: #849923).

 -- Colin Watson <email address hidden> Tue, 03 Jan 2017 14:43:28 +0000

Changed in openssh (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.