SSH Protection

[mlody.1039]

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

ALL: ALL

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]

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.

 

[trueman1]

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

 

[DomainBop]

Use a Non-Standard Port: Port 2345

...and remember to add the new port to your firewall


iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 2345 -j ACCEPT

out before the inevitable debate on whether security through obscurity works begins.

 

[Premiumn]

And remember to test if all works before shutting existing SSH session or you'll be locked out

 

[joepie91]

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.

 

[tonyg]

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.

 

[William]

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

PermitRootLogin without-password

 

[iFi Host]

Hmm. Good  Tuts Here. But Elobrate it Properly For Beginners. Any Way I Like It.

 

[joepie91]

Great, here we go...I guess it was just a matter of time.

As long as people keep making this misleading (and potentially dangerous) suggestion, I'm going to keep correcting it.

 

[Aldryic C'boas]

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.

 

[mitgib]

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.

scp -P <port>

ssh -p <port>

rsync -e "ssh -p <port>"

What is left? non-problem solved

 

[sv01]

scp -P <port>

ssh -p <port>

rsync -e "ssh -p <port>"

What is left? non-problem solved

use ssh config file

ssh vps1

rsync vps1

 

[joepie91]

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]

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.

 

[Aldryic C'boas]

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.

 

[mitgib]

Git, and anything else one might use that tunnels over SSH.

git clone ssh://[email protected]:[port]

You sure are doubling down on being wrong, maybe you should just stop

 

[lbft]

and doesn't actually add any security whatsoever.

Getting rid of the unsophisticated majority of automated attackers makes it easier to spot real trouble. Reducing log noise does add security.

 

[MartinD]

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]

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: