Managing Contractor and Vendor SSH Access

Contractors and vendors need temporary access to your infrastructure. Managing that access with traditional SSH keys creates security and operational problems: keys get copied across machines, shared between team members, and never fully cleaned up when engagements end. You have no visibility into what contractors did during their sessions. When a contract expires, you’re left hunting down and rotating keys across every server.

Twingate addresses these problems by replacing SSH keys with identity-based authentication, short-lived certificates, and automatic access expiry. Contractors authenticate through your identity provider, access is scoped to specific servers via group membership, and every session is recorded and tied to their real identity. When the engagement ends, access revokes instantly with nothing to clean up.

The problem with contractor SSH access today

Traditional SSH key-based access for contractors creates several problems:

Keys live forever and get copied everywhere. You generate an SSH key pair for a contractor. They copy it to their laptop, their personal desktop, and maybe their backup drive. The private key never expires. When the engagement ends six months later, you need to remember to remove that key from every server’s authorized_keys file — but you have no reliable way to know where it was distributed or whether copies still exist somewhere.

No visibility into contractor actions. Standard SSH logging tells you a connection occurred. It doesn’t tell you what commands the contractor ran, what data they accessed, or what configuration changes they made. When you need to audit third-party access for compliance or investigate an incident, you have connection timestamps but no record of what actually happened during the session.

Revocation means manual cleanup across every server. When a contractor’s engagement ends, you need to edit authorized_keys on every server they had access to. Miss one server and the contractor retains access. Tracking down every instance is time-consuming and error-prone, especially across hybrid or multi-cloud environments with hundreds of servers.

How it works with Twingate

Twingate uses identity-based authentication with short-lived certificates instead of SSH keys. Access is controlled through group membership and time-bound policies, and every session is automatically recorded.

Identity-first authentication. The contractor authenticates through your identity provider (Okta, Entra ID, Google Workspace, or any SAML/OIDC provider). When they SSH to a server, Twingate verifies their identity and access permissions through the Twingate Client. The SSH Gateway issues a short-lived certificate for that specific session. The contractor never holds a persistent credential.

Group-based access control. You create a Twingate group for the engagement and assign the relevant SSH Resources to that group. The contractor is added to the group and immediately gains access to the specified servers and nothing else. Access is scoped to exactly what they need. When you remove them from the group, access is revoked instantly across all servers.

Time-bound policies for automatic expiration. You apply a Security Policy with time-based restrictions to the contractor’s access. Set a start date and an end date matching the engagement period. When the end date arrives, Twingate automatically denies access. No manual revocation needed. The contractor’s access expires on schedule even if you forget to remove them from the group.

Every session recorded and tied to identity. The SSH Gateway captures a complete terminal recording of every command in every session in asciicast v2 format. Each recording is tied to the contractor’s authenticated identity, not a shared Linux username or an IP address. Recordings are exported to stdout on the Gateway and stay entirely on your infrastructure. Forward them to your SIEM for real-time monitoring, archive them in S3 for retention, or replay them in the browser at twingate.com/sessionplayer.

Instant, global revocation. When you need to revoke access, you remove the contractor from the Twingate group. Access is revoked immediately across all SSH Resources, with no cleanup required. Because Twingate uses certificate-based authentication through the SSH Gateway, there are no SSH keys to find and remove from authorized_keys files. Access terminates the moment the group membership changes.

Setting up contractor access

Follow these steps to grant a contractor SSH access to specific servers with automatic expiration and session recording.

1. Create a Twingate group for the engagement

Create a dedicated group for this contractor or engagement. Avoid adding contractors to broad groups that include employees or other contractors.

In the Twingate Admin Console:

• Navigate to Teams > Groups
• Create a new group with a descriptive name: Acme Consulting - Prod Servers, Q1 2025 Security Audit, or Contractor - Jane Smith
• Leave the group empty for now

Creating a dedicated group gives you clean isolation: you can apply time-based policies to this specific engagement, revoke access instantly by deleting the group, and audit exactly what this contractor had access to.

2. Assign SSH Resources to the group

Add the specific SSH Resources the contractor needs to the group. Grant the minimum access required for the engagement. If they’re deploying to staging, don’t give them production access.

In the Twingate Admin Console:

• Navigate to Resources
• Find each SSH Resource the contractor needs
• Edit the Resource and add the contractor group to the Access section

