Posts Tagged ‘SSH’

Changing the locale in Ubuntu Server

Wednesday, April 3rd, 2019

When logging into any cPanel server via SSH from an Ubuntu jump server I was seeing some strange warnings from Perl which I didn’t see when logging in from my laptop running macOS:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = “C.UTF-8”
are supported and installed on your system.
perl: warning: Falling back to the standard locale (“C”).
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = “C.UTF-8”
are supported and installed on your system.
perl: warning: Falling back to the standard locale (“C”).
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = “C.UTF-8”
are supported and installed on your system.
perl: warning: Falling back to the standard locale (“C”).

After a quick rummage, I found that the reason was that the “LANG” environment variable on my laptop was defaulting to “en_GB.UTF-8”, whilst on the Ubuntu jump server it was “C.UTF-8”.

The cPanel server runs some Perl stuff when bash starts and if it doesn’t like your locale settings, then it spits out these warnings.

The “LANG” environment variable is part of the locale system and so the best way to fix this is to update the locale settings configured on the Ubuntu jump server.

By default, SSH on both macOS and Ubuntu is configured to send the local “LANG” and “LC_*” environment variables used for locale settings to the remote system.

You can use the “locale” command to see your current locale settings as well as “locale -a” to see installed locales.

$ locale
LANG=C.UTF-8
LANGUAGE=
LC_CTYPE=”C.UTF-8″
LC_NUMERIC=”C.UTF-8″
LC_TIME=”C.UTF-8″
LC_COLLATE=”C.UTF-8″
LC_MONETARY=”C.UTF-8″
LC_MESSAGES=”C.UTF-8″
LC_PAPER=”C.UTF-8″
LC_NAME=”C.UTF-8″
LC_ADDRESS=”C.UTF-8″
LC_TELEPHONE=”C.UTF-8″
LC_MEASUREMENT=”C.UTF-8″
LC_IDENTIFICATION=”C.UTF-8″
LC_ALL=

$ locale -a
C
C.UTF-8
POSIX
en_US.utf8

In my case I wanted to use en_GB.utf8, which wasn’t installed. You can use the “locale-gen” command to generate locales, but they are also provided in official Ubuntu packages , so I installed the “language-pack-en” package from the Ubuntu repositories using APT.
This added several English locales and then I could reconfigure Ubuntu to use the one that I needed.

$ apt-get install language-pack-en
Reading package lists… Done
Building dependency tree
Reading state information… Done
The following additional packages will be installed:
language-pack-en-base
The following NEW packages will be installed:
language-pack-en language-pack-en-base
0 upgraded, 2 newly installed, 0 to remove and 3 not upgraded.
Need to get 420 kB of archives.
After this operation, 3756 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 language-pack-en-base all 1:18.04+20180712 [419 kB]
Get:2 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 language-pack-en all 1:18.04+20180712 [1904 B]
Fetched 420 kB in 0s (3606 kB/s)
Selecting previously unselected package language-pack-en-base.
(Reading database … 50814 files and directories currently installed.)
Preparing to unpack …/language-pack-en-base_1%3a18.04+20180712_all.deb …
Unpacking language-pack-en-base (1:18.04+20180712) …
Selecting previously unselected package language-pack-en.
Preparing to unpack …/language-pack-en_1%3a18.04+20180712_all.deb …
Unpacking language-pack-en (1:18.04+20180712) …
Setting up language-pack-en (1:18.04+20180712) …
Setting up language-pack-en-base (1:18.04+20180712) …
Generating locales (this might take a while)…
en_AG.UTF-8… done
en_AU.UTF-8… done
en_BW.UTF-8… done
en_CA.UTF-8… done
en_DK.UTF-8… done
en_GB.UTF-8… done
en_HK.UTF-8… done
en_IE.UTF-8… done
en_IL.UTF-8… done
en_IN.UTF-8… done
en_NG.UTF-8… done
en_NZ.UTF-8… done
en_PH.UTF-8… done
en_SG.UTF-8… done
en_ZA.UTF-8… done
en_ZM.UTF-8… done
en_ZW.UTF-8… done
Generation complete.

$ locale -a
C
C.UTF-8
en_AG
en_AG.utf8
en_AU.utf8
en_BW.utf8
en_CA.utf8
en_DK.utf8
en_GB.utf8
en_HK.utf8
en_IE.utf8
en_IL
en_IL.utf8
en_IN
en_IN.utf8
en_NG
en_NG.utf8
en_NZ.utf8
en_PH.utf8
en_SG.utf8
en_US.utf8
en_ZA.utf8
en_ZM
en_ZM.utf8
en_ZW.utf8
POSIX
$ update-locale LANG=en_GB.utf8

The locale settings are stored in “/etc/default/locale“, so you can either edit this file manually or use the handy “update-locale” utility to do it for you.
Either way, once you start a new session, you are using the new locale settings and Perl no longer complains when you SSH to a cPanel server.

ProCurve SSH – no matching cipher found

Monday, September 24th, 2018

I recently ran into a strange problem where I suddenly couldn’t SSH to any of our HPE ProCurve 2800 series (2824, 2848) devices from either macOS or Linux. I’m still not really sure what started this as OpenSSH definitely hasn’t been updated recently on the Linux client device at the very least, so I don’t see any reason for the list of ciphers supported on the client to have changed.

Anyway, the error message given by the OpenSSH client was:

Unable to negotiate with port 22: no matching cipher found. Their offer: des,3des-cbc

These ProCurves are pretty old and their SSH support is rather limited (1024 bit keys for example), so it’s not hugely surprising that their supported ciphers are also old and crappy.
Luckily, with OpenSSH you can specify the cipher(s) that you want to use on the command line when you’re connecting:

ssh -c 3des-cbc

This fixed the issue and lets me connect, but isn’t particularly convenient. However, you can also specify this in your ~/.ssh/config file so that it is applied automatically:

Host <blah>
Ciphers 3des-cbc

Just enter one or more hosts to match against (separated by spaces) and OpenSSH will automatically apply the specified options when connecting to any of them.

SSH on a HP ProCurve

Sunday, July 4th, 2010

By default HP ProCurve devices (like most switches) use telnet and TFTP (Trivial File Transfer Protocol) for management access, firmware upgrades and config backups. As these are both unencrypted protocols, it is a good idea to switch to using SSH and SCP/SFTP in order to secure your management access and all important configuration, which you can do with the following commands from configure mode:

crypto key generate ssh
ip ssh
ip ssh version 2
ip ssh filetransfer

This generates the keys that SSH requires, forces SSH to use the newer version two of the protocol and enables SCP/SFTP support for copying files to and from the flash.

As soon as you enable SSH filetransfer (basically SCP/SFTP) support then TFTP is disabled, but you have to disable telnet access manually in configuration mode with:

no telnet-server