Managing permissions

A permission links a team member or group to one or more server accounts, optionally with a schedule. While a permission is active, the GrantSSH agent places the member's public key in each account's authorized_keys file. This guide covers granting access, scheduling it, using groups, and ending access when it is no longer needed.

If you have not set up a server yet, start with the quick start guide. For terminology, see Core concepts.

Who can manage permissions

Owners and managers can grant access, edit schedules, review access requests, and manage groups. Open any server, then choose Team access in the server navigation.

Members cannot grant access to themselves or others. They submit an Access request from the Access requests page or from a server's Request access flow. Once a manager approves the request, GrantSSH creates the same kind of permission as a direct grant.

Grant access directly

To grant access as an owner or manager:

1. Open the server and go to Team access.
2. Choose Grant access.
3. Select a team member or a group. You grant to one or the other — not both in a single form.
4. Select one or more server users (the Linux accounts on that host, such as deploy or ubuntu). Add accounts first under Server users if the list is empty.
5. Choose an access schedule, or leave it unrestricted for permanent access.
6. Submit the form.

GrantSSH creates one permission per server user selected. If the same member or group already has access to a server user, that combination is skipped — you cannot create duplicate grants for the same subject and account.

The granted person must have at least one SSH public key on the SSH keys page. GrantSSH stores public keys only; private keys never leave the user's machine.

Review access requests

When a member needs access they cannot grant themselves, they submit a request with:

• The target server
• One or more server users they need
• A reason (required)
• An optional proposed schedule

Only one pending request per server per member is allowed at a time. Owners and managers review requests from Access requests in the main navigation.

When reviewing a request, you can:

• Approve — adjust the server users and schedule if needed, then confirm. Approval creates permissions for the requester.
• Deny — optionally add a note explaining why. The member is notified.

Managers and owners grant access to themselves directly; they do not use the access-request flow.

Access schedules

Every permission can be unrestricted or limited by a schedule. Schedules control when the agent includes a member's public key in authorized_keys — access outside the schedule is enforced by key removal, not by blocking SSH at connection time.

Schedule types

Time windows

When using Selected days of the week, you can enable Restrict access to a certain time of the day to limit access to a start and end time on those days — for example 09:00–17:00 on weekdays.

All schedule times are in UTC. The grant form shows the current UTC time to help you align windows with your team's working hours.

Groups and bulk access

A group is a named set of team members on your team. Instead of granting the same server users to people one at a time, grant once to the group — every member inherits the same accounts and schedule.

To manage groups:

1. Open a server and go to Groups (under the team access section of the server navigation).
2. Choose Create group, name it, and select members.
3. Return to Team access → Grant access and select the group instead of an individual member.

You can edit a group's name and membership at any time. Deleting a group removes the group and any permissions that were assigned to it.

Adding or removing someone from a group changes which members receive keys for group-based permissions on the next agent sync. Members still need their own SSH public keys uploaded.

View and edit permissions

The Team access page lists everyone with permissions on that server, grouped by team member or group. Expand a row to see each server user, the schedule summary, and the UTC time window.

For each permission you can:

• Edit — change the schedule. The grant subject and server user cannot be changed; create a new grant if you need a different combination.
• Details — view the full schedule breakdown in a modal.

Date-range grants that have passed their end date display an Expired badge. Expired grants remain visible for audit purposes but no longer sync keys to the host.

End access

GrantSSH does not terminate active SSH sessions when access ends. Ending a permission removes the public key on the next agent sync so new connections cannot be opened.

Common ways to end access:

• Set an end date — edit the permission and choose Between two dates with an end date of today or earlier. The grant becomes inactive after that date.
• Let a date range expire — temporary grants end automatically when the end date passes.
• Delete a group — removes the group and all permissions granted to it.
• Remove a server user — deleting a server account in GrantSSH removes its permissions in the app (the Linux user on the host is not deleted).

For immediate offboarding, set the end date to today and confirm the key is removed after one agent sync cycle (typically 30–120 seconds). Revoke team membership separately if the person should no longer belong to the team at all.

How enforcement works

The open-source agent on each server polls GrantSSH for the current list of active permissions and public keys. For each server user, it rebuilds authorized_keys from permissions that are active at poll time.

• Only active servers receive permission data.
• Schedule rules are evaluated in UTC when the agent polls.
• Changes typically apply within one sync cycle — allow 30–120 seconds after granting, editing, or ending access before testing SSH.
• Users connect with normal SSH clients. GrantSSH is not a bastion or proxy.

For a deeper explanation of how schedules and key presence combine, see Access model.

Troubleshooting

• Grant access shows no server users — add server accounts under Server users first.
• Member cannot SSH after grant — confirm the server is active, the member has uploaded a public key, the schedule is currently active (check UTC), and one sync cycle has passed.
• Key still on host after access ended — wait for the next agent sync. If it persists, check the server is still active and the agent is checking in.
• Cannot grant access — only owners and managers can grant permissions. Members should submit an access request.
• Duplicate grant skipped — the member or group already has access to that server user. Edit the existing permission instead.

What to read next

• Working with SSH keys — how public keys are uploaded and synced (coming soon).
• Auditing activity — logins, disconnects, sudo usage, and failed login summaries (coming soon).
• Roles and permissions — detailed capability matrix for owners, managers, and members (coming soon).
• How it works — product-level overview of the access lifecycle.
• Security — keys, data handling, and responsible disclosure.