Sometimes you just need to temporarily grant access to a user to copy some files to your server. But no user should have access to the shell. For sftp this is quite simple (see below), but for scp it’s not that trivial. Also, you probably want to set the user up in a directory with chroot so that they can’t inspect the server’s filesystem.
So there are 2 questions here: can we get by with just sftp? or is scp necessary?
This can be completely solved by modifying /etc/ssh/sshd_config to add a block like the one below and, for instance, adding a system user with NO login-shell to a group called sftponly:
Match Group sftponly
ChrootDirectory /my/chroot/directory/for/user/%u
X11Forwarding no
AllowTcpForwarding no
PermitTTY no
ForceCommand internal-sftp
This use case is a bit more complex, since in order to use scp, the system needs a login shell to be able to use it. But we don’t want (1) the user to be able to log in to the system, and (2) to hold the user inside a chrooted environment. So taking this approach implies we need special software. For this task I use software called scponly, and I’ll explain how to configure it here.
Install the software from the EPEL repository on your monitoring server:
yum --enablerepo=epel install scponly
In this package an important file is unfortunately missing. It’s the file to set up the chrooted environment (setup_chroot.sh), which you can download here. After extracting the script from the zip archive, copy it to your server and run it:
sh ./setup_chroot.sh
It will ask you for 3 things: a username, a home directory with a writable directory inside that home directory for the user (the rest of the directory must be owned by root, as the user should not be able to write there), and finally to set the password for the user.
After you execute the script and your chrooted home directory is set up, the user can then scp or sftp to the server, but they won’t have a login shell if they try to ssh to the server. That makes this a secure way to open scp/sftp for users to your server.