How to Secure an SSH Server in Ubuntu 14.04

Secure SSH Server In Ubuntu 14.04

SSH (Secure Socket Shell) is a command line interface and protocol for securely getting access to a remote Linux server. It provides a secure and encrypted communication over a network and allows data to be exchanged over a secure channel between two servers. It is widely used by system admins to control the Web and other types of servers remotely. In this article we are going to show you how you can secure your SSH server.

Note: this tutorial assumes that the SSH server is running Ubuntu 14.04, and the client machine is a Linux.

First, you need to update your system and install necessary packages to your system.

To update the system and install the SSH server on the server machine, run the following command:

To install SSH client on the client machine, run the following command:

There are two different methods of logging into an SSH server: one is password-based authentication and the other is key-based authentication. Password authentication is a very basic method which is easy to use and crack. Using password authentication is very insecure, especially if your user uses a weak password. On the other hand, SSH keys provide an easy and secure way of logging into a remote server, and this method is recommend for all users.

On your client machine, generate SSH keys with the following command:

Simply press the Enter key at every prompt. This produces two files: id_rsa.pub (public key) and id_rsa (private key).

This will output something that looks like the following:

ssh-keygen

On your server, create the following folder (if it doesn’t exist):

Back to your client machine, copy the “id_rsa.pub” file to your server using the following command:

Change “yourport” to the port number that your SSH server is using (the default is 22) and the “serverip” to the server’s IP address.

On your server machine, change the filename and setup permissions.

To test if the key-based authentication method works, try connecting to your SSH server from the client machine:

If you are able to connect without entering a password, then the key-based authentication method works.

The “/etc/ssh/sshd_config” file is the system-wide configuration file for SSH which allows you to set different options to improve the security of an SSH server. The default configuration in the config file is very insecure, so you need to edit it first and set proper options to improve the security.

To edit the “/etc/ssh/sshd_config” file, run

Change SSH listening port

By default, SSH listens on port 22. Attackers use port scanners to see whether an SSH service is running or not. It is recommended to change the default port.

To change the default port to 2200, change:

to

secure-ssh-change-port-number

Only use Protocol 2

Version 1 of the protocol contains security vulnerabilities. Protocol 2 is the default entry on Ubuntu.

Change the line shown below:

Limit users access

It is necessary to allow only specific users to log in to SSH. It can improve your security. By default, this option is not available in the SSH configuration file.

To allow “user1” and “user2,” add the following line:

To deny “baduser1” and “baduser2,” add the following line:

Disable root login

It is not necessary to log in as root via ssh over a network. Normal users can also use su or sudo to gain root level access. Most attackers will try to use root user to log in. This is a big security risk, so it is recommended to deny the root login.

To disable root login, change the line

to

secure-ssh-permit-root

Hide last login

You can hide who logged in last when a user logs in.

For this, change the line

to

secure-ssh-last-log

Restrict the interface to log in

By default, ssh will listen on all network interfaces. If you want to allow an SSH connection to be accepted from specific IP addresses, you can change the line

to

secure-ssh-listen-address

Disable password uthentication

Using password authentication is a big security risk if your user uses a weak password. It is recommended to use “ssh keys.” An “ssh key” can contain over 600 random characters and be difficult to break.

For this, change the line

to

secure-ssh-password-authentication

Disable .rhosts files

The .rhosts files specify which users can access the r-commands (rsh, rcp, rlogin, etc.) on the local machine without a password. By default an .rhosts file is disabled; if not, then change the lines as shown below.

Disable host-based authentication

SSH’s host-based authentication is more secure than .rhosts authentication. However, it is not recommended that hosts trust one another. By default, this option is disabled.

If not, then change the line shown below.

Set a login grace timeout

The “LoginGraceTime” specifies how long after a connection request the server will wait before disconnecting. It is recommended to reduce it to 60 seconds.

For this, change the line

to

secure-ssh-login-gracetime

Set maximum startup connections

Setting up a proper maximum number of concurrent connections to the SSH daemon can be helpful against a brute-force attack.

For this, change the line

to

secure-ssh-max-startup

Disable forwarding

