In my organization, users have the rights to transfer files to and from servers using SSH File Transfer protocol for a variety of reasons; e.g. application troubleshooting, BAU, etc.

Although our servers are configured with logging to keep track of what users have done, we would still like to control the file transfer operation done by the users in a sense that we would like to make it as a privileged operation and is allowed when a user have raised a valid request; not as and when they please.

The most effective way that I could think of is manually enabling / disabling the SFTP service whenever there is a request and having the user perform the file transfer operation on a dedicated workstation. But it does sound a bit strenuous though.

For FSI institutions, how do they control such operation?

  • Could you specify what you mean by FSI? There are several expansions that would fit the context. Are you interested in FSI because you are part of it, or because your organization is like it, or just as an example of good security? Are you affected by similar regulations? May 8, 2013 at 14:15
  • Likely financial services institution, but hopefully he should clarify. The fact that a bank does it one way should not be benchmark, though.
    – Eric G
    May 8, 2013 at 14:29

2 Answers 2


SFTP is a not really intended for what you are trying to accomplish. Anything else you would be implementing would be non-standard.

You may want to create a web app for upload where you can also implement a workflow where there are authorization requests and tickets associated with each request that an authorized user must use in order to initiate the file transfer. You could script something server side and still use SFTP.

In manufacturing and financial services, they may use any of a number of techniques and protocols like MQ, Web Services (SOAP/REST), which can build in additional functionality, rules, etc. There is also old school EDI systems with run sheets, and control files.

This is probably also a better fit for Super User since its really an operational problem (though you still need to implement the correct controls throughout the process).


You could write a custom PAM module that would allow access if a user wasn't listed in a database (so it doesn't affect your admin accounts) or if the user's database entry had an active support ticket. Drop a reference to your new custom auth module in /etc/pam.d/sshd.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.