HearthGate

Help

HearthGate page

Per-Key Limits

Limit each authorized SSH key by date, schedule, concurrent sessions, lifetime use, and session duration.

Stronger in HearthGate 1.3.0

Per-key control, finally.

Each authorized SSH key can carry its own limits: expiration dates, allowed time windows, concurrent session caps, lifetime use caps, and per-session duration caps. HearthGate 1.3 makes those limits more practical by enforcing expiration and time-window rules while a session is already active, and by letting you set limits earlier during setup. The goal is simple: hand out keys that defend themselves.

Where to find it

Per-Key Limits live directly on each authorized key. Open the key details, click Edit Limits, then choose the controls that match the trust you want to grant.

Related secure-access terms

These are the useful phrases around Per-Key Limits: key expiration, scheduled SSH access, session caps, lifetime-use caps, and active SSH session visibility.

1

Expires after a date

Pick a calendar date. After midnight on that day, the key is rejected automatically. In HearthGate 1.3, expiration can also be enforced against sessions that are already open.

Use case

A contractor needs access for the duration of a 30-day engagement. Set the expiration date when you onboard them. You never have to remember to revoke it later.

2

Active only during certain hours

Choose days of the week and a start/end time, with timezone awareness. Midnight-crossing windows such as Wed 22:00 - Thu 06:00 are handled as one continuous allowed window. HearthGate 1.3 can also close a session when the allowed window ends.

Use case

Your on-call rotation only needs SSH access during business hours. Restrict the on-call key to Mon-Fri 09:00-18:00 in the right timezone and keep an audit trail of denied attempts.

3

Maximum concurrent sessions

Cap how many simultaneous sessions a single key can hold. When the cap is reached, HearthGate can either reject the next attempt cleanly or disconnect the oldest session and accept the new one.

Use case

A teammate keeps stale sessions alive from a laptop, tablet, and old workstation. Cap the key at 2 and have HearthGate remove the oldest session whenever a new one arrives.

4

Maximum lifetime use

Cap how many total session starts this key can ever have. When the count is reached, the key is auto-quarantined until you manually reset the counter in the UI.

Use case

You hand a key to an automation script that should run a backup ten times and then stop. Set the lifetime cap to 10 so the key bricks itself after the tenth run.

5

Session duration cap

Cap how long an individual session may stay open. HearthGate can close sessions that exceed the configured limit, which helps prevent forgotten tunnels from staying open.

Use case

Your interactive shell key should not sit open overnight. Cap each session at 4 hours. If you forget to log out, the session ends on its own.

Active Sessions panel

The Status tab can show every SSH session currently connected to your Mac, grouped by the authorized key holding it open. Each row shows source IP, start time, and runtime. Inline actions let you disconnect a single session or reset a key's lifetime-quarantine state.

Use case

Something feels off. You check the panel and see sessions from an IP you do not recognize. Disconnect those sessions immediately, then move to Authorized Keys and revoke the key if needed.

Common questions

Do Per-Key Limits replace normal OpenSSH restrictions?

No. They sit beside the normal SSH model. HearthGate still uses narrow key thinking, then adds managed Mac-side limits for time, session count, lifetime use, and runtime.

Can I make a key temporary?

Yes. Give the key an expiration date or a lifetime use cap. That makes short-term access easier to hand out and easier to forget safely.

Can I see which key is currently connected?

Yes. The Active Sessions panel groups live SSH sessions by authorized key, source IP, start time, and runtime.

Are expiration dates and time windows checked after login?

Yes. HearthGate 1.3 can keep enforcing expiration and time-window rules after the session has started, so access does not quietly continue just because someone connected before the cutoff.