The user needs shell access and a home directory somewhere outside of the web server’s document root (one good place is \/home\/username).<\/p>\n
The website owner also needs to own the php-fpm pool that corresponds to that website (user = websiteowner1 in the configuration file which creates the pool, see this post<\/a> for more details).<\/p>\n Once this is done, it’s time to allow access to external software tools\u00a0which support SFTP (such as Adobe Dreamweaver CC, FileZilla and others).<\/p>\n You need a way of signing in to the remote server using ssh without authenticating as root.\u00a0You should\u00a0assume superuser privileges (sudo su) only after successful authentication with lower-tier credentials (for example, identified as “administrator”, “ec2-user”, “centos” or whatever you choose to name your remote\u00a0user). Do not edit the sudoers file. Instead, add your user to the group wheel:<\/p>\n and you will be able to sudo su after successful authentication. (By default, all members of the CentOS\/RHEL\/Fedora store SSH server settings in \/etc\/ssh\/sshd_config:<\/p>\n In order to override the default of “no subsystems”, make sure that this line is not<\/strong> commented out:<\/p>\n To disable remote logins with the credentials of the root user, make sure you have the following entry:<\/p>\n When you complete changes to \/etc\/ssh\/sshd_config, restart the sshd service:<\/p>\n Now it’s time to set up access for your site owners.<\/p>\n On the client machine from which you wish a user to connects, create a key pair. This has to be done locally on the computer that is going to initiate a connection; this is the only way to ensure that the private key does not\u00a0traverse a network.<\/p>\n On a Linux desktop, this simple task is best accomplished by running ssh-keygen, for example:<\/p>\n On a Windows desktop, you can create OpenSSH keys using\u00a0PuTTYgen as described in this post<\/a>.<\/p>\n A key can be protected by a passphrase. The passphrase, however, is non-recoverable. Should it get lost, your user will need new keys and you will have to repeat the setup. Unless you set a passphrase, however, anyone in the possession of the\u00a0private key can gain access to the server. The balance between security and\u00a0usability is a question of your priorities<\/strong>.\u00a0On systems which represent high-value targets, a passphrase adds tangible value to the setup. This is also the case when the private key resides on a mobile device which can easily be lost\u00a0or stolen.<\/p>\n IMPORTANT: Each public key must be provided as a one-liner on a separate line.<\/strong> This is the\u00a0format PuTTy ‘s Key Generator will display right in its application window (it’s not the same public key\u00a0you obtain when you click on “Save public key”! It is important to be aware of this not-so-subtle distinction.)<\/p>\n Set permissions on your private key (the one which remains stored on your local computer):<\/p>\n (In the above example, id_rsa is the name of your private key and ~\/.ssh is the containing directory).<\/p>\n On SELinux-enabled systems you also need to make sure that the .ssh directory\u00a0has\u00a0the correct SELinux contexts:<\/p>\n The same goes for its contents:<\/p>\n In order to apply any corrections based on the system defaults, run restorecon:<\/p>\n Only the public key is transferred to the server; the private key remains on the machine where it was generated.<\/p>\n Install the public key on the remote server\u00a0by appending it to the\u00a0~\/.ssh\/authorized_keys file, which is located in the home directory of the user the key is intended for:<\/p>\n A newly created user may have no .ssh directory. If this is the case, create it and set permissions on it as follows:<\/p>\n or permanently:<\/p>\n Create the key file:<\/p>\nStep 2. Disallow remote authentication by root and verify the ssh configuration\u00a0of your Linux server<\/h4>\n
usermod -aG wheel username<\/span><\/pre>\nwheel<\/code> group on RHEL\/CentOS\/Fedora can assume\u00a0sudo privileges). Next, verify the ssh setup of your remote machine.<\/p>\nnano \/etc\/ssh\/sshd_config<\/pre>\n
Subsystem sftp \/usr\/libexec\/openssh\/sftp-server<\/pre>\n
# Prevent root logins:\r\nPermitRootLogin no<\/pre>\n
systemctl restart sshd.service<\/pre>\n
Step 3. Create a key pair for remote access<\/h4>\n
$ ssh-keygen -t rsa<\/pre>\n
![\"PuTTgen:](\"https:\/\/www.cloudinsidr.com\/content\/wp-content\/uploads\/2016\/11\/PuTTYGen_save_keys_authorized_keys-2.png\")
<\/a>Step 4. Set permissions on the\u00a0private key on your local computer<\/h4>\n
$ chmod 700 ~\/.ssh\r\n$ chmod 600 ~\/.ssh\/id_rsa<\/pre>\n
[root@ip-1-2-3-4 .ssh]# ls -laZ\u00a0\r\ndrwx------. user1 user1 unconfined_u:object_r:ssh_home_t:s0 .ssh<\/pre>\n
[root@ip-1-2-3-4 .ssh]# ls -laZ\r\ndrwx------. user1 user1 unconfined_u:object_r:ssh_home_t:s0 .\r\ndrwx------. user1 user1 unconfined_u:object_r:user_home_dir_t:s0 ..\r\n-rw-------. user1 user1 unconfined_u:object_r:ssh_home_t:s0 authorized_keys<\/pre>\n
restorecon -R -v \/home\/kreativj\/.ssh<\/pre>\n
Step 5. Install your public key on the server<\/h4>\n
$ cat id_rsa.pub >> ~\/.ssh\/authorized_keys<\/pre>\n
chown -Rf user1:user1 \/home\/user1home\r\nchcon -R unconfined_u:object_r:ssh_home_t:s0 \/home\/user\/.ssh\/<\/pre>\n
semanage fcontext -a unconfined_u:object_r:ssh_home_t:s0 \/home\/user1home\/.ssh\/\r\nsemanage fcontext -a unconfined_u:object_r:user_home_t:s0 \/home\/user1home\/<\/pre>\n
touch\u00a0.ssh\/authorized_keys file<\/pre>\n