SSH Protection

mlody.1039

New Member
Greetings.

Lots of users use SSH for their VPS/Dedicated Server and sometimes you can see people try access your SSH on Port 22 or try Crack it.

So here is 2 ways to protect from it.

First we can change our SSH Port lots of people just go to random IPs and try attack port 22 as it main Port of SSH.

So For Debian/Ubuntu/CentOs/Fedora

We do the follow commands

vi /etc/ssh/sshd_config
You will see Port 22 you can change it to any Number like 234
In CentOs to work you need Remove # before port 

After we save the file

In Debian/Ubuntu we reset SSH with the follow command

service ssh restart
And In CentOs/Fedora

service sshd restart
After we disconnect from putty or ssh if you using Linux and we connect again with new port. old port 22 is no longer in use.

Second way is allow SSH only by your IP its only for people who have Static IP but you can still use it if your IP change all you do is Connect to VNC and update your new IP.

First we need to do is go to edit Allowed hosts

vi /etc/hosts.allow
And add at the end of the file this

sshd: [Your IP]
If you want add more IPs all you do is sshd: [your IP],[another IP]


Now we need to edit host deny

vi /etc/hosts.deny
And add the follow code at the end

Now we reset our SSH

Debian/Ubuntu

service ssh restart
CentOs/Fedora

service sshd restart
Now our SSH is fully protected so no one can connect to your Server only from the specific IP I also recommend change SSH Port at same time and use SSH IP Protection.

Hope this will help some people.

Best Regards

mlody.1039
 

devonblzx

New Member
Verified Provider
You don't want to set:


ALL : ALL
in hosts.deny if you're just trying to block SSH connections.  It would be:


sshd : ALL
otherwise your going to block connections to other TCP services.

You also shouldn't need to restart sshd after modifying the hosts files.
 
Last edited by a moderator:

trueman1

New Member
Verified Provider
also you can modify /etc/ssh/sshd_config  file

add a second normal user without any rights

disable root login:  PermitRootLogin no

allow only this user to login to ssh:  AllowUsers <your-new-user-name>

Use a Non-Standard Port: Port 2345
 

joepie91

New Member
Far more important:

  • Use SSH keys: `ssh-keygen -t rsa` on your workstation, add the resulting `~/.ssh/id_rsa.pub` on your workstation to `~/.ssh/authorized_keys` on the server.
  • Test whether you can log in with your SSH key now.
  • Disable password authentication: set `PasswordAuthentication` to `no` in the `/etc/ssh/sshd_config` file (remove the # at the start if necessary, to uncomment it).
  • Restart your SSHd.
That also completely removes the need for changing your SSH port, which just makes it harder to work with some third-party tools that tunnel over SSH, and doesn't actually add any security whatsoever.
 
Last edited by a moderator:

tonyg

New Member
That also completely removes the need for changing your SSH port, which just makes it harder to work with some third-party tools that tunnel over SSH, and doesn't actually add any security whatsoever.
Great, here we go...I guess it was just a matter of time.
 
Last edited by a moderator:

William

pr0
Verified Provider
In 99% of cases it is already enough to switch to key based auth and disable password login, in sshd.conf:

PermitRootLogin without-password
 

joepie91

New Member
Changing the SSH port actually does give more benefit than just 'security through obscurity'.  Not wasting resources on SSH Brutes is one example.  So yes, using a non-standard port should be part of everyone's basic SSH security.
  1. "Wasting resources" to a fairly trivial level has nothing to do with "security".
  2. If you disable password authentication, there are no authentication attempts, and the connection is immediately aborted during the handshake as soon as the client announces it cannot authenticate by key. It thus doesn't use any significant amount of resources.

scp -P <port>

ssh -p <port>

rsync -e "ssh -p <port>"

What is left? non-problem solved
Git, and anything else one might use that tunnels over SSH.
 

KuJoe

Well-Known Member
Verified Provider
I personally always change my SSH port regardless if I have password authentication disabled or not unless NAT is involved, if it is then I'll port forward to 22 and use 22 internally but externally it's always something other than 22. I also have a lot of servers/devices where disabling password authentication isn't an option in which case changing the port is needed.

I added buttons to Wyvern a while back so clients can randomize their SSH port (never above 1024) as well as disable password authentication (and adding their own SSH keys). If you're looking at one system it isn't so bad but when we first got into VPS hosting the number one reason for high loads on our servers was SSH brute force attacks against hundreds of VPSs at a time and the disk IO was insane keeping up with the /var/log/(secure/auth.log) being written to constantly (then again this was when we were still using RAID1 without hardware RAID). Basically when a client gets their VPS hacked the first thing we tell them to do is re-install a fresh OS and the second thing is to randomize their SSH port if they don't want to bother with anything else. It's literally the easiest change they can make which will stop 99.9999999999% of all SSH attacks that do not target the client directly.
 
Last edited by a moderator:

Aldryic C'boas

The Pony
  1. "Wasting resources" to a fairly trivial level has nothing to do with "security".
  2. If you disable password authentication, there are no authentication attempts, and the connection is immediately aborted during the handshake as soon as the client announces it cannot authenticate by key. It thus doesn't use any significant amount of resources.
Trivial for folks using hardware or KVM.  OpenVZ - SSH brute scans can easily take a container offline - it doesn't matter if the connection is 'immediately aborted'.  Is more relevant to stability than security, yes, but that hardly means it should be ignored.  And as KuJoe mentioned, if you have OpenVZ nodes, it's something you *have* to take into account.  The IO he noticed was actually the more minor issue - I've seen SSH brute scans knock entire nodes down.  It was an unintentional side effect of the actual brute, and no, I won't be sharing details on the how/why as there are still too many skids lurking that would love to try it themselves.  Just suffice to say it was a problem we deemed significant, and as such put in place measures to prevent it.  Such as detecting and blocking entire brute scans.
 
Last edited by a moderator:

MartinD

Retired Staff
Verified Provider
Retired Staff
Would have to agree. Mass ssh attempts on an ovz node does cause significant problems and I've seen a node collapse due to it.
 

drmike

100% Tier-1 Gogent
Honeypot SSH brutes... Block the bad actors fast and hard across all of your ranges.

One issue with node destruction due to brutes is the lack of entropy pool / slow to replenish.

Guys and gals should consider this as a bandaid:
 
Top