SSH push fails when LANG and LC_* is sent

Issue #369 closed
Benny Prange created an issue

Hi everyone,

when I am trying to push my commits to the mercurial repository, I get the error message “ssh abort: no suitable response from remote hg!”. This is fixed when I edit my local “/etc/ssh/ssh_conf” and remove the line “SendEnv LANG LC_*”.

I am using Ubuntu 16.04 LTS and hg 5.3.2, the server is running Kallithea 0.5.2 on Debian Buster.

The server's “/etc/ssh/sshd_config” contains the line “AcceptEnv LANG LC_*”. Therefore my guess is that Kallithea is responsible for sending the error message.

Comments (8)

  1. Mads Kiilerich

    Try to look at the end of your .ini file and try to set [ssh_serve:logger_root] level = DEBUG and see what that reports on the client side - especially at the very end (if anything).

    It might be related to - what ssh_locale do you have in your .ini? Should we perhaps overrule some additional LC_* ?

    What do you get when you ssh without kallithea in autorized_keys when running

    ssh user@server 'python -c "import os;print(os.environ)"'

  2. André Klitzing

    We don’t get any special debug output if we switch to level=DEBUG.

    ssh_locale = en_GB.UTF-8

    {'LANG': 'en_GB.UTF-8', 'SHELL': '/bin/bash', 'XDG_RUNTIME_DIR': '/run/user/1062201243', 'LANGUAGE': 'en_GB:en', 'MAIL': '/var/mail/USERNAME', 'SHLVL': '0', 'SSH_CLIENT': ' 59694 22', 'XDG_SESSION_TYPE': 'tty', 'PWD': '/home/company.local/USERNAME', 'LOGNAME': 'USERNAME', 'USER': 'USERNAME', 'PATH': '/usr/local/bin:/usr/bin:/bin:/usr/games', 'HOME': '/home/company.local/USERNAME', 'SSH_CONNECTION': ' 59694 22', 'XDG_SESSION_ID': '30573', 'XDG_SESSION_CLASS': 'user', '_': '/usr/bin/python'}

  3. André Klitzing

    ssh -vv

    debug1: Sending environment. debug1: Sending env LANG = de_DE.UTF-8 debug1: Sending env LC_CTYPE = de_DE.UTF-8 debug1: Sending command: hg -R Group/Reponame serve --stdio

  4. Mads Kiilerich

    What do you get if you make a plain non-hg ssh matching the authorizedkeys?

    If you set ssh_enabled=false, do you get SSH access is disabled.?

    Does it make a difference if you in kallithea/bin/ set LC_CTYPE as it sets LC_ALL?

  5. Mads Kiilerich

    Perhaps first of all: try to add `import sys;sys.stderr.write('hello\n')` right after the #! line in kallithea-cli and see if that shows up when ssh’ing.

    If not, experiment with editing authorizedkeys to see if it is possible to launch other (python) commands.

    If it shows up, try to add it elsewhere to see how far Kallithea gets started before the sudden death.

  6. Thomas De Schampheleire

    I don’t think setting LC_CTYPE explicitly if LC_ALL is already set, in can make a difference.

    See e.g. following tests to verify behavior of LC_ALL:

    $ date                                                                                                                                                                                                                          
    Mon 27 Apr 2020 10:33:48 PM CEST
    $ env LC_TIME=C.utf8 date                                                                                                                                                                                                       
    Mon Apr 27 22:33:59 CEST 2020
    $ env LC_TIME=en_US.utf8 date                                                                                                                                                                                                   
    Mon 27 Apr 2020 10:34:04 PM CEST
    $ env LC_TIME=en_US.utf8 LC_ALL=C.utf8 date                                                                                                                                                                               
    Mon Apr 27 22:34:17 CEST 2020

    So whenever LC_ALL is set, it takes precedence. This is in line with ‘man 7 locale':

           If the second argument to setlocale(3) is an empty string, "", for the default locale, it is determined using the following steps:
           1. If there is a non-null environment variable LC_ALL, the value of LC_ALL is used.
           2. If an environment variable with the same name as one of the categories above exists and is non-null, its value is used for that category.
           3. If there is a non-null environment variable LANG, the value of LANG is used.

    What I don’t understand from the information so far:

    • the client has locale de_DE.utf8 and uses SendEnv
    • the server has locale en_GB.utf8 and uses AcceptEnv
    • then why does the output you showed of ‘print(os.environ)’ not show de_DE.utf ? Note that this test completely excludes Kallithea.

    Does the server actually have the de_DE.utf8 locale installed? (`locale -a`)

    If it does not, I can imagine something going wrong. In the kallithea-cli process, this case is intended to be covered by the changes in commit b5b91e854308 as mentioned by @kiilerix. But, this only works if ‘ssh_locale’ is correctly (uncommented) set in the ini file referenced in the authorized_keys file (Note that the ini file is explicitly specified in the authorized_keys file, so it must be correct, if not you have to regenerate authorized_keys).

  7. Thomas De Schampheleire

    Closing because we believe there is no code issue and there is no further feedback to contradict this.

  8. Log in to comment