Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Im in the unfortunate position of having to give someone who I do not fully trust privileged access to a webserver to finish work that they never completed.

They will access the server remotely (ie I will not be able to see their screen).

What can be done to a) proactively limit any potential damage and b) accurately log anything they do on the server for analysis afterwards, even if things seem ok?

They will be updating a web application.

Thanks in advance!

--- More informtion: The server is a Ubuntu AWS server.

share|improve this question

migrated from Dec 6 '12 at 16:32

This question came from our site for computer enthusiasts and power users.

What kind of access did you give that person? (SSH, FTP, etc.) What privileges does he have? (root/sudo access for example?) If he has root privileges, he can just hide every trace. – gertvdijk Dec 6 '12 at 12:52
It will be SSH access. Root access will be required (via sudo). He doesn't know the system outside of the web application. Maybe there are obscurely hidden logging applications? – edo Dec 6 '12 at 13:05
The only workaround I can think of is to use remote logging so that he can't wipe his traces out. If root access is really required, then you should use another workflow. For example, let him create a Puppet file in which he describes the target state of the machine configuration which you can examine and apply if you approve. – gertvdijk Dec 6 '12 at 13:12
Limit them to the directory they need. Why exactly does he need root access? – Ramhound Dec 6 '12 at 13:30
Is that "do not trust fully" as in "he's an idiot" or "do not trust fully" as in "I fully expect her to use any access she's given to try and exploit the server"? – RobM Dec 6 '12 at 17:25

You could give them an unprivileged account that has sudo access, but in /etc/sudoers you only give access to the command rootsh.

rootsh logs everything that takes place in a root shell, and you can push the logs to syslog and have them sent to an external server immediately.

It isn't bulletproof, but you must trust this person to some degree to even entertain the idea.

share|improve this answer
Additionally within sudoers, specify the commands this user will want to run with the NOPASSWD option. – Wesley Werner Dec 6 '12 at 13:29

Consider another approach, using a Configuration Management tool. One of which might suit your needs and is more powerful: Puppet.

Let the guy put all configuration to be done in a Puppet file. Advantages:

  • A very robust way of managing the configuration changes. All is in a file, rather than describing what has been done.
  • You will stay in control, as it lets you...
    • try the configuration on another machine and verify it.
    • decide to apply it whether it looks good or not.
    • pick the moment in time the changes take place
  • Reduce the time the changes are happening. It's automated.
  • You can repeat a similar configuration very easily just by customizing the configuration definition.

It boils down to this: the person responsible for the actual application configuration does not need shell access and it provides a way of separating responsibilities of him and the system administrator(s).


Big practical disadvantage too: it's a big elephant to smash this mosquito, so it might not fit your current situation. Not everyone is familiar with Puppet and low-quality Puppet definitions are worse than having a script setting it all up.

This leads me to another similar but simpler approach: let the guy develop a script that runs the necessary commands to change the configuration. It has some of the advantages listed above, yet does not require that much of an elephant of a tool.

share|improve this answer
So, edo should implement a whole config management system from the ground up, to accomplish his request? I don't disagree that having Puppet is a good idea for many environments, but if he only has one webserver, this would be a huge timesink with little return. – mfinni Dec 6 '12 at 16:38
@mfinni No, he could. It's just another approach suggested worth checking out and might be useful for other viewers of the question in a possible slightly other type of environment. It's an elephant, yes, yet provides other advantages too. – gertvdijk Dec 6 '12 at 16:42

Take a snapshot / make a backup before they start.

share|improve this answer
Not quite an answer I'm afraid. Damage in some forms might already have taken place (e.g. stealing SSL private key) and it doesn't log anything. It will only allows you to revert to an earlier state of the machine. – gertvdijk Dec 6 '12 at 16:45
Agreed, good point – mike42 Dec 6 '12 at 16:48
Not entirely; one could diff the final machine with the snapshot at the end of the work, to examine what had changed. – MadHatter Dec 6 '12 at 16:52
@MadHatter True. Yet, that probably hold an enormous amount of noise (log files, installed packages, etc.) and, it's not completely waterproof - for example, he could run a backdoor in a tmpfs which will survive until a reboot (yet that may be long enough to do more damage). – gertvdijk Dec 6 '12 at 16:56

Set that account up so that he is given a screen session (can attach with -rx at any time), probably with script enabled...

share|improve this answer
How does that prevent him doing harmful stuff? (e.g. running commands as root and then quickly wiping traces, using SFTP, using another SSH connection with forced-command, etc.) – gertvdijk Dec 6 '12 at 16:48
If more than auditability is desired, dont give him root :) and sftp could be restricted to a nonprivileged account used to transfer stuff, serverside forced-command is your friend even, and a chattr +a on certain log/script files plus removing CAP_LINUX_IMMUTABLE will make it rather difficult to wipe traces.... – rackandboneman Dec 6 '12 at 17:03

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.