• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Question Can I change the default Port, for SSH Client connection, to any available Port number?

Craig1986

Basic Pleskian
I have recently come to realise that it is considered good practice, from a security point of view, to change the default Port for SSH client connection from 22.

I have spoken with my VPS provider, who has confirmed that all 65,535 Ports are available for use. Would I then be right in thinking that I can use any available Port, providing they are not already in use by Plesk; as detailed in this Plesk Documentation?

Assuming my thoughts are correct, are there any other factors I would need to bear in mind? For example:
  • Are some Ports more secure than others?
  • Do different Ports offer different performance levels?
  • Would changing Ports require additional changes within the VPS. Such as SSL Certificates?
Also, should I also look to change the default Ports for other services, such as MySQL and Plesk Installer; or would I just be causing issues here?
 
Hi @Craig1986,

Changing the port is good as a security measure, but not a complete solution. Because hackers can scan different ports on an IP address. There will only be a decrease in the number of test attacks, you cannot block it completely.

No performance loss / increase is observed with port changes. For port changes, you must allow the relevant port inside the server and, if you are using it, on the physical firewall.

Sample:

If you are using Ubuntu and will port 1560;

sudo ufw allow 1560
sudo ufw reload

You must run commands.

It should also not conflict with the standard ports of some services. For example, you shouldn't update to 53. Port 53 is for DNS query, SSL transport port 443 etc.
 
Changing the port can cause problems with:
- Plesk backup and restore
- Plesk Migrator extension
- SFTP access in subscriptions
- SSH access in subscriptions

Other suggestion: Create a separate user account on your Linux system level for login purposes only, but don't give it root privileges. Then set the "PermitRootLogin" variable in /etc/ssh/sshd_config to "no", restart sshd. Also activate Fail2Ban and use the SSH and recidive jails. Hackers might still try to login, but they'll fail after n attempts, and even in the very unlikely case that someone logs in to SSH, they'd still need to upgrade their permissions to root privileges (need the password for that, too).
 
Changing the port is good as a security measure, but not a complete solution.
Thank you for your response. Are you saying that changing a Port is just one step of a series of steps, or that changing a Port is like 'security through obfuscation' and thus has its limitations?

Changing the port can cause problems with:
- Plesk backup and restore
- Plesk Migrator extension
- SFTP access in subscriptions
- SSH access in subscriptions

Other suggestion: Create a separate user account on your Linux system level for login purposes only, but don't give it root privileges. Then set the "PermitRootLogin" variable in /etc/ssh/sshd_config to "no", restart sshd. Also activate Fail2Ban and use the SSH and recidive jails. Hackers might still try to login, but they'll fail after n attempts, and even in the very unlikely case that someone logs in to SSH, they'd still need to upgrade their permissions to root privileges (need the password for that, too).

Thank you for highlighting the potential problems, as well as an alternative solution.

I have been adopting your alternative suggestion, for quite some time now and have experienced no issues to date. Are you saying that in using this approach, that I do not need to worry about changing the default Port number since access is all secure anyway?
 
Yes, it is very secure in combination with the SSH and recidive Fail2Ban jails. You will probably see a lot of SSH blocks in the Fail2Ban blocked IP list on SSH. Plus, an attacker would need to figure out the root password in addition to the SSH login password. As long as your passwords are not hacked (e.g. by a keylogger on your system) you'll be pretty safe on the SSH access. Even better when you are not using password based SSH login at all, but a keyfile instead. Port changes are not recommended.
 
Yes, it is very secure in combination with the SSH and recidive Fail2Ban jails. You will probably see a lot of SSH blocks in the Fail2Ban blocked IP list on SSH. Plus, an attacker would need to figure out the root password in addition to the SSH login password. As long as your passwords are not hacked (e.g. by a keylogger on your system) you'll be pretty safe on the SSH access. Even better when you are not using password based SSH login at all, but a keyfile instead. Port changes are not recommended.
Awesome! Thanks for the reassurances.

I would like to add that I also have a 2 Step Authentication extension installed, offering another layer of security to help protect against attacks that have used tools such as the Keylogger you mentioned.

I will have to read up more on setting up Keyfiles but thanks for the advisory. :)
 
Back
Top