Each SSH Resource represents one or more SSH servers. If you need to grant access to multiple servers, add the contractor group to each relevant Resource. If the servers are logically grouped (e.g., all staging servers), you may have a single Resource covering them.

3. Add the contractor to the group

Add the contractor’s user account to the group. The contractor must have a Twingate account authenticated through your identity provider.

If the contractor doesn’t have an account yet:

• Add them to your IdP (e.g., Okta, Entra ID) as an external user or guest
• Invite them to Twingate. They authenticate via SSO and appear in your user list
• Add them to the contractor group

Once added to the group, the contractor gains access to all SSH Resources assigned to that group.

4. Apply a time-based Security Policy

Apply a Security Policy to the contractor group with time-based restrictions. Set a start date and an end date matching the engagement period. Access will automatically expire when the end date arrives.

In the Twingate Admin Console:

• Navigate to Security > Policies
• Create a new policy or edit an existing contractor policy
• Under Schedule, set Access Window:
  • Start Date: The first day of the engagement
  • End Date: The last day of the engagement (or a date shortly after)
• Under Apply To, select the contractor group
• Save the policy

When the end date arrives, Twingate denies all SSH access for this contractor. This happens automatically. You don’t need to remember to manually revoke access.

You can also apply other restrictions in the same policy: require MFA, enforce device posture checks (e.g., disk encryption, OS version), restrict access to specific geolocations, or limit access to specific hours of the day.

5. Contractor setup: Install Twingate Client and connect

The contractor installs the Twingate Client on their workstation, authenticates, and enables SSH config auto-sync. They connect using their standard ssh client. No custom CLI or wrapper required.

Contractor instructions:

• Download and install the Twingate Client for your operating system (macOS, Windows, or Linux)
• Launch the Client and sign in. You are prompted to authenticate via SSO
• In the Client settings, enable Auto-sync SSH Server Configuration (this populates your SSH config automatically)
• Connect to Twingate by clicking Connect in the Client

Once connected, run ssh as usual:

ssh my-server.internal.company.net

The Twingate Client routes the connection transparently. The SSH Gateway authenticates you via your identity and proxies the session to the target server. You’re authenticated via certificate. No SSH key pair needed.

All your existing SSH tools work: scp, sftp, VS Code Remote SSH, JetBrains Gateway, Ansible, Terraform. The Twingate Client operates transparently alongside native OpenSSH.

Revoking access

When the engagement ends or access needs to be revoked immediately, remove the contractor from the Twingate group. Access is revoked instantly with no cleanup.

Manual revocation

In the Twingate Admin Console:

• Navigate to Teams > Groups
• Open the contractor group
• Remove the contractor’s user account from the group

Access is revoked immediately across all SSH Resources. The contractor can no longer establish new SSH sessions. Any active session continues until it closes, but no new connections are permitted.

If you need to terminate active sessions immediately, restart the SSH Gateway or use your server’s session management tools (e.g., pkill -u username on the target server).

Automatic expiration via time-based policies

If you applied a Security Policy with an end date, access expires automatically when that date arrives. Twingate denies all connection attempts from the contractor. You don’t need to manually remove them from the group. The policy enforcement handles it.

This is the recommended approach for contractor access: set the end date when you grant access, and let the policy enforce automatic expiry. If the engagement extends, update the policy’s end date rather than relying on manual revocation.

Why this is easier than key-based revocation

With traditional SSH key-based access, revoking a contractor’s access means:

• Finding every server they had access to
• Locating and editing the authorized_keys file on each server
• Removing the contractor’s public key from each file
• Ensuring no copies of the private key exist anywhere
• Repeating this process for every contractor departure

With Twingate, you remove the contractor from a group. Access is revoked globally and immediately. Because the SSH Gateway uses certificate-based authentication, there are no authorized_keys files to edit, no keys to rotate, and no persistent credentials to track down. The certificate authority stops issuing certificates for that user.

Auditing contractor sessions

Every SSH session is recorded automatically and tied to the contractor’s real identity. You get a complete audit trail of what each contractor did on every server they accessed.

Session recording format

The SSH Gateway captures every session in asciicast v2 format, an open standard for terminal session recordings. Each recording includes:

• Every command the contractor typed
• All output returned by the server
• Exact timing information for command execution
• The contractor’s authenticated identity (their email or username from your IdP)
• The target server hostname and IP
• Session start and end timestamps

