Secure Your SSH Server
#1
Secure your SSH server

There are two methods of logging into SSH server

1. Password Authentication
2. key-based Authentication

Password Authentication is a very basic mode and very easy to use . Ease come with pain as well.It can be cracked easily using bruteforce attacks, so its is very insecure method, if you are using a very weak password.

key-based Authentication is based on cryptographic key authentication.  SSH keys provide easy and secure access to SSH server and it is recommended to all users.


For key-based Authentication go to this thread.

If you using above tutorial do not forget to check this post as well.

After following the above strategies continue with tutorial below, if you are using Key based authentication.

If you are not interested in Key based Authentication, still you can secure your SSH server by following the tutorial.

*** Not applies to password based Authentication.
=======================================================

The “/etc/ssh/sshd_config” file is the system-wide configuration file for SSH and used to improve security of SSH server.

To edit sshd_config file

You may use your own preferred text editor.

Terminal

nano /etc/ssh/sshd_config


If you get an error like nano not found, install it using below command.

Centos
Code:
yum install nano -y

Ubuntu
Code:
apt-get install nano -y



Change SSH port

By default SSH listen to port 22. Attackers use port scanners to check SSH service running or not. Change this default port to some random port.

For this change the line

Code:
# Port 22
 
to

Code:
Port  40522
Remember to remove number sign # before Port and opening port in firewall.

*** Disable Password Authentication

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 this line

Code:
# PasswordAuthentication Yes

to

Code:
PasswordAuthentication no

Set a login grace timeout

Login grace time defines how long a connection to server before disconnected.

For this change this line

Code:
LoginGraceTime 120

to

Code:
LoginGraceTime 60

Set maximum startup connections

To stop brute force attacks set up a maximum number of concurrent connections to SSH server

For this change the line

Code:
#MaxStartups 10:30:60

to

Code:
MaxStartups 2

Disable forwarding

This port forwarding is used by attackers to use tunnels to login into SSH sessions. If you disable this option you may not be able to access your SSH server from VPN.

For this change change this line

Code:
X11Forwarding yes

to

Code:
X11Forwarding no

Logging

By default SSH logs everything, but if you want more information like failed login attempts, change the following values.

For this change this line

Code:
LogLevel INFO

to

Code:
LogLevel VERBOSE

Disable Empty Passwords

Most of linix flavour set to " no by default.

If not you need to change this

Code:
PermitEmptyPasswords no

Idle time out

By default this is not availble in SSH default config file.

To add . insert following lines

Code:
ClientAliveInterval 300
ClientAliveCountMax 0

*** Disable root login

It is not necessary to login to root over a network, users can use " sudo or su" to gain root privileges. Attackers tend to try root as login and its a big security risk. So is better to turn it off.

For this change this line

Code:
PermitRootLogin without-password

to

Code:
PermitRootLogin no

Finally to implement above rules, run this command.

Code:
service sshd restart

Iptables

You can create access only to your IP segment by allowing access in iptables.

To enable SSH run this command

Code:
iptables -A INPUT -p tcp -m state --state NEW --source 192.168.1.2/8 --dport 40522 -j ACCEPT

/8 denotes 192.0.0.1 to 192.255.255.254. 40522 is your SSH port, change it as required.

Disable SSH connection from other hosts:

Code:
iptables -A INPUT -p tcp --dport 40522 -j DROP

Finally save the rule

Code:
service iptables save

Conclusion

Above instructions are best way to secure SSH server. Core idea of these to defeat SSH brute attacks.
#2
Two good additional points might be:
- disable root login via SSH if password authentication is used (PermitRootLogin no)
- if password and public key authentication is used set root login to be allowed only "without-password" --> public key authentication
#3
Here is what I did to my SSH:
* The default grace time period is 2m (2 minutes), I set it to 30s (30 seconds). You may need to give exact time value, either in second, minute or hour.
* I forced no root login even I used authentication keys. Only 1 user with it, and no password authentication.
Thank you FreeVPS and ZXPlay for VPS 7 and 19

[Image: show_img.php?userid=17170&vpscount=2]


Don't PM me for support, use an appropriate forum to ask for support
#4
(2015-10-06, 5:14:48 pm)abhe Wrote:  Here is what I did to my SSH:
* The default grace time period is 2m (2 minutes), I set it to 30s (30 seconds). You may need to give exact time value, either in second, minute or hour.
* I forced no root login even I used authentication keys. Only 1 user with it, and no password authentication.


1. Default grace period to login into SSH server is generally in seconds. You can not denote it in , minutes and hours.
2. Root login with authentication + SSH Random port is also a good step to fend off attackers.  I prefer to use SSH Key authentication + SSH random port.

When you enable SSH Key authentication, you had to disable plain password based authentication.

Hidden Refuge Wrote:- if password and public key authentication is used set root login to be allowed only "without-password" --> public key authentication

Thank you for the input. Please elaborate more. I am not sure but SSH will not work, if root is set to " without-password" in password based authentication.
#5
(2015-10-06, 8:56:57 pm)saurav Wrote:  Thank you for the input. Please elaborate more. I am not sure but SSH will not work, if root is set to " without-password" in password based authentication.

"PermitRootLogin without-password" only allows login for the user "root" via SSH through other login methods than password authentication (in this case the more secure public key SSH authentication). Other users (eg: saurav) will still be able to login with passwords and also public keys.


(2015-10-06, 8:56:57 pm)saurav Wrote:  1. Default grace period to login into SSH server is generally in seconds. You can not denote it in , minutes and hours.
2. Root login with authentication + SSH Random port is also a good step to fend off attackers.  I prefer to use SSH Key authentication + SSH random port.

When you enable SSH Key authentication, you had to disable plain password based authentication.

To 1) You can specify the grace period in seconds, minutes and hours. The value 30 without s,m or h equals 30 seconds. 1m equals 60 seconds and etc.. I recently reinstalled a few servers and they had a default grace period of 2m.

You don't have to disable password authentication when using public key authentication. In fact Debian has a default setup that uses password authentication by default with public key authentication enabled but not enforced and root login is only allowed "without-password" so over public key authentication. I'm talking about a real Debian system (not OpenVZ templates).
#6
For people that use password, i suggest to use fail2ban. If someone trys to guess the password, their ip will be banned. This makes it impossible to brute force.
#7
Quote:For people that use password, i suggest to use fail2ban. If someone trys to guess the password, their ip will be banned. This makes it impossible to brute force.

Theoretically, your password still can be brutforced using proxies or botnet resources
But It's probably a good idea anyway, I'd wrote the article about fail2ban and how to configure it here: https://serversuit.com/community/technic...l2ban.html

I can hardly image it of course but still, so I can recommend for all the users to use key identification only
Using 2-factor ID is probably a good idea too, google authenticator is very easy to set and configure.

So you'll need to enter additional PIN when login to your server, and your smartphone will be good for that.
There is a good how-to about that: https://www.linux.com/blog/securing-ssh-...henticator
#8
Personally I let my FreeVPS run on a custom port with root login allowed and password authentication, but since I do like you here so that only a specific IP segment can access it there is no need to worry about much intrusion attempts in the SSH server. If I was extra paranoid I guess I could add my key too.
This is what I would recommend for everyone: Root login blocked, only public-key authentication, locked to IP, max login tries, custom port. If that isn't secure for a small server I don't know what security is.
With that said I should note down that you cannot use this if you have a dynamic IP, mine is semi-static meaning that my internet has to be down for more than 7 hours for the ISP's DHCP to assign me a new IP, or I have to access it using a different MAC (assuming they have leftover IPs to give me). For this reason I would recommend you to set the router to sync up your IP and then have a CRON or something running in the background of your VPS to retrieve the latest IP and ensure you don't get locked out. It is pretty easy to write and highly useful. I would like to say if you run a VPN you could just disable public SSH entirely and just access it when you are connected to your VPN Tounge This was a little unstable as in slower response in SSH, but sure worked!
The latter VPN solution would work even if you wanted to access shell from whatever remote location, and you could always if you use a service like dns-o-matic update the other IP you have to the VPS if you are not from home. Overall locking it to certain IPs could be more a bother to do, so if you have publickey it's not necessary to do.
#9
Why aren't fail2ban and knockd mentioned in the OP? These measures make it all but impossible to bruteforce a password, and make even dictionary / rainbow hash attacks tough. Knockd in particular will even prevent port scanners from knowing which port is your SSH port.
Giveaway Manager, FreeVPS Directory and Discussion

Also a big fan of Anime, see my poor taste here.
#10
Nice post. I was using the key based authentication along with the password but will not disable it and also will make few of the above changes.




Users browsing this thread: 1 Guest(s)