Overview

This document outlines several valuable modifications you can implement on your server to enhance SSH security. It is highly recommended to restrict and properly configure Secure Shell (SSH) access to secure your server effectively.

Control SSH Access

Grant SSH access only to users who genuinely require it. To revoke a user's SSH access, utilize WHM’s Manage Shell Access interface (WHM » Home » Account Functions » Manage Shell Access).

For users who need SSH access but only require access to files in their home directory, assigning a jailed shell environment is advisable. More information on jailed shells can be found in our VirtFS - Jailed Shell documentation.

Configure an SSH Legal Message

Your system can display a legal message (message of the day, or motd) to users logging into your server via SSH. To set this message, edit the /etc/motd file using your preferred text editor and save your changes. For instance, a technical analyst might use the following message:


1
2
3
4
5
6
7
ALERT! You have entered a secured area! The system has recorded
your IP and login information, and it has notified the administrator.

This system is restricted to authorized access only. All activities on
this system are recorded and logged. The system administrator will fully
investigate and report unauthorized activity to the appropriate law
enforcement agencies.

Implement SSH Keys for Authentication

Disabling password authentication for SSH on your server can compel users to log in exclusively with SSH keys. To achieve this, follow these steps:

  1. Utilize WHM’s Manage root’s SSH Keys interface (WHM » Home » Security Center » Manage root’s SSH Keys) to generate and download a key for the root user.
  2. Use WHM’s SSH Password Authorization Tweak interface (WHM » Home » Security Center » SSH Password Authorization Tweak) to disable password authentication for SSH.

Enhance SSH Security Settings

The /etc/ssh/sshd_config file contains the configuration settings for your server’s SSH service. We recommend modifying the following settings to bolster security:

  • Port — This defines the port number on which the sshd daemon listens for incoming connections. The maximum acceptable value is 49151.

    Note: It is advisable to use a privileged port between 1 and 1023 that is not currently in use by another service. Only the root user can bind to ports in this range. Unprivileged ports (1024 and greater) can be used by any user.

  • Protocol — Specifies the SSH protocol version your server uses. We recommend setting this value to 2.
  • ListenAddress — The IP address where the sshd daemon will listen for connections. This IP address must be owned by your server. It is strongly recommended to avoid using your main shared IP address for this value. Instead, consider creating a custom DNS entry (e.g., ssh.example.com) with an A record pointing to the new SSH IP address.
  • PermitRootLogin — This option determines whether direct SSH login for the root user is permitted. We strongly advise setting this value to no.

Edit the sshd_config file

To configure the /etc/ssh/sshd_config file and enhance your server’s security, follow these steps:

  1. Log in to your server as the root user via SSH. If direct root logins are not allowed, log in as your wheel user and use the su command to become the root user.
  2. Back up the sshd_config file using the following command: 
    cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak`date +%F`
  3. Open the /etc/ssh/sshd_config file with a text editor.
  4. To modify a parameter, uncomment the relevant line by removing the number-sign character (#) and then change its value. For example, to change the SSH port from its default to 456, modify the line to resemble: 
    Port 456

After configuring SSH, run the /scripts/restart_sshd script or the service sshd restart command to restart the SSH daemon.

Once SSH has restarted, log out and then log back into your server using the user, IP address, and port number specified in the modified sshd_config file.

Warning: If you inadvertently misconfigure your SSH configuration file, access the following link in your web browser (replace example.com with your server’s hostname or main IP address):

https://example.com:2087/scripts2/doautofixer?autofix=safesshrestart

This script will temporarily set up an additional SSH configuration file for port 22, allowing you to access, edit, and correct the original SSH configuration file. If port 22 is already in use by another service, the script will configure an additional SSH configuration file for port 23.

Example sshd_config File

Warning: Do not copy and use the example file below on your server, as it will likely disrupt your SSH service configuration. This file is provided for reference only.

Click to view...


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
# $OpenBSD: sshd_config,v 1.93 2014/01/10 05:59:19 djm Exp $

# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/usr/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options override the
# default value.

# If you want to change the port on a SELinux system, you have to tell
# SELinux about this change.
# semanage port -a -t ssh_port_t -p tcp #PORTNUMBER
#
Port 456
#AddressFamily any
ListenAddress 192.168.69.187
#ListenAddress ::

# The default requires explicit activation of protocol 1
Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# 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
HostKey /etc/ssh/ssh_host_ed25519_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Ciphers and keying
#RekeyLimit default none

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
SyslogFacility AUTHPRIV
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#RSAAuthentication yes
#PubkeyAuthentication yes


# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile .ssh/authorized_keys

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
PasswordAuthentication yes

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
#KerberosUseKuserok yes

# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials no
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no
#GSSAPIEnablek5users no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
# WARNING: 'UsePAM no' is not supported in Red Hat Enterprise Linux and may cause several
# problems.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
UsePrivilegeSeparation sandbox # Default for new installations.
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#ShowPatchLevel no
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Accept locale-related environment variables
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS

# override default of no subsystems
Subsystem sftp /usr/libexec/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# PermitTTY no
# ForceCommand cvs server
Was this answer helpful? 0 Users Found This Useful (0 Votes)

Most Popular Articles

How to Setup Email Accounts in cPanel

Setting Up Email Accounts in cPanelThis guide will walk you through the process of creating and...
Understand Workflow Triggers

Understanding Workflow Triggers for Metanow CRM Integrations Workflow triggers in Metanow CRM are...
ModSecurity® 3

ModSecurity® 3 - Metanow CRM ModSecurity® 3 Overview ModSecurity...
The Ultimate Guide to Voicemail: Everything You Need to Know

The Ultimate Guide to Voicemail: Everything You Need to Know Understanding Voicemail: A Brief...
Gain Insights into Every Association | Features

Gain Comprehensive Insights into Every Association | Metanow CRM Features Association Deep...