Facebook
Twitter
-
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
Resolved Acces /usr/share/psa-roundcube trough SFTP
Hi Jelle G,
well you just need to use an app like Filezilla, WinSCP or Director Opus (paid) and login as root using port 22.
On the other hand you could just download Putty, and create the new folder with a command like...
# mkdir /usr/share/psa-roundcube/<new_folder_name>
I hope that helps
Regards
Lloyd
well you just need to use an app like Filezilla, WinSCP or Director Opus (paid) and login as root using port 22.
On the other hand you could just download Putty, and create the new folder with a command like...
# mkdir /usr/share/psa-roundcube/<new_folder_name>
I hope that helps
Regards
Lloyd
Hi Jelle G,
Do you have the Plesk Firewall Extension installed? If not I suggest you install it, and that will set up the appropriate ports for you.
Install it via...
Plesk > Tools & Settings > Updates & Upgrades
I hope that helps
Regards
Lloyd
EDIT: What app are you using?
Do you have the Plesk Firewall Extension installed? If not I suggest you install it, and that will set up the appropriate ports for you.
Install it via...
Plesk > Tools & Settings > Updates & Upgrades
I hope that helps
Regards
Lloyd
EDIT: What app are you using?
No the firewall will be configured to allow connections to ssh by default.
Are you sure you are using the right password for root? Some providers set it to the same as the admin password for Plesk.
Regards
Lloyd
Are you sure you are using the right password for root? Some providers set it to the same as the admin password for Plesk.
Regards
Lloyd
After a quick conversation...
This could be because ssh is configured to only allow root access without a password (with certificate), you can enable root access by editing...
Changing...
to...
Then you could login as root with FileZilla and upload whatever you need to whatever directory.
But you should set up authorized_keys file and change it back to without-password.
If they mean, like on Ubuntu the root account is disabled, you can enable it like...
And set your root password.
This could be because ssh is configured to only allow root access without a password (with certificate), you can enable root access by editing...
Code:
# sudo nano /etc/ssh/sshd_configChanging...
to...
Then you could login as root with FileZilla and upload whatever you need to whatever directory.
But you should set up authorized_keys file and change it back to without-password.
If they mean, like on Ubuntu the root account is disabled, you can enable it like...
Code:
# sudo passwd rootAnd set your root password.
@Jelle G,
There is something completely wrong about this topic, in the sense that a lot of unnecessary steps are taken to (essentially) create a more vulnerable system.
First, with respect to Linux based SSH, note the following:
a) the root user is in principle a "passwordless" account, for the sake of security,
b) SSH access can be granted by means of
- an alternative account with a password, required to use the sudo prefix (or better: sudo -i, in order to prevent typing sudo before each command)
- an alternative account with a password and root privileges
- a root account with a password (which violates the principle, mentioned in point a)
- a root account with certificate based access
c) any provider of servers, granting certificate based SSH access, also provides
- the private key required to make the connection (this key is the secure password)
- an alternative account with a password and/or root priviliges
and in both cases, one can make SFTP connections by using the private key (in any application) or by using the alternative account.
Second, if you have a FTP account that works, just
- upload data to an accessible folder
- move the data to desired destination folder, by accessing the server via SSH
and this will not compromise security.
Third, if you fiddle with
- SSH config (read: sshd configuration files)
- root passwords (read: the command passwd root)
- root privileges (read: root privileges assigned to any user, including the user with the alternative account mentioned in point b of the first point made)
you are in danger of locking yourself out of the system entirely OR creating a security blackhole (that malicious scripts and persons scan for and, afterwards, WILL use).
Fourth, why not asking the server provider where to download the private key required for getting SSH access? Saves a lot of trouble.
Fifth, always make sure that SSH access is blocked for all IPs, except your own private IP and other IPs that you trust (so, it often is the rule "allow, deny all others")
Sixth, I am not sure why you would want to make any changes to the roundcube directories.
Sure, it can be the case that you want to customize Roundcube, but any upgrade of Plesk Roundcube packages can imply that your customizations are lost.
Moreover, the default Roundcube config files are a little bit "picky", in the sense that customizations do not always work as expected.
In summary and conclusion, I would recommend to keep the server as original as can be, in order to prevent system config customizations that can become troublesome.
Think about it a second, before letting the connection issues win over the security related considerations.
Regards.....
There is something completely wrong about this topic, in the sense that a lot of unnecessary steps are taken to (essentially) create a more vulnerable system.
First, with respect to Linux based SSH, note the following:
a) the root user is in principle a "passwordless" account, for the sake of security,
b) SSH access can be granted by means of
- an alternative account with a password, required to use the sudo prefix (or better: sudo -i, in order to prevent typing sudo before each command)
- an alternative account with a password and root privileges
- a root account with a password (which violates the principle, mentioned in point a)
- a root account with certificate based access
c) any provider of servers, granting certificate based SSH access, also provides
- the private key required to make the connection (this key is the secure password)
- an alternative account with a password and/or root priviliges
and in both cases, one can make SFTP connections by using the private key (in any application) or by using the alternative account.
Second, if you have a FTP account that works, just
- upload data to an accessible folder
- move the data to desired destination folder, by accessing the server via SSH
and this will not compromise security.
Third, if you fiddle with
- SSH config (read: sshd configuration files)
- root passwords (read: the command passwd root)
- root privileges (read: root privileges assigned to any user, including the user with the alternative account mentioned in point b of the first point made)
you are in danger of locking yourself out of the system entirely OR creating a security blackhole (that malicious scripts and persons scan for and, afterwards, WILL use).
Fourth, why not asking the server provider where to download the private key required for getting SSH access? Saves a lot of trouble.
Fifth, always make sure that SSH access is blocked for all IPs, except your own private IP and other IPs that you trust (so, it often is the rule "allow, deny all others")
Sixth, I am not sure why you would want to make any changes to the roundcube directories.
Sure, it can be the case that you want to customize Roundcube, but any upgrade of Plesk Roundcube packages can imply that your customizations are lost.
Moreover, the default Roundcube config files are a little bit "picky", in the sense that customizations do not always work as expected.
In summary and conclusion, I would recommend to keep the server as original as can be, in order to prevent system config customizations that can become troublesome.
Think about it a second, before letting the connection issues win over the security related considerations.
Regards.....
Hi trialotto,
Thanks for your reply and information.
I do know the securityrisks for this.
I needed to modify a lot of files and also each time, to see the changes.
Therefore I wanted SFTP access, so that it become much easier and faster to modify the files.
This was also done on a dev server, without any critical information on it.
After I completed these modifications, I of course edit the /etc/ssh/sshd_config again with "PermitRootLogin off" to disable root access.
It's good that you warn people about the risk, so thanks for that!
Thanks for your reply and information.
I do know the securityrisks for this.
I needed to modify a lot of files and also each time, to see the changes.
Therefore I wanted SFTP access, so that it become much easier and faster to modify the files.
This was also done on a dev server, without any critical information on it.
After I completed these modifications, I of course edit the /etc/ssh/sshd_config again with "PermitRootLogin off" to disable root access.
It's good that you warn people about the risk, so thanks for that!
@Jelle G
A mistake can be made very fast indeed.
Some things to note:
a) you should set "PermitRootLogin without-password" if you want to return to certificate based root (SSH) access.
The "PermitRootLogin off" is not recommended, you effectively deny root access (including certificate based access) and that can have unexpected consequences.
b) if you have set a root password and you do not want to use it anymore, make sure you apply the command: passwd -dl root (from the top of my head, verify this please)
The -d flag is for "password deletion" and the -l flag is for "lock", implying that the above command makes sure that you do not have root account with password.
c) one can also consider the following approach for Roundcube development:
- create a development subdomain with Plesk
- put a copy of all the Roundcube files in the root directory of the subdomain
- work within the subdomain and immediately see the changes or effects of changes
and the big advantage is that you can keep using FTP and keep your original Roundcube installation intact. It is in essence a staging environment.
I would certainly recommend this latter approach to Roundcube development.
Regards
A mistake can be made very fast indeed.
Some things to note:
a) you should set "PermitRootLogin without-password" if you want to return to certificate based root (SSH) access.
The "PermitRootLogin off" is not recommended, you effectively deny root access (including certificate based access) and that can have unexpected consequences.
b) if you have set a root password and you do not want to use it anymore, make sure you apply the command: passwd -dl root (from the top of my head, verify this please)
The -d flag is for "password deletion" and the -l flag is for "lock", implying that the above command makes sure that you do not have root account with password.
c) one can also consider the following approach for Roundcube development:
- create a development subdomain with Plesk
- put a copy of all the Roundcube files in the root directory of the subdomain
- work within the subdomain and immediately see the changes or effects of changes
and the big advantage is that you can keep using FTP and keep your original Roundcube installation intact. It is in essence a staging environment.
I would certainly recommend this latter approach to Roundcube development.
Regards
Similar threads