Binary payloads from file transfers (SCP, SFTP) are automatically excluded to keep recording sizes manageable.

Accessing session recordings

Recordings are exported to stdout on the SSH Gateway. You control where they go and how long they’re retained.

Forward to a SIEM for real-time monitoring: Configure the Gateway to forward recordings to Splunk, Datadog, Elastic, or any log aggregation system. Monitor contractor sessions in real time, alert on suspicious commands, and correlate SSH activity with other security events.

Archive in S3 or object storage for compliance retention: Store recordings in S3, GCS, or Azure Blob Storage with lifecycle policies for long-term retention. Recordings can’t be modified once written. For compliance audits (SOC 2, ISO 27001, PCI-DSS, HIPAA), you can produce a complete record of every contractor’s activity on sensitive systems.

Replay in the browser: Visit twingate.com/sessionplayer, upload an asciicast file, and replay the session in the browser. You see exactly what the contractor saw: every command, every output line, with accurate timing. This is useful for incident investigation, security reviews, and knowledge transfer.

Querying session logs

Because each session recording includes the contractor’s identity (not a shared Linux username), you can easily answer audit questions:

• What servers did contractor X access last month?
• What commands did contractor Y run on production servers?
• Did contractor Z access any customer data during their engagement?
• Show me all commands run by contractors on this specific server.

If you’re forwarding recordings to a SIEM, you can query by contractor email, server hostname, command patterns, or session duration. If you’re storing recordings in object storage, you can use the filename metadata (which includes timestamp and identity) to filter and retrieve specific sessions.

Best practices

Create dedicated groups per engagement

Avoid adding contractors to broad groups that include employees or multiple contractors. Create a dedicated group for each engagement, project, or individual contractor. This gives you:

• Clean revocation: Delete the group when the engagement ends, and all associated access is gone
• Precise auditing: You know exactly what servers this contractor had access to
• Scoped policies: Apply time-based restrictions and compliance controls specific to this engagement

Example group names: Contractor - Acme Consulting - Q1 2025, Vendor - Security Audit - Feb 2025, Contractor - Jane Smith - Infrastructure Migration

Always set an end date with time-based policies

Manual revocation requires you to remember to remove access when the engagement ends. Time-based policies enforce automatic expiry. Access terminates on the configured date whether you remember to act or not.

When granting contractor access, apply a Security Policy with:

• Start Date: The first day of the engagement
• End Date: The last day of the engagement (or a few days after to provide buffer)

If the engagement extends, update the end date. If it ends early, manually remove the contractor from the group. The policy provides a safety net: even if manual revocation is forgotten, access expires on schedule.

Separate contractor access from employee access

Don’t mix contractors and employees in the same groups. Create separate groups for contractors, even if they need access to the same servers. This makes it easier to:

• Identify contractor-specific access during audits
• Apply stricter policies to contractors (e.g., more frequent MFA prompts, restricted hours)
• Revoke contractor access without affecting employees
• Generate contractor-specific session recordings and compliance reports

Review session recordings periodically

For contractors accessing sensitive or production systems, periodically review their session recordings. Look for:

• Unusual commands or access patterns
• Access to data outside the scope of the engagement
• Commands that modify critical configuration files
• Copying large amounts of data via SCP or rsync

If you’re forwarding recordings to a SIEM, set up alerts for high-risk commands (e.g., rm -rf, chmod 777, wget from external IPs, database dumps).

Use your existing identity provider

Add contractors to your identity provider (Okta, Entra ID, Google Workspace) as external users or guests rather than creating Twingate-only accounts. This gives you:

• Single source of truth: All identity and access decisions are managed in one place
• Unified audit trail: Contractor authentication events appear in your IdP’s logs alongside employee logins
• Consistent MFA enforcement: Contractors use the same MFA policies as employees
• Lifecycle integration: When you offboard a contractor in your IdP, their Twingate access is revoked automatically

Most identity providers support guest or external user accounts specifically for contractors and vendors. Use these instead of creating standalone Twingate credentials.

Apply Zero Trust policies consistently

Contractors should be subject to the same (or stricter) device posture checks, MFA requirements, and geoblocking policies as employees. Twingate’s Security Policies apply uniformly to all resource types: network, SSH, and Kubernetes.

Common policies to enforce for contractors:

• Require MFA: Force multi-factor authentication for every login
• Device posture checks: Require disk encryption, up-to-date OS, and endpoint protection software
• Geoblocking: Restrict access to specific countries or regions
• Time-of-day restrictions: Limit access to business hours in the contractor’s timezone

