SSH key management

Where it is

Open a server page, then System → Users. Under the list of users is the live authorized_keys listing the agent reports (key type and comment only, never the key body) and a Grant SSH access panel.

Grant access

1. 1.Click Grant SSH access.
2. 2.Enter the Linux user the person will log in as, for example ubuntu, deploy or ec2-user. The user must already exist on the server.
3. 3.Give the key a label such as "Priya’s laptop" so you know whose it is when you revoke it later.
4. 4.Paste the public key, the single line that starts with ssh-ed25519 or ssh-rsa. On their machine it is usually cat ~/.ssh/id_ed25519.pub or id_rsa.pub.
5. 5.Click Add key to server.

Opservo checks the key is a valid single public key (a private key, a PEM block or several keys pasted together are refused), then runs a signed command on the server that appends the line to that user’s ~/.ssh/authorized_keys and fixes the file’s ownership and permissions. The row shows Adding… and then Access granted or Failed with the reason. Adding a key that is already present is harmless; it is reported as already there.

Revoke access

Click Revoke access on the row. Opservo removes every line with that key from the user’s authorized_keys, writing through a temporary file so a crash mid-write cannot truncate the file. The row becomes Revoked; revoked rows are hidden by default and can be shown again. The same person can be granted access again later by pasting the same key.

Who can do this

Granting and revoking need the owner or admin role and, if your workspace requires it, a 2FA code before server actions. The server must have remote actions switched on; otherwise the request is refused with a message pointing you to the Automation tab. The workspace must be on the Growth plan or higher.

The command runs with sudo -n like every other quick action. If the agent’s user cannot use sudo without a password on that server, the row fails with a plain-English explanation of what to allow.

What is recorded

Each grant and revoke writes an audit entry (ssh_key_added, ssh_key_revoked) with the Linux user, the label and the key’s SHA256 fingerprint, never the key itself. Hover the fingerprint on a row to compare it with ssh-keygen -lf on the person’s machine. The key text travels to the server base64-encoded inside the command, so a comment containing quotes or shell characters is inert, and the server’s command history shows only the command, not the key.

What it does not do

• •It does not create or delete Linux users; the user must exist already.
• •It does not change sshd_config, password authentication or root login.
• •It does not manage keys for servers where remote actions are off.