Recording contractor and vendor sessions on Linux servers

Say a contractor gets an SSH key to a shared account like deploy or ubuntu. When something breaks a week later, you have a bash history file at best. It lists commands without their output, it mixes everyone who used that account, and the contractor could have edited it.

Waiting on the vendor's own evidence is slow. In January 2022, Okta alerted its support contractor Sitel to a compromise of a Sitel engineer's account. Okta received the complete investigation report on March 22, two months later, and its security chief wrote of being "greatly disappointed" by the wait.

Security frameworks treat this as your job. The NIST Cybersecurity Framework 2.0 lists it as outcome DE.CM-06: activities of external service providers are monitored to find potentially adverse events.

Put shellz on each machine the contractor will work on. Every account on the box then logs in through the recorder, so their interactive logins, one-shot remote commands, file transfers and container shells get captured. The contractor installs nothing and changes nothing.

Create one Linux account per contractor, such as contractor-rk, instead of handing out a shared login. Their sessions then sit under one name you can filter by, and the source IP shows where each one came from.

Contractors don't need a shellz account to be recorded. Only the people who view recordings join your shellz team.

The following case is hypothetical. An agency upgrades PostgreSQL on db-02 on Saturday night. On Monday a reporting job fails, and the client asks whether anyone touched the cron jobs.

The client's admin filters sessions by contractor-rk over the weekend and finds three. A search for crontab hits one session. The replay shows the contractor listed the crontab and closed it without saving. The integrity badge says verified, so no part of the recording is missing or altered.

If the contractor had edited the file, the same replay would show the exact line, and the agency would know what to undo. For deeper post-incident work, see incident investigation.

If the job needs root, the contractor also has the power to tamper with whatever is watching them.

If anyone edits shellz's configuration, it puts the setting back within seconds and alerts you by email, Slack or webhook. Uninstalling requires your approval in the dashboard. A machine that goes silent triggers an alert inside a minute. A contractor with full root could still meddle with the recorder, and that meddling gets caught and reported.

When a client asks what changed on their server, an agency without records relies on memory and a ticket thread. A recording lets you show the exact commands and output instead.

If the agency runs shellz on client servers, export the sessions that matter as a replay file (.cast) or a text transcript (.txt) and send them with your report.

Inviting a client's staff into your shellz team is possible, but members can see every server the team records. Keep that in mind before you invite one client into a team that also covers another client's machines.

Remove the contractor's Linux accounts and keys on the servers. That part happens outside shellz. Their past sessions stay in your account, and uploaded recordings can't be deleted.

If agency staff were members of your shellz team, remove them from the team page. With Perfect Secrecy turned on, removing a member rotates the team's decryption key, so they can't read anything recorded after they leave. See the security model.

shellz is a recorder. Approving access ahead of time, keeping credentials out of the contractor's hands, stopping a command and cutting off a session in progress all need an access gateway; the PAM vs session recording guide covers when that's worth paying for.

When a contractor types a password into sudo or passwd, it stays out of the recording. Whatever appears on screen goes in, so ask them not to paste tokens into commands. Windows servers, RDP, Kubernetes and direct database connections are outside what shellz records.

Contractors need Linux accounts on your servers, not seats in shellz, so they don't add to the bill. You pay for your own staff: nothing across 10 active devices, or $10 monthly per shellz team member on Commercial, with $1 per stored GB and unlimited devices (plans).