Community Blog Advanced OpenSSH Features to Harden Access to Your Alibaba Cloud ECS

Advanced OpenSSH Features to Harden Access to Your Alibaba Cloud ECS

In this article, we will go through all necessary SSH configurations that can be used to secure our ECS instances in a production environment.

By Anish Nath, Alibaba Cloud Tech Share Author. Tech Share is Alibaba Cloud's incentive program to encourage the sharing of technical knowledge and best practices within the cloud community.

In this article, we will go through all necessary SSH configurations that can be used to secure our Alibaba Cloud Elastic Compute Service (ECS) instances in a production environment.

When you log in to Alibaba Cloud Linux ECS instance using SSH

ssh root@[EIP address of the instance].

You will see the following message, you have successfully connected to an instance.

Welcome to Alibaba Cloud Elastic Compute Service !

Note: The default user is root which needs to be disabled (not the preferred way of accessing production system) so let's put a privilege escalation method such as sudo and then be used to execute commands as root.

However, this is not sufficient for most production environment. For better SSH security, we will cover various SSH secure parameter that needs to be audited/configured for the production environment.

Hardening ECS with OpenSSH

The OpenSSH server reads a configuration file from /etc/ssh/sshd_config when it's started. The default values for /etc/ssh/sshd_config in OpenSSH are quite restrictive and need to be further tuned to meet the demand of the current security need for the production environment and being compliance with governance requirement like PCI/DSS, HIPPA etc.

You will need to be root or use sudo to edit and control the SSH server.

Usually this is done by editing the default configuration file to change and more harden configuration for example.

It is always a good idea to make a backup of any configuration files before editing them.

cp /etc/ssh/sshd_config /etc/ssh/backup.sshd_config

To disable passwords for root, but still allow key-based access without forced command, use:

PermitRootLogin prohibit-password

To disable passwords and only allow key-based access with a forced command, use:

PermitRootLogin forced-commands-only

To disable root login for the key-based access also and prompting the message

no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="echo 'Please login as the user \"alibabacloud\" rather than the user \"root\".';echo;sleep 10" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDePRIy/ ECS 

The /etc/ssh/moduli

The /etc/ssh/moduli file usually contains several different entries called groups and sshd picks one randomly for each session. As shown in the below diagram the 1024 bits simply don't offer sufficient security margin.


OpenSSH supports 13 key exchange methods

SL No Key Exchange Method Name Implement
1 curve25519-sha256 SHOULD
2 diffie-hellman-group-exchange-sha1 MUST NOT
3 diffie-hellman-group1-sha1 MUST NOT
4 diffie-hellman-group14-sha1 SHOULD-
5 diffie-hellman-group14-sha256 MUST
6 diffie-hellman-group16-sha512 SHOULD
7 ecdh-sha2-nistp256 SHOULD
8 ecdh-sha2-nistp384 SHOULD
9 gss-gex-sha1-* MUST NOT
10 gss-group1-sha1-* MUST NOT
11 gss-group14-sha1-* SHOULD
12 gss-group14-sha256-* SHOULD
13 gss-group16-sha512-* SHOULD
14 rsa1024-sha1 MUST NOT

If option 4 is selected then delete the lines from the 5th column from the file /etc/ssh/moduli where bit size is less than 2000

awk '$5 > 2000' /etc/ssh/moduli > "${HOME}/moduli"
wc -l "${HOME}/moduli" # make sure there is something left
mv "${HOME}/moduli" /etc/ssh/moduli

If this file doesn't exist then generate a strong DH key size, higher bit size means more secure keys and less likely to break

ssh-keygen -G /etc/ssh/moduli.all -b 4096
ssh-keygen -T /etc/ssh/moduli.safe -f /etc/ssh/moduli.all
mv /etc/ssh/moduli.safe /etc/ssh/moduli
rm /etc/ssh/moduli.all

Recommended KexAlgorithms /etc/ssh/sshd_config :

KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

Allow/Deny rules

You should consider using Allow/Deny rules as a means of SSH access control mechanism. Once you add one AllowUsers rule, then the only users allowed to login via SSH are the listed ones:

User Based Logins

