I am building a server that will need to accessible from the outside world for two operations:

1) I need to maintain it remotely (via ssh)
2) Automatically copy files to and from it from a second, dedicated machine (either via scp or vsftpd). The automated nature of this requires that the second machine either have a password stored in a script OR use keys with no passphrase. The second computer will be identical to the server (same physical security, same software, same configuration, etc...)


Do you think it is more secure to:

A) Only have a single user allowed to ssh into the machine and then install vsftp with a virtual user to do the automated copying. This way, even if the remote machine is compromised and the password/keys are stolen, a remote shell cannot be opened with this information. Only the vsftpd has been compromised.

B) Allow two users to ssh (the admin and the remote, automated user who will use scp) and NOT install vsftpd. The remote user would be an unprivileged user. By not installing vsftpd I will have reduced the number of open ports and the number of attack vectors?

Thanks!

The admin user will use a password protected ssh-key, so his security is not at stake, given the physical security of the primary server.

For the unprivileged user who is using an unprotected key on the secondary machine (either for ftp or ssh) the security risks are totally different. In case of ftp there is no effective protection for the transmission of the ftp password, you can sniff it with a packet analyzer like wireshark. If you use (unprotected) ssh-keys for scp you will get full encryption of your connection and data transfer between the two servers, BUT you will have to guard the clear text ssh-key on the second server very closely. Use the second method, because ssh always outperforms (any) ftp with respect to security.

For the automated cxn, consider using ssh-agent to initiate the cxn and put the copying process into a daemon, inside the ssh-agent env.
This way you can use a passwd that doesn't have to reside on (client) disk (unlike the ssh-key).