7 ways to secure your SSH Server
7 ways to secure your SSH Server
The challenging part for any IT administrator is to find the right solution to secure the data. When it comes to securing SSH Server, everyone wants to test the solution and see the exact features which are also very important.
This page shows how to secure your OpenSSH server running on a Linux/Raspberry operating system and test in a real-time environment.
What does SSH do?
SSH offers two main functions:
- Logging on to remote systems and running terminal sessions, execute remote commands and such on these remote systems.
- Transferring files between remote systems.
Here is our top 7 list for how to secure your Open SSH:
1) Use SSH Public Key based logins
Public key-based authentication coupled with centralized identities in an LDAP backend is the strongest authentication method for OpenSSH servers.
Generate a key pair using the following ssh-keygen command from your Linux, Mac or Windows machine.
You can either generate the key pair on your local desktop/ laptop or import just the public key on your LDAP account.
To generate the key pair, the standard command for all systems is ssh-keygen, it prompts you to enter the path to the file in which you want to save the key.
A default path and file name are suggested in parentheses. For example: /home/user_name/.ssh/id_rsa.
With RCDevs solutions, you get access to self-service. Here users can generate the new key pair by themselves or import their existing public key in order to use their existing private key for SSH logins purposes. Even the hardware FIDO and PIV keys can be used for your SSH logins.
Public keys don’t need to be deployed on each SSH server! An agent is instead installed and the agent will check with the server if the private key provided during the SSH login matches the public key stored on the users’ accounts.
With RCDevs solutions, SSH key management/deployment is fully automated from the key pair generation, passing through the accesses revocation (on all or a group of systems in one shot for a user), until the auto-renewal by end-users of an expired key.
More information on how to secure SSH Server for free
2) Enable MFA
Enabling Multi-factor Authentication (MFA) on Linux machines is also one of the proven ways to secure your SSH Server.
You can implement simple login or push login for MFA.
The below image shows the login flow for MFA in SSH Server.
On Unix-like systems, processes such as the OpenSSH daemon need to authenticate the user and learn a few things about him or her (user ID, home directory). Authentication is done through a mechanism called Pluggable Authentication Modules, and retrieving information about users (or even groups, hostnames) is done through another mechanism, called the Name Service Switch.
Read How to implement MFA in SSH Server / PAM
3) Centrally-manage your SSH Keys and Accounts
Many, or even all, Unix and Linux logins go ungoverned, without the ability to determine which key belongs to which identity and if the access is in breach with company IAM guidelines. In practice, this means that an unknown identity may log in with a key that is not even known to exist. To make things even worse, SSH logins are generally for privileged access which is the most critical form of access.
The solution is to centralize SSH Keys and accounts. Using self-service web enrolment to automate key distribution and audit unwanted access or renewal of outdated keys is also recommended.
4) Disable SSH Access with the Root account
Root account on Linux systems is the first account an attacker will try to access because of permissions allowed to this account.
In the SSH configuration, you can permit Root login or not.
It is possible to provide privileged access to users through the SUDO mechanism. SUDO provides the ability to launch a command as administrator (like root), or as another user while keeping proof of the executed commands. SUDO provides the possibility to allow an action to a user or group of users (update a system for e.g) without providing them full access to the system.
Access to root account through SSH is highly unadvised but in case you need to allow it, you should allow remote access to that account with public-key-based authentication, coupled to a One-time password(OTP)/ Yubikey/ Voice password validation.
5) Configure Idle TimeOut and session Interval
A user can log in to the server via ssh, and you can set an idle timeout interval and session duration to avoid unattended ssh sessions.
You are setting an idle timeout interval in seconds (300 secs == 5 minutes). After this interval has passed, the SSH session is locked and will require the user to provide his LDAP password.
6) Change SSH default Port
One of the main benefits of changing the port and using a non-standard port is to avoid being seen by casual scans. There is a default port for all services. So, if the port number is changed it is difficult to detect which service is running behind that port, and hence, your chances of being attacked are reduced.
7) Set a limit to Password Attempts
By setting a limit to your password attempts for SSH login, you can reduce the Brute-Force Attack to your server. Some of the good practices in user setting to reduce unethical access can be:
-Blocking IP addresses with multiple requests in a short time.
-Blocking login attempts for users with multiple wrong passwords.
-Setting a time gap between login attempts to the SSH server.
Bonus tips from RCDevs
RCDevs supports 3 layers of security i.e. SSH Public Key-based login, Multi-Factor Authentication, and LDAP Password to log in.
Some of the security features supported and recommended by RCDevs for safe login are:
1) SUDO Commands
The SUDO Command defines at the User, Group, System-level, and network level, what actions can be done by them according to the privileges defined and deployed.
2) User Blocking
User Blocking is very helpful to prevent brute-force attacks. You can set maximum log-in tries, failure blocking timer, blocking alerts to administrator, maximum session time, screen lock time, etc.
You can also allow users accesses based on IP Addresses, Client Certificates and even client policies.
3) Server Policy
Server Policy lets you enforce which kind of key user should use(RSA, ECC, or DSA), key length, key expiration and key maximum use.
Example– You want to enforce key expiration after 1 month from generation. You can simply select the days in the Key Expiration tab like in the image below.
4) Access based on Tags
The team access can be based on tags delegated per user or group.
All hosts managed by SpanKey Server can be tagged in the SpanKey client configuration. For example, all web servers could be tagged with the acronym «WEB» in the configuration file of the SpanKey client. Then you can add this Tag for all Webmaster accounts or groups to ensure SSH access to every web server with a common centralized configuration.
5) Extra Login Factor
You can also add an extra factor of authentication for SSH login and SCP/SFTP file transfer. (LDAP/OTP passwords)
The extra login factor for SSH login is also possible with FIDO or VOICE biometric authentication.
6) User Notification
You can notify your users through mail or SMS if its key pair or LDAP password is going to expire. On top of that, you can configure the SpanKey server to automatically send self-services access requests to access the different portals when SpanKey detects that the users’ password or SSH key pair expired.
7) Offline mode
Another interesting feature of SpanKey is the fact that even if SpanKey servers are down for any reason and authentications can not be verified with the server, you can configure specific accounts which can be used in offline mode. That way, you can still access your SSH servers even if the SpanKey server is not responding anymore.
You can download the RCDevs Security Solutions SSH Key Management solution now and get up to 5 Spankey Hosts free.
