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.
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
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
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
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.
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
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
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.
#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
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
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:
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:
2,599 posts | 762 followers
FollowAlibaba Clouder - June 18, 2019
- November 14, 2017
Alibaba Clouder - May 29, 2018
francisndungu - October 26, 2018
Alibaba Clouder - May 22, 2019
Alibaba Clouder - July 15, 2019
2,599 posts | 762 followers
FollowElastic and secure virtual cloud servers to cater all your cloud hosting needs.
Learn MoreYou can use Certificate Management Service to issue, deploy, and manage public and private SSL/TLS certificates.
Learn MoreA cloud firewall service utilizing big data capabilities to protect against web-based attacks
Learn MoreMore Posts by Alibaba Clouder