The port forwarding technique is used by attackers to tunnel network connections through an SSH session to log into systems. It is recommend to disable this option.

For this, change the line

to

secure-ssh-x11forwarding

Log more information

By default, SSH logs everything. If you want to log more information like failed login attempts. you can change the value of this to “VERBOSE.”

For this, change the line

to

secure-ssh-loglevel

Disable empty passwords

It is necessary to deny users with empty passwords on your server. By default PermitEmptyPasswords is disabled in Ubuntu.

If not, then change the line shown below.

Set idle timeout interval

By default, this options is not available in the SSH default configuration file. It is recommended to set a proper idle timeout to avoid an unattended ssh session.

For this, add the following lines.

Strict mode

This will prevent the use of insecure home directory and key file permissions. By default, this option is enabled.

If not, then change the following line.

Now save and exit the /etc/ssh/sshd_config file and restart the SSH server.

A TCP wrapper provides host-based access control to network services used to filter network access to the Internet. Edit your “/etc/hosts.allow” file to allow SSH only from 192.168.1.2 and 172.16.23.12.

Add the following line:

By default, an SSH server must only accept connections from your LAN or other remote sites. It is recommended to allow only specific IP addresses to access SSH and block access to SSH to unauthorized IP addresses.

To allow SSH connections only from 192.168.1.2 run the following command:

Disable SSH connection from all other hosts by running the following command:

Now save your new rules using the following command:

The above instructions are very powerful techniques for securing your SSH server. This post covers all of the information most users will need for an SSH server. If you have any questions feel free to comment below.

Reference: SSH ubuntu

14 comments

  1. Great article. One type typo, though. The following command:

    scp -P “yourport” ~/.ssh/id_dsa.pub username@serverip:~/.ssh

    Should be:

    scp -P “yourport” ~/.ssh/id_rsa.pub username@serverip:~/.ssh

    • Brad, thanks for the feedback. I have fixed the typo in the article, as well as in your comment.

  2. I have a question bout the following part of the tutorial below, it asks me for a password but I am able to log in. Where could i be going wrong if its asking me for a password. please advise as I need to do this for a project. much appreciated.
    =============================================================================================
    To test if the key-based authentication method works, try connecting to your SSH server from the client machine:

    ssh -P “yourport” username@serverip

    If you are able to connect without entering a password, then the key-based authentication method works.

    • This is probably the case when your authorized_key is of a different permission, or it doesn’t contain your key. Check that the authorized_keys is of permission 600

  3. sorry it’s me again. I just realized when i was using the cat command to move the authorized key from the client to the server it says the directories that i used for the client dont exist. i checked and they exist. can someone please please help me out here.

      • Hey Damien,
        In the command username@serverip, is the username the name of the client machine thats trying to connect to the server. Also do I need to create a user in the server and if so what permissions should I give it when creating its account.
        Kindest Regards,
        Jennifer

        • Sorry but I have another question, when i log into my machine its client@client-virtual-machine and when i try the command cd ~/.ssh it says bash: cd: /root/.ssh doesnt exist. I then typed in sudo su and it changed from client@client-virtual-machine to root@client-virtual-machine:/home/client. i then typed in the cd ~/.ssh command and it says bash:cd:/root/.ssh doesnt exist. i used the cd .. command to get out of the /home/client directory . I typed in the command cd ~/.ssh and it gives an error bash:cd: /root/.ssh doesnt exist. I looked inside the home directory and it has client in there so i opened the client directory and it doesnt have .ssh directory there. Is there a specific location I should be installing openssh client? I think this might be the root of all my issues. please advise.

          • You shouldn’t use “su” command as it makes you the root user. You can just create the “.ssh” folder if it doesn’t exist.

        • @Jennifer, the username is not the name of the client machine. It is the user in the server that you want to log in as. If you have not created any user before, chances are that the only user in the server is “root” and you may want to create another user with the command adduser newusername

  4. I’m confused re: server identification;
    Is the server i.d. a made-up name, e.g. jim@home?
    or are there real hardware with formal idents?
    Hope I made my question clear enough.

    Thank you,
    jim@home

Comments are closed.

Sponsored Stories