Say I am connecting to a server via SCP and copying some files from the remote server to my home computer. Can the server admins tell that I have copied something, see what was copied, or know who copied it?

  • 2
    use sftp. It might be logged, but it is not clearly visble as the process title of scp.
    – Jakuje
    Feb 18, 2016 at 13:15
  • 2
    Probably just a matter of changing the log level on the server? Didn't check.
    – jcaron
    Feb 18, 2016 at 14:32
  • 14
    I'd always assume everything is closely watched and logged if you're not in control of the sever.
    – axk
    Feb 18, 2016 at 16:06
  • 3
    Server admins can see everything you do on their server; that's kinda implied by the term "admin". The only question is whether they're actually paying attention or care.
    – Ajedi32
    Feb 19, 2016 at 16:22

6 Answers 6


A ServerFault question is almost identical to this. Hopefully you checked before posting your question, but yours is a little different so I will answer here.

The short answer is that if ANYONE has access and permissions to an endpoint (the system you are scping from or scping to), they can see what happens. If they do not have access to either endpoint, they likely won't have access to or be able to decipher what you're doing (apart from potentially knowing the application by protocol numbers).

The answer is ultimately very dependent on your infrastructure. Most likely though, as long as there isn't intense monitoring and SCP isn't considered at threat in the company (which will throw up red flags), your traffic will go by unnoticed. This is especially true for smaller companies.

As @SimonRichter mentioned: if someone can execute a command on your system (ie. admin or others), they can check your process list and see the command line scp -args /filepath/. However this requires that they be either logging all process activity or checking it at the time you are transferring. Additionally, if you are doing it from your own system at work to another system (say at home or elsewhere), they won't necessarily have that visibility.

Additionally, as @alex.forencich mentioned: It is also possible to log all system calls (including file open and read calls) so even if your copying program (scp, sftp, etc.) does not log or leak anything (command line arguments), it is still possible to figure out what files were read or written. See the linux audit system. –

  • It is also possible to log all system calls (including file open and read calls) so even if your copying program (scp, sftp, etc.) does not log or leak anything (command line arguments), it is still possible to figure out what files were read or written. See the linux audit system. Feb 20, 2016 at 12:06
  • Thanks @alex.forencich , I am adding your comment to the answer!
    – Abraxas
    Feb 20, 2016 at 18:12

Not just the admin.

For testing, I just copied /bin from my server to a temporary directory on my laptop. ps on the server shows

$ ps 24096
24096 ?        Ss     0:00 scp -r -f /bin

This information is generally accessible to all users.

  • 6
    For kernel>=3.2, (re)mounting /proc with option hidepid=2 disables this..
    – heemayl
    Feb 19, 2016 at 16:45
  • "This information is generally accessible to all users." Huh, really? All users can see what all other users are doing? I haven't tried it but that seems unlikely to me. Even on Windows you can only see your own processes (unless you're an admin and click on a special admin button). Feb 20, 2016 at 18:29
  • @PreferenceBean, yes, but that is the default setting. Depending on how the admin has set up the umask setting, other people's home directories may be readable as well by default. Feb 21, 2016 at 8:55
  • Showing information like that about another user like this sounds like a supremely dumb default. Feb 21, 2016 at 12:11
  • @CodesInChaos, that is an old decision, made for a time where people had to share the computer cooperatively, so it was best if you could easily tell who was hogging the CPU and why, so you could talk to them. These days, no one bothers generally, because very few people actually log in to shared computers. Feb 21, 2016 at 12:24

scp works with the help of code running on the server (sshd, and scp itself). That sever code is in theory completely in the control of the server admin, and the version of scp running on the server to write the file down the connection to you, is separate from the version of scp running on your machine to issue the request.

An administrator of the server could, just for an example, replace scp on the server with a version that logs all requests, rather like a web server can write logs. Then they could see from those logs exactly what you copied.

Whether they have the expertise and the motivation to actually do this is less definite, but if they want to then in principle there's nothing to stop them.

I think these questions are companions to yours: https://security.stackexchange.com/questions/14782/is-there-an-easy-way-to-see-a-log-of-scp-activity-on-a-server-ala-var-log-secu, https://askubuntu.com/questions/659896/where-would-you-find-scp-logs

Although I don't know all the details, it seems that straight out of the box scp and sshd don't have options to log what you're asking about. So perhaps more is required than simple configuration, but you can't get away from the fact that admins control the server.


Anything that passes unencrypted through the memory of a computer can be read or changed by a sufficiently privileged user on that machine.

The names of running processes and the command line used to start them are accessible to any logged-on user on Linux. (This is not the case on Windows, for the curious.) Therefore, the admin or anybody else who happens to be around could see which files you copied. Additionally, it's entirely possible for the administrator to have set up some sort of file access logging, or to have replaced/jiggled the scp program on one end to do extra logging.

scp just protects you from network sniffers. Obviously, both ends have to know the decrypted data, so there's the opportunity for a sophisticated admin on either of the endpoints to suck the data out of scp's memory. Other solutions, even those that don't involve command lines, are also open to that: both ends of sftp know what's going on, so it's possible to determine via memory inspection what sftp is thinking/transferring.


A rule of thumb is, a person with root access can know everything (if he can be bothered to check). Probably the only thing that's off limits is a certificate-encrypted filesystem.

during the act, the scp opens a process on the remote side, which can be seen by anyone just by invoking ps. If you manage to hide the commandline showing up in the process list, then lsof (list of open files) can show which files are being touched. It's so easy, I'm actually doing that to observe how far some copy process I started is, if I started the process on a terminal I can't view at the moment (where the file list is being output).

after the act, a quick scan with find can find the newest files (if the timestamps weren't preserved during copy). If the files were accessed or touched in any way through a ssh session, your .bash_history shows what you were doing (but you can delete that if you want).

If security's meant to be very strict, you can always set up additional monitoring: you can listen to all file modifications with a simple daemon, and log everything about filesystem transactions, local and remote, doesn't matter. It wouldn't be a surprise to log all user-spawned processes. If backups are being done, the files may be still stored somewhere after you delete them.

  • When you wrote file, did you mean find?
    – user
    Feb 19, 2016 at 13:20

The server admins are able to monitor any traffic that travels into or out of their server, so they could easily monitor SCP traffic if they wanted to, and see that you have copied files and what files you have copied.

  • "that you have copied files" is very different from "what I copy" as indicated by the OP.
    – user
    Feb 18, 2016 at 10:49
  • they can see that too Feb 18, 2016 at 10:54

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.