It’s foolish to use an absolute term such as securely in the context of computer security. A better title would have used the qualifier more. If you happen to be a security expert, please be so kind as to leave a comment with any tips, admonishments, etc.
I need to allow users to upload files to a web server via an SFTP client, period. I don’t want them to be able to do anything else, and I don’t want them to be able to see any files other than their own.
SSH configuration is located in the /etc/ssh/sshd_config file.
I prefer to disallow the root user from logging in remotely via ssh, change yes to no for PermitRootLogin:
I prefer to disallow using passwords when logging in remotely, so I require the use of public keys. Change yes to no for PasswordAuthentication. Before you activate the following line, make sure you’ve setup your SSH keys properly or you may lock yourself out of your server. The short answer is to generate a public/private key pair on your local machine and place the public key (typically id_rsa.pub) in the ~/.ssh/authorized_keys file on the server, then test it by logging in via ssh – you should not be prompted for a password if successful:
To allow access for these special sftp users, I change the Subsystem sftp line to be:
Subsystem sftp internal-sftp
and add the following at the very end of the config file:
Match Group sftp ChrootDirectory /home/%u PasswordAuthentication yes X11Forwarding no ForceCommand internal-sftp
The Match statement sets up a chroot jail for any user in the sftp group so that the user will only have access to their home directory. It also overrides the global rule to disallow password login so the sftp users may use the traditional means of username/password to login. It also forces them to use the sftp command instead of allowing normal shell access.
To activate these changes, restart the ssh daemon:
sudo /etc/init.d/ssh restart
When adding users, we need to ensure they’re in the sftp group so that the Match statement in sshd_config will actually match. Alternatively, you could match on some other criteria such as username. First create the sftp group:
sudo groupadd sftp
Then add a user with that group and no shell specified:
sudo adduser --shell /bin/false --ingroup sftp brian
That should take care of everything. Test the new user by attempting to login via ssh:
ssh email@example.com firstname.lastname@example.org's password: This service allows sftp connections only. Connection to 10.0.0.1 closed.
That should fail as shown above. Also test to see if you can view any directories outside of the users’s home directory:
sftp email@example.com sftp> ls /etc Couldn't stat remote file: No such file or directory Can't ls: "/etc" not found sftp>
Some additional tools to enhance security:
- shorewall firewall
- fail2ban (locks ip addresses out for a time period after N failed attempts)
- rkhunter (checks for root kits)
- chkrootkit (checks for root kits)