Setting up SSH Server for Public/Private keys based Authentication (Password-less login)

SSH  is a protocol to communicate a server with client in an encrypted manner. It has replaced telnet protocol, which was not at all secure at all. Almost the Linux system admins know about it because they use it to connect to Linux servers as the physical access to server is very limited.

SSH is installed by default on most of the Linux distribution. & to access a server through ssh is very easy, you use following command

$ ssh {Server IP address or FQDN}

and then you enter the credentials. But in this tutorial we will learn to access ssh session securely with the help of Public/Private keys authentication aka password-less ssh sessions. Advantages of using Public/Private keys authentication are

• You won’t be asked for password everytime you access server (unless you are using a passphrase to decrypt the keys)
• No-one can gain unauthorized access to your server unless they have the right key .

Now let’s  create Public/Private keys to access our servers.

Creating keys on Local machine

Remember this, keys are to be created on each host that you wish to gain access from. So if there are 10-20 hosts from where you want to access a server, we must create keys on all those 10-20 servers.

To create keys, run the following command

$ ssh-keygen –t rsa

It will then ask you to select a location for the generated keys. By default, the keys will be stored in the ~/.ssh which is a hidden directory in your home folder (/home/dan/.ssh). The private key will be called id_rsa and the associated public key will be called id_rsa.pub.

It will also ask you to enter a passphrase, which is used to decrypt the keys. If you don’t wish to use any pass-phrase just leave it empty & press enter or else provide a pass-phrase.

Next, set permissions on your private keys,

$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/id_rsa

Configuration on Server

Now copy the Public key (id_rsa.pub) & move it to server at /home/user/.ssh/authorized_keysfolder. Now that the public keys have imported to server, remove them from local machine.

Next, we will also have to set permissions on the server as well

$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys

All the settings for Public/Private keys authentication is now complete.

Testing the Public/Private keys authentication  

Now log back into the local machine to access server & enter

$ ssh {Server IP address or FQDN}

& hit enter. You will notice that you won’t be asked for the credentials & are logged directly into the server.

Once you have tested your Public/Private keys authentication, you can also disable use of password authentication so that everyone uses only keys to access the server. Thus making your servers more secure. To disable password authentication , open /etc/sshd/sshd_config & change the following parameter

PasswordAuthentication no

That’s it, our Public/Private keys authentication setup is now complete.

-------------------------------------------------------------------------------------------

Ultimate guide to securing SSH sessions

Hi Linux-fanatics, in this tutorial we will be discussing some ways with which we make our ssh server more secure. OpenSSH is currently used by default to work on servers as physical access to servers is very limited. We use ssh to copy/ backup files/folders, to remotely execute commands etc. But these ssh connections might not be as secure as we believee & we must make some changes to our default settings to make them more secure.

Here are steps needed to secure our ssh sessions,

• Use complex username & password

This is first of the problem that needs to be addressed, I have known users who have ‘12345’ as their password. It seems they are inviting hackers to get themselves hacked. You should always have a complex password.

It should have at-least 8 characters with numbers & alphabets, lower case & upper case letter, and also special characters. A good example would be “vXdrf23#$wd” , it is not a word so dictionary attack will be useless & has uppercase, lowercase characters, numbers & special characters.

• Limit user logins

Not all the users are required to have access to ssh in an organization,  so we should make changes to our configuration file to limit user logins. Let’s say only Bob & Susan are authorized have access to ssh, so open your configuration file

$ vi /etc/ssh/sshd_config

& add the allowed users to the bottom of the file

AllowUsers bob susan

Save the file & restart the service. Now only Bob & Susan will have access to ssh , others won’t be able to access ssh.

• Configure Idle logout time

Once logged into ssh sessions, there is default time before sessions logs out on it own. By default idle logout time is 60 minutes, which according to me is way to much. Consider this, you logged into a session , executed some commands & then went out to get a cup of coffee but you forgot to log-out of the ssh. Just think what could be done in the 60 seconds, let alone in 60 minutes.

So, its wise to reduce idle log-out time to something around 5 minutes & it can be done in config file only. Open ‘/etc/ssh/sshd_config’ & change the values

ClientAliveInterval 300
ClientAliveCountMax 0

Its in seconds, so configure them accordingly.

• Disable root logins

As we know root have access to anything & everything on the server, so we must disable root access through ssh session. Even if it is needed to complete a task that only root can do, we can escalate the  privileges of a normal user.

To disable root access, open your configuration file & change the following parameter

PermitRootLogin no
ClientAliveCountMax 0

This will disable root access to ssh sessions.

• Enable Protocol 2

SSH protocol 1 had man in the middle attack issues & other security issues as well, all these issues were addressed in Protocol 2. So protocol 1 must not be used at any cost. To change the protocol , open your sshd_config file & change the following parameter

Protocol 2

• Enable a warning screen

It would be a good idea to enable a warning screen stating a warning about misuse of ssh, just before a user logs into the session. To create a warning screen, create a file named “warning” in /etc/ folder (or any other folder) & write something like “We monitor all our sessions on continuously. Don’t misuse your access or else you will be prosecuted” or whatever you wish to warn. You can also consult legal team about this warning  to make it more official.

After this file is create, open sshd_config file & enter the following parameter into the file

Banner /etc/issue

now you warning message will be displayed each time someone tries to access the session.

• Use non-standard ssh port

By default, ssh uses port 22 & all the brute force scripts are written for port 22 only. So to make your sessions even more secure, use a non-standard port like 15000. But make sure before selecting a port that its not being used by some other service.

To change port, open sshd_config & change the following parameter

Port 15000

Save & restart the service and you can access the ssh only with this new port. To start a session with custom port use the following command

$ ssh –p 15000 {server IP}

 Note:- If using firewall, open the port on your firewall & we must also change the SELinux settings if using a custom port for ssh. Run the following command to update the SELinux label

$ semanage port -a -t ssh_port_t -p tcp 15000

• Limit IP access

If you have an environment where your server is accessed by only limited number of IP addresses, you can also allow access to those IP addresses only. Open sshd_config file & enter the following with your custom port

Port 15000
ListenAddress 192.168.1.100
ListenAddress 192.168.1.115

Now ssh session will only be available to these mentioned IPs with the custom port 15000.

• Disable empty passwords

As mentioned already that you should only use complex username & passwords, so using an empty password for remote login is a complete no-no. To disable empty passwords, open sshd_config file & edit the following parameter

PermitEmptyPasswords no

• Use public/private key based authentication

Using Public/Private key based authentication has its advantages i.e. you no longer need to enter the password when entering into a session (unless you are using a passphrase to decrypt the key) & no one can have access to your server until & unless they have the right authentication key.