An access request is how anyone gets onto a server in Shellius. It names one server, a protocol, a duration and a reason. The policy engine decides whether it is granted straight away, sent to an approver, or refused. Nothing in Shellius grants standing access: every approved request has an expiry, and the certificate issued under it never outlives it.

Use this page if you request access, review other people's requests, or need to understand why a production request did or did not need an approver.

Required permissions

Permission	Label in Roles	What it allows
access.request	Request access	Submit access requests. What is granted still depends on access policies.
access.choose_principal	Choose login user	Request any login user the matching policy allows, not just the server default.
access.prod_bypass	Production without approval	Get production access without an approver, when the organisation switch is also on.
access.bypass_policies	Bypass access policies	Non-production access without a matching policy. Deny policies still apply.
access.break_glass	Break-glass access	Self-approve emergency access to servers a break-glass policy names for you.
access_requests.view_all	View all access requests	See every request, not just your own and the ones you review.
access_requests.revoke_any	Revoke any access	Revoke any approved request and its certificate.

Reviewing is not a permission. You can approve or deny a request only if you were resolved as one of its approvers when it was submitted.

The life of a request

Status	Meaning
PENDING	Waiting for one of the resolved approvers. Expires on its own after 24 hours.
APPROVED	Access is live until Expires at. You can connect and, if policy allows, download credentials.
DENIED	An approver refused it. The reason they gave is shown on the request.
EXPIRED	The approved window ended, or a pending request went unanswered. Any linked certificate is revoked.
REVOKED	Someone ended the access early. Any linked certificate is revoked with it.

Request access

1. Open Access requests and choose New request.
2. Pick the Server. Servers that have not been onboarded cannot be requested.
3. Choose the Protocol — SSH or RDP — and the Duration, in minutes or hours. The minimum is one minute and the maximum is seven days; the matching policy's maximum session length caps it further.
4. Enter a Reason of at least 10 characters. It is shown to approvers and kept in the audit log.
5. Submit.

What happens next depends on the policy evaluation:

• A deny policy matches — the request is refused with the policy's name.
• No policy matches — the request is refused.
• An allow policy matches and no approval is needed — the request is created as APPROVED immediately, with the duration clamped to the policy maximum.
• Approval is needed — the request is created as PENDING and the approvers are notified in the portal and by email.

Which login user you get

For SSH, the default login user is your just-in-time account if a matching policy provisions one, otherwise the server's configured SSH user. Without access.choose_principal you can only ask for one of those two. For servers that use a stored identity from the Keystore, the login user is the identity's username and cannot be changed. For RDP it is the server's configured RDP account.

You receive a notification when the request is approved, denied or revoked, and a warning about ten minutes before approved access expires.

Who approves

Approvers are resolved from the matching policy when the request is submitted:

• the users named on the policy,
• everyone holding one of the policy's approver roles,
• the members of the policy's approver group.

If the policy names nobody, Shellius falls back to the requester's manager. The requester is never their own approver. If that leaves no one, the request is rejected with a message asking an administrator to assign a manager or set an approver group or role on the policy — it is never silently auto-approved.

Any one of the resolved approvers can decide. The set is a snapshot taken at submit time, but an approver who has since been suspended or removed can no longer act on it.

Review a request

1. Open Access requests and switch to Pending reviews.
2. Open the request and read the server, environment, login user, duration and reason.
3. Choose Approve or Deny.
   • When approving, you can set Approved duration to something shorter than was asked for. Leave it blank to use the requested duration. It can never exceed the matching policy's maximum session length.
   • When denying, a Reason for denial of at least 5 characters is required.

Approve from email

Each approver's notification email contains a one-click link. The link opens a confirmation page showing the request, with Approve and Reject buttons — opening the link does not decide anything by itself, so mail scanners that prefetch links cannot approve a request. The link is bound to one approver and one request, expires, and stops working once a decision is made. Decisions made this way go through exactly the same review path, audit trail and notifications as decisions made in the portal.

Production servers

A server whose environment is prod needs an approver for every request, unless both of these are true:

• the requester's role holds access.prod_bypass (Production without approval — Admin and Super admin by default), and
• the organisation switch Allow skipping production approval is on, under Administration → Access rules.

With the switch off, nobody skips approval, super admins included. A policy's auto-approve setting never applies to production.

When a request does skip approval it is not invisible:

• the request is still created, with status APPROVED and the reason attached,
• it is audited under its own action, access_request.prod_bypass,
• the server's approvers are notified after the fact.

Revoke access

An approved request can be ended before it expires by anyone who could have approved it, or by anyone with access_requests.revoke_any.

1. Open the request from Access requests.
2. Choose Revoke and optionally enter a reason.

The request moves to REVOKED, the certificate issued under it is revoked, and the requester is notified. The next connection attempt with that certificate is refused by the host — see Certificates.

Browser SSH sessions opened under the request are ended automatically within about 30 seconds; the same happens when a request simply expires. A shell opened with your own ssh client does not pass through Shellius and is not closed for you, and RDP sessions are ended from Sessions.

Break-glass access

Break-glass is emergency access that you approve yourself. It exists for the moment when production is down and no approver is reachable, and it is built to be loud.

It is only available when all of these hold:

• your role has access.break_glass,
• an active allow policy marked as break-glass names you and the server — deny policies still win,
• for a prod server, the organisation switch Allow skipping production approval is on,
• nobody else already holds live break-glass access to that server.

To use it:

1. Open the server and choose Break-glass.
2. Describe the emergency. The reason must be at least 20 characters; it is recorded in the audit log and sent to administrators.
3. Complete step-up verification: a code from your authenticator app, or a one-time code emailed to you if you have no authenticator enrolled. The challenge lasts 5 minutes and allows 5 attempts.
4. On success, a request is created already APPROVED, for at most the break-glass policy's maximum session length.

WARNING

If the verification email cannot be delivered, no challenge is created and nothing is granted. Break-glass depends on a working email setup for anyone without an authenticator app.

Starting and completing break-glass are both audited as high severity (access_request.break_glass.started, access_request.break_glass.granted), and everyone who holds access_requests.revoke_any is notified with the server, the person and the reason.

Downloading SSH credentials

Connecting from the browser needs nothing downloaded. Using your own ssh client does: from an approved request you can download a one-off key pair and certificate, along with the exact command to connect.

This is off by default. It is available only when an active allow policy has Allow SSH key download turned on, and only to the requester. It is never available for servers that use a stored Keystore identity — use the browser terminal for those. Every download is audited as certificate.key_downloaded.

See Certificates for what the download contains.

Next steps

Access policiesDecide who can request what, for how long, and who approves.CertificatesWhat is issued when a request is approved, and how revocation reaches the host.Sessions and recordingSee who is connected, end a live session, and replay recordings.Audit logFind every request, approval, bypass and break-glass event.