AllowUsers ecs
AllowUsers ecs2 

Host based Logins

AllowUsers *@mywebserver.alibabacloud.com
AllowUsers *@myprovisioningserver. alibabacloud.com 

Domain Based Logins

AllowUsers *@*. alibabacloud.com 

Black List with PAM

pam_abl is a pam module designed to automatically block hosts who are attempting a brute force attack

# /etc/security/pam_abl.conf

*:10/1h,30/1d: means block any user (*) if they are responsible for ten or more failed authentication attempts in the last hour or thirty or more failed attempts in the last day.


Chroot is "an operation that changes the apparent root directory for the current running process and its children." This will give a client access to the server, but limit those users to their home directories, and it's a powerful feature and serve many secure use case like to chroot an SFTP directory.

Create an user and force root to be owner of it

cd /home
mkdir ftp
useradd -d /home/ftp -M -N -g users ftp
sudo chown root:root /home/ftp
sudo chmod 755 /home/ftp

Change the subsystem location on /etc/ssh/sshd_config:

#Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp

and create a user section at the end of the file

Match User john
    ChrootDirectory /home/ftp
    ForceCommand internal-sftp
    AllowTCPForwarding no
    X11Forwarding no

Password, Authentication, and Encryption

You can encrypt your SSH connection by running the SSHv2 Protocol.
Force SSHv2 Protocol

Protocol 2

HostKeys for Protocol Version 2

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key

Use Secure Ciphers and MACs

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

Disable Unused Authentication Schemes

RhostsRSAAuthentication no
HostbasedAuthentication no
ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no

Disable Root SSH access

PermitRootLogin no
PermitEmptyPasswords no

Public Key Authentication and Password Authentication

The following options lets you control the types of authentications available for use. You can tune it according to your environment, such as using only key based authentication instead of password for extra security.

RSAAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication yes
AuthenticationMethods publickey,password

Enable Logging

Logging provide traceability and enable the audit for the users.

SyslogFacility AUTH
LogLevel INFO

Authentication Time
You can adjust the time it takes for authentication to happen. In this example, we will limit it to 20 seconds.

LoginGraceTime 20

Reduce Timeout Intervals

# Sets a timeout interval in seconds, default is 15 
ClientAliveInterval 40

# Sets the number of client alive messages, default value is 3 
ClientAliveCountMax 3

Deny Empty Password
You can force all logins to require a password.

# Don't allows login to accounts with empty password, The default value is no
passworPermitEmptyPasswords no


Fail2ban can scan logs and ban temporarily ban IPs based on possible malicious activity. You will need to install Fail2ban.

sudo apt-get install fail2ban
sudo yum install fail2ban

copy the fail2ban configuration file.

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Open the /etc/fail2ban/jail.local files and find the spot that starts [sshd]. Edit it like so, adding enabled = true:

enabled  = true
port    = ssh
logpath = %(sshd_log)s

Then restart fail2ban

service fail2ban restart

Fail2ban will monitor your SSH logs for possible malicious activity and then temporarily ban the source IP.

List Down Current Ciphers

$ ssh -Q cipher

List Down Supported MAC's

[root@localhost ~]# ssh -Q mac

List Down Supported Keys

$ ssh -Q  key

Restart SSHD

Any changes in the file /etc/ssh/sshd_config requires restart of the SSH service.

/sbin/service sshd restart

/etc/init.d/sshd restart

Automating the Process

Because ystems will added/deleted over the time, you should consider using automation when the inventory is changing rapidly. Automation of SSH-key management include:

  1. Automated discovery of all SSH keys and configuration information
  2. Automation of adding, configuring, removing, and rotating SSH keys
  3. Provide continuous monitoring of SSH keys
  4. Enable forensic-level analysis by logging of all relevant operations and management actions
  5. Audit

You should also consider other forms of automation, such as automating security group updates on Alibaba Cloud.


Additional reading materials about OpenSSH and sshd_config can be found at:

  1. OpenSSH website
  2. sshd_config man page
  3. SSH tests from Lynis project
0 0 0
Share on

Alibaba Clouder

2,600 posts | 754 followers

You may also like