$ sudo systemctl restart sshdįor an added security layer, you can define the users who require SSH protocol to log in and perform remote tasks on the system. Then restart the SSH daemon to effect the changes made. This implies that the SSH session will be dropped if no activity is registered after 3 minutes which is the equivalent of 180 seconds. Assign a reasonable value, for example, I have set the limit to 180 seconds. Once again, open your SSH configuration file and locate the directive “ClientAliveInterval”. To address the issue, it’s prudent, therefore, to set an idle timeout limit which when exceeded, the SSH session will be closed. Someone can simply pass by and take over your SSH session and do whatever they please. Leaving your PC unattended for extended periods of time with an idle SSH connection can pose a security risk. In this case, the command was: $ ssh -1 Check SSH ProtocolĪdditionally, you can simply specify the -2 tag just to be sure that Protocol 2 is the default protocol in use. You will get an error that reads “ SSH protocol v.1 is no longer supported”. To test if SSH protocol 1 is supported any more, run the command: $ ssh -1 Going forward, SSH will use Protocol 2 by default. To change this to the more secure Protocol 2, add the line below to the configuration file: Protocol 2Īs always, restart SSH for the changes to come into effect. SSH protocol 2 was introduced in 2006 and is more secure than protocol 1 thanks to its strong cryptographic checks, bulk encryption and robust algorithms.īy default, SSH uses protocol 1. SSH comes in two versions: SSH protocol 1 and protocol 2. Henceforth, remote root login will be deactivated. Once you are done, restart SSH service for the change to be effected. Once again, head over to the configuration file and modify this line as shown. Allowing remote root login is invariably a bad idea that could jeopardize your system’s security.įor this reason, it is always recommended that you disable SSH remote root login and instead stick to a regular non-root user. It’s a no brainer what can happen if a hacker manages to brute force your root password. Then restart SSH service for the change to be effected. To reject requests from users without a password, again, head over to the configuration file at /etc/ssh/sshd_config and ensure that you have the directive below: PermitEmptyPasswords no This sounds a bit strange but sometimes system administrators can create user accounts and forget to assign passwords – which is a very bad idea. Disable User SSH Passwordless Connection RequestsĪnother recommended way of fortifying the security of your server is to disable SSH logins from users without passwords. # sudo systemctl restart sshdĪt this point, you will only have access to the remote server using the SSH key authentication. Uncomment and change the option 'yes' to 'no' PasswordAuthentication no Inside the configuration file, scroll and locate the following directive. The next step is to disable password authentication, To achieve this, you need to modify the SSH configuration file. Once the public key is successfully copied, you can now SSH in to the remote server seamlessly without having to provide a password. The private key resides on your host system whilst the public key is then copied to the remote server. The first step is to generate an SSH key-pair which consists of a public key and a private key. To be on the safe side, the use of SSH passwordless authentication is highly encouraged. But here’s the thing: hackers can guess passwords or even perform a brute force attack using special hacking tools and gain access to your system. Setup SSH Passwordless Authenticationīy default, SSH requires users to provide their passwords when logging in. In this guide, we explore different ways that you can use to secure and harden OpenSSH installation on the server. When it comes to accessing remote devices such as servers, routers, and switches, SSH protocol comes highly recommended given its ability to encrypt traffic and ward off anyone who might try to eavesdrop on your connections.īe that as it may, the default settings of SSH are not infallible and additional tweaks are needed to make the protocol more secure.
0 Comments
Leave a Reply. |