Applicable to:
- Plesk for Linux
- Plesk for Windows
Question
How to provide Plesk Support with server access?
Answer
-
Install the Support SSH Access extension from the Extensions menu.
-
Go to Tools & Settings > Plesk Support SSH Access (under Assistance and Troubleshooting).
-
Specify the expiration date for SSH access (by default, the access is granted for 5 days) and click OK.
-
Click Copy access credentials and send the access details to a Plesk Support representative in a ticket/chat:
-
Connect to a Plesk server via SSH.
-
Install the Support SSH Access extension:
# plesk bin extension --install support-access
The extension was successfully installed.Note: If the command above fails, see If Support SSH Access is not available below.
-
Generate the SSH access that will be valid for the next 5 days:
# plesk ext support-access provide -user plesk_support -date $(date -d '+5 days' '+%F')
-
Send the access details to a Plesk Support representative in a ticket/chat.
-
To revoke the SSH access manually, run:
# plesk ext support-access revoke
-
If Support SSH Access is not available:
Run the following command to activate the SSH access using the Plesk SSH Support Key:
# sh <(curl https://support.plesk.com/hc/en-us/article_attachments/6327675890962/script || wget -O - https://support.plesk.com/hc/en-us/article_attachments/6327675890962/script)
-
-
To remove the Plesk SSH Support Key, run:
# sed -i '/support@plesk.com/d' ~/.ssh/authorized_keys
-
Create a rule in Windows Firewall that will allow connections to your Windows Server from Plesk Support IP addresses:
-
Connect to a Plesk server via RDP.
-
Start Windows PowerShell and run the following command:
PS New-NetFirewallRule -DisplayName "Plesk Support Access" -RemoteAddress @("195.214.233.0/24", "81.184.0.141", "2001:678:744::10/64") -Direction Inbound -Action Allow
-
Log in to the Plesk Help Center and send server access details in your ticket/chat.
Note: Plesk Help Center uses HTTPS connection to prevent the interception of the data. Once the access to the server is verified by a Plesk Support representative, the server access details are removed from the ticket and put in the "Server(s) credentials" field. This field gets cleared when the ticket goes into the "closed" status.
Note: If 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 address ranges to connect to Plesk servers:
- 195.214.233.0/24
- 194.8.192.130
- 81.184.0.141
- 208.74.127.0/28
- 2001:678:744::/64
Comments
17 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 Roman Garcia Rodriguez
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 Pfleging
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
Your article is too freakin old. There's no such entry under "Assistance and Troubleshooting"
Hi jameslev
Did you install the Plesk Support SSH Access extension on step 2?
Once installed, it will appear under "Assistance and Troubleshooting" in Tools & Settings.
Thanks, Kuzma. I did but it didn't occur to me to check the UI again for this option until you asked. Forgive my frustrated tone earlier and thanks for following up and for outlining the steps on the command line for us. Be safe and have a great new year.
Hi Kuzma / Plesk Support,
Could someone please update this article so that the colon symbol is removed from the end of the last IP address above?
The extraneous colon there makes it confusing when I attempted to copy and paste this IP address into the firewall rule on the server because it results in an error message that the IP address isn't valid and I had no idea why, for hours, until closer examination.
The syntax of the IP address is very confusing because there are 2 colons in the middle of the IP address and one colon at the end, so it's unclear whether the 2 colons in the middle needed to be 1 colon OR whether the last colon should / shouldn't be there. I only found out through much trial-and-error, which is time-consuming.
2001:678:744::/64: <-- Referring to this colon here.
If we compare the last 2 IPs from the list above, one of them has a colon at the end, while the other one doesn't, so it's doubly confusing whether the colon at the end needs to be there.
2A00:1730:FFF9::/48
2001:678:744::/64:
It may not seem like a big deal at first glance to those who are familiar with IP address syntax, but for users who aren't as familiar with how all the different kinds of IPs are formatted, it's very confusing. I understand that it might've been a typo (typographical error) which normally would be understandable, but typos are really not okay in technical settings, especially in IP addresses where every number and every character matters.
Thank you.
Hi Support!
Thanks for brining this to our attention.
We removed that nasty colon from the last line.
Thanks, Kuzma! You're the best :)
Hi,
work with KVM, no SSH and used:
If support SSH access is not available:
Run the following command for SSH login using the Plesk SSH support key:
sh <(curl https://support.plesk.com/hc/article_attachments/4406015997074/script || wget -O - https://support.plesk.com/hc/article_attachments/4406015997074/script)
but return:
bash: syntax error near unexpected token ')'
Please sign in to leave a comment.