Technical details

Certificate-based authentication via SSH CA

Twingate uses certificate-based authentication through an SSH Certificate Authority (CA). When a contractor connects via SSH:

• The Twingate Client authenticates the contractor via your IdP
• The SSH Gateway verifies the contractor’s group membership and policy compliance
• The Gateway requests a short-lived certificate from the Twingate SSH CA
• The certificate is valid for the duration of the session (typically minutes to hours)
• The Gateway uses the certificate to authenticate to the target SSH server
• The SSH server trusts certificates issued by the Twingate CA via TrustedUserCAKeys in sshd_config

The contractor never holds an SSH private key. The certificate is issued on-demand, used for a single session, and expires automatically.

No agent on SSH servers

The only change required on each SSH server is a one-line configuration in /etc/ssh/sshd_config:

TrustedUserCAKeys /etc/ssh/twingate_ca.pub

This tells sshd to trust certificates signed by the Twingate SSH CA. No agent, no daemon, no proprietary software. This works on minimal Linux systems, embedded hardware, and environments where installing additional software on servers isn’t permitted.

Session recording always enabled

Session recording is automatic. Every session is captured and tied to the contractor’s real identity. There’s no way to disable it, and contractors can’t bypass it. Recordings are generated by the SSH Gateway before the connection reaches the target server, so even if a contractor has root access on the server, they can’t tamper with the recording.

Group-based access control

Contractor access uses the same group-based model as all other Twingate resource types. You create a group, assign Resources to it, and add users. Access is granted by group membership. This consistency simplifies administration: you don’t need separate access control models for network Resources, SSH Resources, and Kubernetes Resources.

Time-bound policies with date and time restrictions

Twingate Security Policies support time-based access windows. You can specify:

• Access Window: Start date and end date for access (e.g., Feb 1 to Feb 28)
• Allowed Hours: Days of the week and hours of the day when access is permitted (e.g., Monday-Friday, 9am-5pm EST)

These policies are enforced at the Gateway. When a contractor attempts to connect outside the allowed window, the connection is denied before it reaches the SSH server.

Native SSH tooling, no custom CLI

Contractors use the standard ssh client, the same OpenSSH binary they already have installed. The Twingate Client routes the connection transparently. This means all SSH-based tools work without modification:

• Standard SSH: ssh, scp, sftp, rsync
• Remote development: VS Code Remote SSH, JetBrains Gateway, Cursor
• Automation: Ansible, Terraform remote-exec, CI/CD pipeline SSH steps
• Legacy tools: PuTTY, SecureCRT, MobaXterm

Tools that replace ssh with a custom CLI break these integrations. Contractors would need to learn new commands and reconfigure their tooling.

Comparison to alternatives

Traditional approach (VPN + SSH keys):

• Contractors hold long-lived private keys that never expire
• Keys get copied to personal machines and never fully cleaned up
• No session recording, only connection logs
• Revocation requires editing authorized_keys on every server

Other privileged access products:

• Achieve similar certificate-based authentication and session recording
• Require a custom CLI instead of native ssh, breaking IDE integrations and existing tooling
• Higher cost and operational complexity
• Separate product to deploy and maintain

Twingate:

• Certificate-based authentication with no SSH keys
• Native ssh support: contractors use standard tooling with no workflow changes
• Automatic session recording tied to real identity
• Group-based access with automatic expiry via time-based policies
• Same platform you use for network access and Kubernetes access: one console, one policy engine

Summary

Twingate eliminates the security and operational problems of contractor SSH access:

• No SSH keys: Contractors authenticate via your IdP, and the Gateway issues short-lived certificates per session
• Time-bound access: Security Policies with end dates enforce automatic expiry; access terminates on schedule
• Instant revocation: Remove a contractor from a group, and access is revoked globally with no cleanup
• Full session recording: Every command in every session is captured and tied to the contractor’s real identity
• Native tooling: Contractors use standard ssh, scp, VS Code, and JetBrains with no custom CLI

Set up contractor access in minutes: create a group, assign SSH Resources, add the contractor, apply a time-based policy. When the engagement ends, remove them from the group or let the policy expire. No keys to distribute. No authorized_keys files to edit. No persistent credentials to track down.

Join us in the community subreddit to share how you manage contractor access and what workflows have worked well for your team.