Advanced OpenSSH Features to Harden Access to Your Alibaba Cloud ECS

6 min readJan 16, 2019

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 sudoand 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 NoKey Exchange Method NameImplement1curve25519-sha256SHOULD2diffie-hellman-group-exchange-sha1MUST NOT3diffie-hellman-group1-sha1MUST NOT4diffie-hellman-group14-sha1SHOULD-5diffie-hellman-group14-sha256MUST6diffie-hellman-group16-sha512SHOULD7ecdh-sha2-nistp256SHOULD8ecdh-sha2-nistp384SHOULD9gss-gex-sha1-*MUST NOT10gss-group1-sha1-*MUST NOT11gss-group14-sha1-*SHOULD12gss-group14-sha256-*SHOULD13gss-group16-sha512-*SHOULD14rsa1024-sha1MUST 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
debug
host_db=/var/lib/abl/hosts.db
host_purge=2d
host_rule=*:10/1h,30/1d
user_db=/var/lib/abl/users.db
user_purge=2d
user_rule=!root:10/1h,30/1d

*: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.

ChrootDirectory

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

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

#ubutnu
sudo apt-get install fail2ban
#rhel/centos
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:

[sshd]
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
3des-cbc
blowfish-cbc
cast128-cbc
arcfour
arcfour128
arcfour256
aes128-cbc
aes192-cbc
aes256-cbc
rijndael-cbc@lysator.liu.se
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com
chacha20-poly1305@openssh.com

List Down Supported MAC’s

[root@localhost ~]# ssh -Q mac
hmac-sha1
hmac-sha1-96
hmac-sha2-256
hmac-sha2-512
hmac-md5
hmac-md5-96
hmac-ripemd160
hmac-ripemd160@openssh.com
umac-64@openssh.com
umac-128@openssh.com
hmac-sha1-etm@openssh.com
hmac-sha1-96-etm@openssh.com
hmac-sha2-256-etm@openssh.com
hmac-sha2-512-etm@openssh.com
hmac-md5-etm@openssh.com
hmac-md5-96-etm@openssh.com
hmac-ripemd160-etm@openssh.com
umac-64-etm@openssh.com
umac-128-etm@openssh.com

List Down Supported Keys

$ ssh -Q  key
ssh-ed25519
ssh-ed25519-cert-v01@openssh.com
ssh-rsa
ssh-dss
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
ssh-rsa-cert-v01@openssh.com
ssh-dss-cert-v01@openssh.com
ecdsa-sha2-nistp256-cert-v01@openssh.com
ecdsa-sha2-nistp384-cert-v01@openssh.com
ecdsa-sha2-nistp521-cert-v01@openssh.com

Restart SSHD

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

#rhel/centos
/sbin/service sshd restart#ubuntu 
/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:

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

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

References

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

Reference:https://www.alibabacloud.com/blog/advanced-openssh-features-to-harden-access-to-your-alibaba-cloud-ecs_594352?spm=a2c41.12499061.0.0