Temporary SSH access: how to avoid permanent keys for short-lived work

When temporary SSH access is useful

• Contractors on a fixed project timeline
• Incident response when someone needs shell access quickly
• Maintenance windows with a known start and end
• On-call coverage for a specific shift

The manual way

The usual workflow: add a public key to authorized_keys, set a calendar reminder, remove the key later. It works for one server and one person once in a while.

Why reminders fail

Reminders slip during busy weeks. The person who added the key leaves the team. Tickets get closed before cleanup happens. Emergency access feels urgent; revocation feels optional. Over months, temporary grants become permanent.

What good temporary access needs

Every grant should answer:

• Who — which person or role
• Server and account — which machine and Linux user
• Reason — project, incident, or maintenance context
• Start time — when access becomes valid
• End time — when access should stop

Example access windows

• Contractor access for 7 days — start Monday 09:00, end the following Monday 17:00
• Maintenance window — Saturday 09:00–17:00 for deploy work only
• Incident access for 2 hours — immediate grant, automatic expiry when the bridge closes

Cleanup and audit requirements

Record who approved access and when it should end. After expiry, verify the key is gone from authorized_keys. Lightweight activity events help you reconstruct who had access during an incident review.

How GrantSSH handles time-bound permissions

Permissions have schedules. The open-source agent syncs authorized_keys locally — keys appear while access is active and are removed when it ends (typically within 30–120 seconds on the next sync). Users keep their normal SSH workflow; no bastion or proxy sits in the path. Existing sessions are not forcibly terminated when access expires.

Related: on-call SSH access · how GrantSSH works