So be sure when you step, Step with care and great tact. And remember that life's A Great Balancing Act.
Theodor Seuss Geisel
Security, like the rest of life, is a great balancing act. A rock on the bottom of the ocean is about the most secure thing in the world, but it's not terribly useful... There are always tradeoffs.
Generally, FTP should be avoided, because with normal FTP your passwords will be sent over the wire in plaintext and vulnerable to replay attacks. All of your data will also be sent over the wire in plaintext, so adiós to any sense of confidentiality for the data you sent that way. There are still times with FTP makes sense to use though, most especially over very lossy, high latency networks, when transferring content that is already public, like static website resources. If you're forced to use FTP, and you will do so repeatedly, make sure to choose a client and server that at least encrypt the authentication.
On any network connection that isn't the equivalent of institutional Grade D beef, you should be using SFTP (SSH File Transfer Protocol) or FTPS (FTP over TLS/SSL).
Sometimes you have a single User Account that you want to share with multiple devices. For example, maybe you want your Tablet to connect to SFTP to your Linux box, but you don't want that key to have full shell access.
Sometimes you should use the "full solution" of creating a separate user account, giving that user a locked down, perhaps chrooted shell, but then you need to figure out the user/group permissions of the files in question, how to maintain those permissions over time, and whether those permissions changes will be compatible with the rest of the required workflow.
There's a little used, not widely understood feature of SSH's ~/.ssh/authorized_keys file, you can prefix each key with:
# authorized_keys "command" example...
command="/usr/local/bin/file-transfer-only" ssh-rsa AAAA...Then for /usr/local/bin/file-transfer-only you could put something like:
#!/bin/bash
case $SSH_ORIGINAL_COMMAND in
'/usr/lib/openssh/sftp-server')
exec /usr/lib/openssh/sftp-server
;;
'scp'*)
exec $SSH_ORIGINAL_COMMAND
;;
'rsync'*)
exec $SSH_ORIGINAL_COMMAND
;;
*)
echo "Access Denied"
;;
esacMost Android "SFTP File Transfer" interfaces like Solid Explorer or the Fx File Manager use /usr/lib/openssh/sftp-server to get the SFTP transfer started, while most command line users will use scp or rsync to move files around.
This can be a nice in-between solution. Far better than sharing an SSH key between multiple devices (because you can easily remove it if any device/user is now gone, accountability, etc) but also a far simpler solution than a whole new account.
It ultimately depends on what you're doing.
You could even experiment with doing a chroot in this script to further tie things down, though keep in mind the chroot environment usually needs several things mounted for kernel access.
If you have any problems getting this setup, just turn on debugging on your SSHD server, and watch the log on your SSHD server, and you should be able to figure it out if you read carefully.
# /etc/ssh/sshd_config
# Change LogLevel
LogLevel DEBUG
# Save and Quit
systemctl reload sshOn Debian, the SSHD logs will be under:
/var/log/auth.log
On RHEL the's are /var/log/secure
If it's neither of those, you might be stuck using journalctl to access the sshd logs.
If you turned on DEBUG level logging, don't forget to turn it back off.
Enjoy your Linux adventures!