Resolved Change ssh port

[garcue]

Hello everyone,

Can plesk fail if I modify the ssh port?
Should I have something in mind when interacting with plesk after the change?

Regards

 

[TomBoB]

No, PLesk will not fail. Changing the SSH port is a great security measure.

But check before hand that the port is open in the firewall, and if you use fail2ban, you'd want to adjust the port there too.
Instructions are at the Plesk Helpcenter

Cheers,
Tom

 

[garcue]

No, PLesk will not fail. Changing the SSH port is a great security measure.

But check before hand that the port is open in the firewall, and if you use fail2ban, you'd want to adjust the port there too.
Instructions are at the Plesk Helpcenter

Cheers,
Tom

Thanks tom,
That is the main reason for my decision, but I wanted to know if at the system level it influenced something. Apart from checking if the port in the firewall is open, another service to be reviewed is fail2ban, only check if the new port inserted is being correctly monitored.

 

[AYamshanov]

Hi garcue,

Could you please clarify why you prefer change ssh port instead of using strong passwords and block brute-force bots with fail2ban?

 

[garcue]

Hi garcue,

Could you please clarify why you prefer change ssh port instead of using strong passwords and block brute-force bots with fail2ban?

It is a good security practice to change the SSH connection port, as well as to disable root user access.

 

[mr-wolf]

That's "security through obscurity"
Who decided that's "good security practice"? You did?

 

[garcue]

That's "security through obscurity"
Who decided that's "good security practice"? You did?

Any computer security book you can find recommends such practices. Yes, I have applied it on my servers.

 

[mr-wolf]

Maybe you should buy other books...
Read this first:
Security through obscurity - Wikipedia

One sentence is pivotal:
"recommends the usage of security through obscurity as a complementary part of a resilient and secure computing environment"

The problem is that it is rarely used as a "complementary part", but rather "instead of".
You can never stop with improving your security. It always ends in risk management.
Having "security through obscurity" in place always means that there is less effort done getting open security implemented. That's human behaviour.

If you really have proper security in place, the "security through obscurity" part doesn't really increase any security and just becomes a nuisance.

Beginning with "you, not knowing how to implement it"
Furthermore you don't need to change anything in your SSHD config. You can do this in iptables.
No program will be aware of that, neither does Plesk.

 

[ChristophRo]

If you really have proper security in place, the "security through obscurity" part doesn't really increase any security and just becomes a nuisance.

A part of security is also intrusion detection, or maybe one day you have a break-in and need to evaluate the source, entry vector, damage and more it caused.
Good luck browsing through gigs of logfiles, full of nonrelevant entries and false positivies, cause you are using well known ports that get bombarded by casual bots and script kiddies.

 

[mr-wolf]

A part of security is also intrusion detection, or maybe one day you have a break-in and need to evaluate the source, entry vector, damage and more it caused.
Good luck browsing through gigs of logfiles, full of nonrelevant entries and false positivies, cause you are using well known ports that get bombarded by casual bots and script kiddies.

The funny part is that I don't have "gigs of logfiles" and am not getting bombarded because I took the time to put some real security in place.
Something you don't feel the need of doing because you resorted to "security through obscurity" as an easy way out.

And if you know all this so good.
Why don't you tell the OP how to change the SSH-port without changing anything in sshd.conf

 

[garcue]

Maybe you should buy other books...
Read this first:
Security through obscurity - Wikipedia

One sentence is pivotal:
"recommends the usage of security through obscurity as a complementary part of a resilient and secure computing environment"

The problem is that it is rarely used as a "complementary part", but rather "instead of".
You can never stop with improving your security. It always ends in risk management.
Having "security through obscurity" in place always means that there is less effort done getting open security implemented. That's human behaviour.

If you really have proper security in place, the "security through obscurity" part doesn't really increase any security and just becomes a nuisance.

Beginning with "you, not knowing how to implement it"
Furthermore you don't need to change anything in your SSHD config. You can do this in iptables.
No program will be aware of that, neither does Plesk.

I prefer to look for it in several books before in wikipedia XD.

It is not the only security measure implemented for SSH login.

I also know that it can be modified from IPTABLES. Thanks for your "help".

 

[mr-wolf]

I don't have this from Wikipedia. Just looked it up for you as an easy referral.
I knew this long before Wikipedia existed.

It even "comes back" on the consensus somewhat that it is "not done". But that is of course an opinion.

You may not see this as "help". But an easy recipe published here isn't either. You're not the only one reading these threads. If an "easy recipe" is published here it will most certainly be followed by those that don't consider putting any other security measure in place.

Especially if everyone here agrees "it's such a good thing!"
I wanted to have at least one voice here that discourage those looking for an easy fix.

The ones that already know this, should already have the abilities and knowledge to do this without asking for help.

 

[garcue]

I don't have this from Wikipedia. Just looked it up for you as an easy referral.
I knew this long before Wikipedia existed.

congratulations!!

 

[ChristophRo]

The funny part is that I don't have "gigs of logfiles" and am not getting bombarded because I took the time to put some real security in place.
Something you don't feel the need of doing because you resorted to "security through obscurity" as an easy way out.

Yeah sure, you know better how to do things, but assuming the most common case, we simply have a server that currently has port 22 open from everywhere, and maybe/possibly fail2ban active.
So changing the SSH port is a very effective way to prevent unwanted login tries and keep your logs clean.
Given the same circumstances, you are free to tell us how your magic security solutions looks like, that seems to prevent the same but in a much better fashion.
(geo filtering and limiting tcp/22 access to known/trusted sources aside, as these may not be feasible)

Why don't you tell the OP how to change the SSH-port without changing anything in sshd.conf

iptables -t nat -A PREROUTING -p tcp --dport 10022 -j REDIRECT --to-ports 22

But I'd rather change the port in sshd.conf or even add an additional "port xxxx", so the SSHd does listen on both and I can still use 22 for internal/trusted access.