Ubuntu / Debian - Change SSH Port for security reasons

[Desert]

I created this tutorial for be aware about SSH Brute Force attacks

https://blog.sucuri.net/2013/07/ssh-brute-force-the-10-year-old-attack-that-still-persists.html

 

Go to your VPS (Linux Ubuntu)

root@webflake:~# apt-get install nano && nano /etc/ssh/sshd_config

# What ports, IPs and protocols we listen for
Port 22

Change it to a number above 40000 for more security

root@webflake:~# service ssh restart
ssh stop/waiting
ssh start/running, process 11065

 

---

If you want more security

Now create other account (no root obviously) for use "su" command and use root user.

root@webflake:~# useradd connect-bridge
root@webflake:~# passwd connect-bridge
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

Change PermitRootLogin to no

root@webflake:~# service ssh restart
ssh stop/waiting
ssh start/running, process 11065

Now for connect to you server change the SSH Port and connect with connect-bridge , type password and now type "su" and type the root password.

Edited June 21, 2015 by Desert

[Bogdan.]

Useful tutorial, my congratulations.

[Afresh]

Also, don't forget to change in Fail2Ban and in your firewall.

It may be obvious, but it happened to me too many times :D

[Mikasa]

This is quite useless to be honest - Yes it keeps the script kiddies away that only scan for standard ports , but if someone really wants to find that port - They will.

A more efficent way to "hide" ports like SSH, FTP, SFTP and so on is to use a "Port knocking" technique. For example you have to "knock" on port Y to enable port X. This is way more efficent that just changing the port. with this you don't even have to change the standard ports. Because nobody will know which port you're knocking on to open the door,

[NikoCodey]

But why? Use a strong password and there is nothing anyone can do.

The only concern is DDoS attacks which can be resolved with a good host.

Or configure fail2ban

Edited November 22, 2015 by NikoCodey

[Luke]

I know, I know later reply.. but why use SSH passwords at all?... I use Dropbox, Google Drive, or OwnCloud to sync SSH keys between my machines. That and fail2ban is a great start to securing a system. I use an Ansible playbook (fail2ban, ssh setup, unattended-upgrades on a jessie box) to setup everything on the node for me.. then I just login with that one SSH key to all of my different servers. 

 

I never take chances, always lock down root, root is never passworded, and login is disabled.

Edited November 30, 2015 by Luke

[nelsa]

Well actualy it is not good idea to change SSH port outside priviliged ports range i.e above 1024. Because below 1024 are special priviliged ports and this is a security feaure.People like to move this port away in order to lower the number of attacks on the SSH port but that pop ups other worst risks.Now insted explaining  I will just copy one part of very good article from https://www.adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-another-port-than-22-is-bad-idea/

 

''Now, at first glance, this seems a valid reason: if you don’t know which port to attack, you can’t attack it at all. But if you go deeper, you will notice this is nothing more than security through obscurity.

But there are more reasons why this is a bad idea and one of the most important reason has to do with a bit of the (Linux) way of handling TCP/IP ports. When you are logged onto a system as a non-root user (anyone not being uid 0), you cannot create a listing TCP or UDP port below 1024. This is because port numbers below 1024 are so-called privileged ports and can only be opened by root or processes that are running as root.

So for instance, when your webserver (apache, nginx etc) will start, it will do so as the privileged root user in order to open up a listening connection to port 80 (the port that by default will be used for HTTP traffic). Now, as soon as the port is opened and everything that needs to be done as root is done, the webserver will fall back to a non-privileged user (either the www-data, apache, or nobody user). From that point, when something bad is happening, it is only limited to the rights that that user has. Now, back to SSH: when we start SSH on port 22, we know for a fact that this is done by root or a root-process since no other user could possibly open that port. But what happens when we move SSH to port 2222? This port can be opened without a privileged account, which means I can write a simple script that listens to port 2222 and mimics SSH in order to capture your passwords. And this can easily be done with simple tools commonly available on every linux system/server. So running SSH on a non-privileged port makes it potentially LESS secure, not MORE.''

 

So if you don't have problems with attacks don't do this but if you are constantly under attacks and no way to deal with this(there is many better ways you can deal with this without moving SSH on non priviliged port) than you need to make sure you know what are you doing...and in that case there is few things you shoud do to lower security risks you just made by moving SSH on non  priviliged port ...for more I sugest to look in whole article above..and also first explore online how to deal with attacks without changing port and also look for tips how to move SSH on non priviliged port without exposing your server.

Edited December 15, 2015 by nelsa

[Janno]

I'd also like to add that if you have a static IP from which you connect, you can change sshd_config to only allow connections to the machine from specific IP's to specific accounts, for example:

AllowUsers [email protected]

That way, only account webflake from IP 127.0.0.1 can access the SSH. It also doesn't hurt to actually use a SSH key to authenticate. They're basically impossible to replicate and you'll end up with a much safer system.

 

You can also use an asterick either on the account part or in the IP part, so you can make webflake accessible from everywhere or make every account accessible from 127.0.0.1 IP.

Edited December 29, 2015 by Janno

[Proto]

This is usually one of the first things I do after creating a new server ontop of other things. 

[The General]

I would change the line PermitRootLogin to no, that way no one can SSH remotely using the root user.

If something happens and you need root you could always use the command sudo -s and it will switch you to root using your password.