Applicable to:
- Plesk for Linux
- Plesk for Windows
Question
How to provide Plesk Support Team with direct access to the server?
Answer
On Plesk Obsidian for Linux Support SSH Access extension can be used instead, to simplify providing the access.
For Windows use the instructions below:
-
Configure firewall rules:
Add Plesk Support IPs to exceptions in the firewallNote: In case an intermediate firewall is used, such as Google Cloud Platform Firewall, the rules should also be added there. For more information, refer to the product documentation.
Plesk Support uses the following IP ranges to access remote servers:
- 195.214.233.0/24
- 91.204.24.0/24
- 91.204.25.0/24
- 80.237.178.180
- 81.184.0.141
- 95.170.131.46
- 2A00:1730:FFF9::/48
- 2001:678:744::/64
These IP addresses can be added the following way:
-
On Linux:
# iptables -I INPUT -s 195.214.233.0/24,91.204.24.0/24,91.204.25.0/24,80.237.178.180,81.184.0.141,95.170.131.46 -j ACCEPT
# ip6tables -I INPUT -s 2A00:1730:FFF9::/48,2001:678:744::10/64 -j ACCEPT
-
On Windows:
PS New-NetFirewallRule -DisplayName "Plesk Support Access" -RemoteAddress @("195.214.233.0/24", "91.204.24.0/24", "91.204.25.0/24", "80.237.178.180", "81.184.0.141", "95.170.131.46", "2A00:1730:FFF9::/48", "2001:678:744::10/64") -Direction Inbound -Action Allow
-
Set up SSH keys authentication (for Linux)
Setting up SSH keys-
Connect to the server using SSH.
-
Make sure PubkeyAuthentication is enabled in SSH configuration:
# grep PubkeyAuthentication /etc/ssh/sshd_config
PubkeyAuthentication yes -
Make sure
.sshdirectory exists in the home directory of the user that will be provided to the Support Team:# mkdir ~/.ssh && chmod 700 ~/.ssh
-
Place the Plesk Support public SSH key to the
authorized_keysto allow logging in using it:# curl -L https://support.plesk.com/hc/en-us/article_attachments/360003621494/id_rsa.pub >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys
Keys may be removed after the conclusion of the support incident as follows:
# sed -i '/support@plesk.com/d' ~/.ssh/authorized_keys
-
-
Log into the Plesk Help Center and add server access as a reply to the ticket
Note: Since the help Center uses HTTPS connection, it is secure. After access to the server is verified by the support engineer, they remove the reply from the ticket and put the credentials to a special field. This field is flushed when the ticket goes to a "closed" state.
Comments
10 comments
Hi,
How can I list the installed keys to check if the process was successfully done?
Thanks!
Hello Mario,
You may use any text editor (like vi or vim) to open the file /root/.ssh/authorized_keys and find out if the key is there.
Or you may use just less (less /root/.ssh/authorized_keys) or cat (cat /root/.ssh/authorized_keys)
Hi,
Today I got these IP's from one of your colleagues:
* 64.131.89.14
* 91.204.24.0/24
* 91.204.25.0/24
* 91.204.26.0/24
* 91.204.27.0/24
* 195.214.232.10
* 195.214.233.106
* 195.214.233.155
* 81.184.0.141
* 195.214.234.4
* 95.170.131.46
* 203.32.4.0/26
* 203.214.176.0/24
* 80.237.178.180
* 195.214.233.10
* 195.214.233.8
What's Plesk's current IP's/ranges to whitelist?
Thanks!
Hi @Mario,
You may find the most actual IP addresses in this exact article. They are as follows:
The current IP address ranges are almost the same as previous.
Netmasks were changed to take less time to whitelist IPs in firewalls, and some outdated IP addresses were removed.
Silly question, I am going to block several countries with ipset from our hardware nodes. This includes Russia.
Now I noticed a week or two ago, Plesk couldn't connect to the server as a result of this.
Now it's not clear; if I block a country with ipset and later on add the Plesk support IP's (as accepted IP's) is they can access the servers?
In other words will the IP's in the ACCEPT list overrule the country block?
Let me know. Thanks.
Hello @Michel vd Lingen,
Yes, whitelist has to work
Besides, you can allow connections for our IP addresses explicitly, however, make sure that these allowing rules are located before your blocking ones
Also, if you have several firewalls allow connection for each
From a security point fo view, I do have huge concerns of providing direct (unmonitored) access to a third party. May I suggest to think about adding the option of running a screen sharing session (e.g. TeamViewer) for such cases?
Already from a privacy perspective (EU GDPR), we have to ensure that private data is appropriately protected (e.g. GDPR article 28 & 29) and that persons with access to personal data are well instructed (Article 32 paragraph 4, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679&from=EN). So besides the fact that we actually might need to check if a data processing / confidentiality agreement needs to be signed, it would be great if we find a way that no unmonitored access needs to be granted.
Hi b_p,
From one side, in order to access the server, we require first to sign and verify a DPA (Data Processing Agreement), only after that we can access a server.
From the other side, we are all instructed on how to handle data according to GDPR, plus no data is taken out from the server without your explicit consent (for example, we don't download Backups, database dumps or files from the server). Also, we have internal audits for taking care of possible violations of GDPR, and in that case, the customer will be informed asap.
And third, it's not required to share root credentials with the Support SSH extension, a new user with keys will be created (on Linux, for Windows it's possible to create an additional user within the Administrators group).
Apart from that, and based on my experience, TeamViewer sessions are prone to delay (a lot) the investigation and resolution of issues, so it's not the recommended way, especially speaking when the Development team should be involved in the matter. Still, with a TV session, a DPA is required.
I hope I could answer your doubt :)
Hi Francisco Garcia
Well, but even beyond GDPR, it is a matter of trust: I know quite a few people who would consider their servers to be compromised if they need to provide unmonitored access to a third party. And beyond trust, there is the issue of traceability: In order to understand side effects (or prevent follow-up requests), it is much preferred to have a full overview of what is done on the server.
Hello b_p
Thank you for sharing your thoughts.
Server access isn't a "must". Issues investigation without access is also provided by Plesk support. However, such an investigation may take more time. However, it's a specific client to decide what rights are to be provided to Plesk for the investigation.
Plesk as a company ensures that the process of investigation is transparent and nothing extra is done by support engineers on the server.
Also, there're instruments to monitor all actions done on the server, for example https://unix.stackexchange.com/questions/84847/is-there-an-easy-way-to-log-all-commands-executed-including-command-line-argume
Please sign in to leave a comment.