Roles and permissions

Every person on a GrantSSH team has one of three roles: member, manager, or owner. Roles define what someone can configure in the dashboard — not which servers they can SSH into. SSH access is always governed separately by permissions (team access grants).

For how teams and roles fit into the wider product model, see Core concepts.

Overview

Roles are cumulative: managers can do everything members can, and owners can do everything managers can. There is exactly one owner per team at any time. When ownership is transferred, the previous owner becomes a manager.

After login, the default landing page depends on role:

• Owners and managers land on the Dashboard.
• Members land on Servers, focused on hosts they can reach or request access to.

Capability matrix

The table below summarises dashboard capabilities. A dash (—) means the role cannot perform that action.

Member

Members are individual contributors who need SSH access but should not change team-wide configuration. Typical examples include developers, contractors, and on-call engineers.

Members can:

• Add, edit, and remove their own SSH public keys on the SSH keys page.
• Browse the team's server list and see which hosts they already have access to.
• Submit an Access request for a server — selecting server accounts, providing a reason, and optionally proposing a schedule.
• Connect with a normal SSH client when an active permission includes them and their key is synced.
• View the team Activity log (logins, disconnects, sudo, and failed logins).

Members cannot:

• Add or approve servers, define server accounts, or grant access to anyone (including themselves).
• Approve or deny access requests submitted by others.
• Invite people, change roles, or manage billing.

Only one pending access request per server is allowed at a time for a given member. If access is denied, they can submit a new request.

Manager

Managers operate the team's SSH access day to day. They are trusted to approve servers, define which Linux accounts GrantSSH manages, and grant or revoke access — but they cannot transfer ownership or delete the team.

In addition to member capabilities, managers can:

• Add servers, install agents with claim codes, and Approve server once the agent checks in.
• Create and edit server accounts (Linux users) for each managed host.
• Use Grant access to create permissions directly — permanent, date-bounded, or time-windowed — for individual members or groups.
• Revoke active grants and manage Groups on a server's team-access settings.
• Review, approve, or deny Access requests, including adjusting the requested server accounts or schedule before approval.
• Open full server management views, including per-server Auth logs.
• Invite new members (as member or manager), change existing members between member and manager roles, and cancel pending invitations.
• Generate or rotate the team's enrolment token for scripted agent installs.
• View and manage team Billing when the plan requires it.

Owner

The owner is the person who created the team (or received ownership via transfer). There is one owner per team. Owners have every manager capability plus exclusive control over team lifecycle.

Only owners can:

• Transfer ownership to another team member. The previous owner becomes a manager automatically.
• Delete the team and its associated data.

Owners and managers share member management: both can invite people and promote or demote between member and manager. Neither can assign the owner role directly — that happens only through ownership transfer.

Choosing the right role

Use these guidelines when inviting people:

• Member — anyone who only needs SSH into specific server accounts. Most of your team should be members.
• Manager — team leads, DevOps engineers, or account managers who approve access requests, add servers, and define server accounts. Limit managers to people who routinely make access decisions.
• Owner — the person accountable for billing, membership, and team continuity. Keep a single clear owner; use transfer rather than sharing owner-level access.

What roles do not control

Team roles govern the GrantSSH dashboard only. They do not change what someone can do after they SSH into a server — that remains defined by the Linux account, sudo configuration, and your own tooling on the host.

Regardless of role:

• SSH access requires an active permission for the target server account; roles alone never grant shell access.
• GrantSSH stores public keys only and does not proxy or record SSH sessions.
• Permissions enforce connection access (who can authenticate and when), not command-level restrictions.

What to read next

• Core concepts — teams, servers, permissions, and groups in context.
• Managing permissions — grant, schedule, and revoke access (coming soon).
• Quick start — first server setup from an owner or manager perspective.
• How it works — product-level overview of the access lifecycle.