02 September 2010

Sharing a shell and monitoring the other party

Recently, I had a reason to allow someone else to use a shell on a machine for which I'm the admin, but I wanted a way to track what they're doing. You might think the history command is just fine for this, but it's possible to clear the history, and I wouldn't want that. Screen to the rescue!

I ssh'd into the machine and created a new user for my visitor. Then I switched to that user. Once logged in, I ran screen -L, which logs the shell (both input and output) to ~user/screelog.0). Then I called up the user, gave them the IP address, username, and password. They logged in, and I told them to run screen -ls to see a list of open screen sessions. The output looks like this:

There is a screen on:
 2119.pts-0.marlyn (09/01/2010 06:32:03 PM) (Attached)
1 Socket in /var/run/screen/S-maco.

The next step was for them to type screen -x 2119.pts-0.marlyn Once they did this, we could each see what the other saw in our SSH session, and it was all logged. Great! I could keep track of what they were doing as they were doing it and review the logs later for a double check.

It's not a VCS though. If you know what directory they'll be operating in, you might want to run bzr init ; bzr add ; bzr commit -m "starting point" first, so you can later run bzr diff | less to see what files changed and keep a record of what changed, since while it might all seem perfectly logical while it's happening, recalling the exact changes won't be easy. The point of watching can be to catch them in the act if they try to do something that violates your security policy or to be given a demonstration.

EDIT: After a question in comments about how you keep them from opening another non-screen'd connection, my friend Peter suggested adding screen -xR to the user's ~/.bash_profile, so it forcibly connects to the screen session. Thanks, Peter!


kiwi said...

Aren't they free to open another terminal with the same credentials and not use screen?

Mackenzie said...

Hmm... yeah good point. Could change some SSH settings and restart sshd while they're logged in. It won't kill the existing ssh connection but will prevent subsequent logins. I've usually used this for demos, but the recent case was a trusted third-party (where I wanted to be able to know what had been wrong to start with).

The Casual Vegan said...

This is an interesting security through obscurity trick.

However, they could still delete the log, or reset ~/.bash_profile

Instead, you should run:
chattr +a .bash_history

There are a few more things you have to watch out for. Complete details can be found here:


You should consider including a link to that article in your post. =)

高欣 said...

nice blog!