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.
Getting started – install SSH
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:
sudo apt-get update sudo apt-get install openssh-server
To install SSH client on the client machine, run the following command:
sudo apt-get install openssh-client
Configure SSH for password-less login
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:
cd ~/.ssh ssh-keygen -t rsa
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:
On your server, create the following folder (if it doesn’t exist):
mkdir -p ~/.ssh/
Back to your client machine, copy the “id_rsa.pub” file to your server using the following command:
scp -P "yourport" ~/.ssh/id_rsa.pub username@serverip:~/.ssh
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.
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys chmod 700 .ssh chmod 600 .ssh/authorized_keys rm .ssh/id_rsa.pub
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.
Secure SSH configuration file
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
sudo nano /etc/ssh/sshd_config
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:
Port 22to
Port 2200
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:
Protocol 2Limit 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:
AllowUsers user1 user2
To deny “baduser1” and “baduser2,” add the following line:
DenyUsers baduser1 baduser2
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
PermitRootLogin without-password
to
PermitRootLogin no
Hide last login
You can hide who logged in last when a user logs in.
For this, change the line
PrintLastLog yesto
PrintLastLog no
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
#ListenAddress ::to
ListenAddress 192.168.1.20
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
# PasswordAuthentication yes
to
PasswordAuthentication no
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.
IgnoreRhosts yes RhostsAuthentication no RSAAuthentication yes
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.
HostbasedAuthentication no
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
LoginGraceTime 120to
LoginGraceTime 60
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
#MaxStartups 10:30:60
to
MaxStartups 2
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
X11Forwarding yesto
X11Forwarding no
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
LogLevel INFO
to
LogLevel VERBOSE
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.
PermitEmptyPasswords no
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.
ClientAliveInterval 300 ClientAliveCountMax 0
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.
StrictModes yesNow save and exit the /etc/ssh/sshd_config file and restart the SSH server.
sudo service ssh restart
Secure SSH using TCP wrappers
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.
sudo nano /etc/hosts.allow
Add the following line:
sshd : 192.168.1.2 172.16.23.12
Secure SSH using iptables
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:
sudo iptables -A INPUT -p tcp -m state --state NEW --source 192.168.1.2 --dport 2200 -j ACCEPT
Disable SSH connection from all other hosts by running the following command:
sudo iptables -A INPUT -p tcp --dport 2200 -j DROP
Now save your new rules using the following command:
sudo iptables-save > /etc/iptables/rules.v4
Conclusion
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
Over 5 years of experience as IT system administrator for IT company in India. My skills include a deep knowledge of Rehat/Centos, Ubuntu nginx and Apache, Mysql, Subversion, Linux, Ubuntu, web hosting, web server, squied proxy, NFS, FTP, DNS, Samba, ldap, Openvpn, Haproxy, Amazon web services, WHMCS, Openstack Cloud, Postfix Mail Server, Security etc.
14 comments
Comments are closed.
Nice but would it be an idea to discuss port knocking too?
Great article. One
typetypo, 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
Made a typo in my comment about a typo. Typoception.
Brad, thanks for the feedback. I have fixed the typo in the article, as well as in your comment.
The line DenyUser baduser1 baduser2
Should actually be:
DenyUsers baduser1 baduser2
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
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.
You have to check the command again. You probably mistyped it.
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 newusernameI’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