Set up Access

Access lets your engineers SSH into your servers with their Fob account, so you don't have to manage keys in authorized_keys. You give groups Unix logins on servers, and Fob gives people short-lived SSH certificates when they connect.

Permission

Needs Change security settings.

Turn on Access

1. Open Access > Settings and choose Turn on Access. Fob creates your organization's SSH certificate authorities and a Fob CLI app for signing in from the command line.
2. On Access > Server groups, choose New server group and name it, such as Production web.
3. On the server group's page, choose Give access and give a group a login, such as deploy for Platform. See Give access.
4. Add a server to the server group.
5. Send your engineers to Connect to servers.

Server groups

A server group is a set of servers you give access to all at once, such as Production web. A server can be in several server groups. You choose a server's groups when you add it, and can change them on the server's page.

Deleting a server group removes the access given on it. Its servers stay.

Give access

Choose Give access on a server group's page. To give access to one server only, choose it on that server's page instead.

Field	What to enter
Groups	Who gets the logins. You can choose Everyone.
Logins	Unix user names, such as deploy or ubuntu. The accounts must already exist on the servers.
Only by request	Users ask for the logins when they need them, and someone approves. See Access requests.
Maximum duration	For access by request, the longest anyone can ask for: 1 to 72 hours. The default is 8 hours.

A login only works on the servers it was given on. If Staging gives Platform deploy and Production gives Payments deploy, Platform can log in as deploy on Staging servers but not on Production servers.

Renaming a group keeps its access. Deleting a group removes it.

Add a server

1. On Access > Servers, choose Add server and pick its server groups.
2. Choose how people connect:
   • Through Fob (recommended). Installs fob-agent, which connects out to Fob.
   • Direct. People connect straight to sshd with their certificate.
3. Run the command the console shows on the server, as root. The token in it works once, within 30 minutes. The console shows when the server has joined.

	Through Fob	Direct
Inbound SSH port	Not needed	Needed
Access changes	Apply at once	Apply within an hour
Session recordings	Kept by Fob, can't be altered on the server	Uploaded by the server
Port, agent and X11 forwarding	Not available	Off unless you allow it

For requirements, options and what the command changes on the server, see Server install details.

Only through Fob

To send every session through Fob, turn on Only through Fob under Connecting on Access > Settings. Fob then stops issuing certificates for direct connections.

Warning

Servers without a connected fob-agent can't be reached while Only through Fob is on. The console lists them before you turn it on.

Forwarding

Certificates for direct connections allow a terminal and nothing else. To also allow port, agent and X11 forwarding, turn on Allow forwarding with direct certificates under Connecting. It's off by default because forwarded traffic isn't recorded, and a forwarded port reaches anything the server can.

When someone loses access

A user loses a login when they leave the group, are disabled or deleted, or when the request behind it runs out or is cancelled. Then:

• Their sessions through Fob end within 30 seconds.
• New certificates no longer carry the login.
• Each server refuses certificates they already hold from its next hourly refresh. To apply it straight away, run sudo /usr/local/sbin/fob-access-refresh on the server.

Access requests

For access marked Only by request, users ask for it when they need it with fob request, giving a reason and how many hours they need.

1. Owners and admins get an email about the request.
2. On Access > Requests, choose Approve or Deny, with an optional comment.
3. The user gets an email with the decision. Approved access lasts for the hours they asked for.

Nobody can decide their own request. To end approved access early, choose End access. To withdraw one that's still waiting, choose Cancel request. Requests nobody decides expire after 7 days.

Requests, decisions and comments are recorded in the audit log.

Session recordings

Access > Sessions lists SSH sessions with the user, login, server and client IP address, and replays the recorded ones. Viewing it needs See sign-in and audit logs. Sessions through Fob that are still open are listed too. Choose End connection to close one.

Session	What's recorded
A terminal, as in ssh deploy@web-01.prod	Everything shown, up to 8 MiB
A shell without a terminal, as in ssh -T	Everything printed, up to 8 MiB
A command, as in ssh web-01.prod uptime	The command. Through Fob, also the first 64 KiB of output.
scp and sftp	That the session happened, not the files

A recording holds what was shown, not what was typed.

Recordings of direct sessions come from the server, so root on that server could alter or withhold them. They also need script from util-linux 2.35 or later on the server. When you need recordings nobody on the server can change, turn on Only through Fob.

A session marked Unverified was reported by a server, but Fob couldn't confirm that it issued the certificate for that login at that time. Treat it as suspicious. Sessions with no user listed used a plain SSH key, not a Fob certificate.

Fob keeps recordings until you set a shorter time under Keep recordings on Access > Settings: 30, 90 or 180 days, or 1 year. When a recording is deleted, its session stays listed.

Certificates

Set how long certificates last under Certificate lifetime on Access > Settings: 1, 4, 8, 12 or 24 hours. The default is 8 hours. Each certificate's key ID is the user's email, so it shows up in sshd logs. Issued certificates lists the latest 100.

Rotate a certificate authority

Your organization has two certificate authorities (CAs), under Certificate authorities on Access > Settings:

• The user CA signs people's certificates. Servers trust it.
• The host CA signs servers' certificates. People's computers trust it, so fob never asks them to trust an unknown server.

To change one, choose:

• Rotate for routine changes. There's nothing to do on servers or laptops. The new CA takes over 2 hours later, after servers have fetched it, and the old one stays trusted for a day after that.
• Replace now if a CA's key may have leaked. Fob stops trusting the old CA at once.

Replace now

Replacing the user CA locks everyone out of each server, through Fob and directly, until that server's next hourly refresh. Replacing the host CA means people can't verify direct servers until they refresh, though sessions through Fob keep working. To restore a server straight away, run sudo /usr/local/sbin/fob-access-refresh on it.

Turn off Access

Turn off Access on Access > Settings stops Fob issuing certificates and ends sessions through Fob. Certificates already issued for direct connections keep working until they expire. Your server groups, access and CAs are kept in case you turn it back on.