by Anish
Posted on Thursday January 24
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 | gss-gex-sha1-* | MUST NOT |
9 | gss-group1-sha1-* | MUST NOT |
10 | gss-group14-sha1-* | SHOULD |
11 | gss-group14-sha256-* | SHOULD |
12 | gss-group16-sha512-* | SHOULD |
13 | rsa1024-sha1 | MUST NOT |
If option 4 is selected then delete the lines from the 5thcolumn 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 [email protected],diffie-hellman-group-exchange-sha256
Do consider 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 user1
AllowUsers user2
Host based Logins
AllowUsers *@mywebserver.xyz.com
AllowUsers *@myprovisioningserver.xyz.com
Domain Based Logins
AllowUsers *@*.xyz.com
pam_abl is a pam module designed to automatically block hosts which 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.
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
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr
MACs [email protected],[email protected],[email protected],hmac-sha2-512,hmac-sha2-256,[email protected]
RhostsRSAAuthentication no
HostbasedAuthentication no
ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no
PermitRootLogin no
PermitEmptyPasswords no
Tune it according to your environment like only key based authentication
RSAAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication yes
AuthenticationMethods publickey,password
Logging provide traceability and enable the audit for the users.
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 20
# Sets a timeout interval in seconds, default is 15
ClientAliveInterval 40
# Sets the number of client alive messages, default value is 3
ClientAliveCountMax 3
# 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.
$ ssh -Q cipher
3des-cbc
blowfish-cbc
cast128-cbc
arcfour
arcfour128
arcfour256
aes128-cbc
aes192-cbc
aes256-cbc
[email protected]
aes128-ctr
aes192-ctr
aes256-ctr
[email protected]
[email protected]
[email protected]
[root@localhost ~]# ssh -Q mac
hmac-sha1
hmac-sha1-96
hmac-sha2-256
hmac-sha2-512
hmac-md5
hmac-md5-96
hmac-ripemd160
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
$ ssh -Q key
ssh-ed25519
[email protected]
ssh-rsa
ssh-dss
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
Systems will added/deleted over the time, when the inventory is changing rapidly , go towards automation of the SSH-key management which 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.
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
if i Missed out any rules, post a comment, I will add in the List
Generate SSH Key Online (RSA/DSA/ECDSA)
Thanku for reading !!! Give a Share for Support
Instead of directly asking for donations, I'm thrilled to offer you all nine of my books for just $9 on leanpub By grabbing this bundle you not only help cover my coffee, beer, and Amazon bills but also play a crucial role in advancing and refining this project. Your contribution is indispensable, and I'm genuinely grateful for your involvement in this journey!
Any private key value that you enter or we generate is not stored on this site, this tool is provided via an HTTPS URL to ensure that private keys cannot be stolen, for extra security run this software on your network, no cloud dependency