SSH et le codage de caractères

Une drôle de constatation que j’ai fait : le contexte est fondamental dans une session ssh, surtout quand vous développez autour.

Publié le

Le client est le Terminal d’OSX configuré en UTF-8. Le serveur est une CentOS configurée en UTF-8 Français.

$ ssh root@serveur
# locale
# LANG=fr_FR.UTF-8
# [...]

Pour le moment, tout va bien. Maintenant :

$ ssh root@serveur locale
# LANG=en_US.UTF-8
# [...]

Nous sommes passé en anglais !? Et oui : dans le premier cas, c’est le shell, ici bash, qui était exécuté, avec sa propre configuration de la session. Dans ce cas présent, c’est local qui est exécuté. Il prend par défaut les réglages de la machine, l’anglais américain (en_US).

Plus drôle encore, en utilisant une API ssh dans un code (ici jsch en Java), en exécutant directement la commande locale sur le même serveur :

# LANG=

Mmmh, c’est pas clair. Essayons locale -k charmap :

# charmap="ANSI_X3.4-1968"

En effet, nous ne sommes plus en UTF-8, mais en simple ASCII.

Si je paramètre mon client en UTF-8 en définissant la variable d’environnement de la langue avec

channel.setEnv("LANG", "UTF-8");

Le serveur me répond :

# charmap="UTF-8"

C’est gagné. Je retrouve mes accents.

Pour aller plus loin

Si vous voulez connaitre toutes les variables d’environnement qu’accepte le serveur en surcharge, regardez dans le fichier /etc/ssh/sshd_config, avec le parametre AcceptEnv.

Exemple avec mon serveur :

AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS

Lang est bien autorisé.