Building GrantSSH: Why We Made a Simple SSH Access Tool

SSH access is one of those things that quietly becomes a mess.

It usually starts off fine. A developer needs access to a server, so someone adds their public key. A freelancer joins for a short project, so they get added too. A new server appears, a client project changes hands, someone leaves the company, someone else changes laptops, and before long nobody is completely sure who has access to what.

That was the problem we kept running into.

One of us had seen it from the web agency side, where different clients, projects, servers, developers, and contractors all come and go. The other had seen it inside a software company, where the same access problems show up in a slightly different shape. Different environment, same pain.

Managing SSH access across servers is boring, manual, easy to forget, and surprisingly risky.

When someone joins, they need adding. When someone leaves, they need removing. When access changes, keys need updating. In a lot of teams, that still means manually editing authorized_keys files, copying keys between servers, or updating Ansible scripts and redeploying them.

None of that is difficult in theory.

But in practice, it is slow. It gets skipped. It gets out of date. And the bigger your list of servers, users, contractors, and client accounts gets, the harder it becomes to trust that everything is actually correct.

The problem is not SSH

We like SSH.

It is simple, proven, widely understood, and already part of how developers work. We were not interested in replacing it with some huge access platform or forcing everyone through a completely different workflow.

The problem was not SSH itself.

The problem was everything around it.

• Who currently has access to this server?
• Does that old contractor still have a key somewhere?
• Did we remove that developer from all the right machines?
• Who needs temporary access for this project?
• Can we see when someone actually connected?
• Can we avoid digging through server files every time someone joins or leaves?

Those are not unusual questions. They come up all the time in agencies, SaaS companies, development teams, freelancers working with clients, and small teams that do not have a dedicated infrastructure department.

And that was really the gap we wanted GrantSSH to fill.

Existing options felt too heavy

There are ways to solve SSH access properly at a larger scale. Bastion hosts, VPNs, identity-aware proxies, enterprise access tools, complex internal platforms, configuration management, and plenty more.

For some teams, those are exactly the right answer.

But for a lot of smaller development teams, they feel like too much.

A bastion setup can be powerful, but it can also be expensive, complex, and disruptive. It changes how people connect. It introduces more infrastructure to maintain. It can feel like you are taking on an enterprise access project when all you really wanted was a better way to manage who can SSH into a handful of servers.

We did not want that.

We wanted something practical.

Something that worked with normal SSH. Something that did not require teams to completely change how they work. Something that did not lock people into proprietary infrastructure or put us in control of their servers.

GrantSSH came from that idea: make SSH access easier to manage, without making the whole thing bigger than it needs to be.

Useful, but not invasive

A big part of the thinking behind GrantSSH is that it should do the smallest useful thing.

It should help you manage access, but it should not take over your infrastructure.

It should make users and keys easier to control, but it should not force you into a strange new way of connecting.

It should give you better visibility, but it should not become yet another complicated platform that needs its own training, maintenance, and internal rollout.

That is why GrantSSH focuses on being simple and practical.

You can manage who has access from a dashboard, instead of hunting through authorized_keys files. You can remove access when someone leaves, instead of hoping every server has been cleaned up properly. You can see access more clearly across your team and servers, instead of relying on memory, old notes, or scripts that nobody wants to touch.

And because real access is not always permanent, GrantSSH also supports scheduled access. That means you can give someone access for the period they actually need it, rather than adding them now and hoping someone remembers to remove them later.

That matters for contractors, client work, short-term support, temporary cover, and all the little "can you just jump on this server?" moments that happen in real development teams.

Visibility matters too

Access control is not only about adding and removing keys.

It is also about knowing what is happening.

GrantSSH logs SSH activity, including when people connect and when they use sudo. That gives teams a clearer picture of server access without needing to piece everything together after the fact.

Again, the goal is not to turn small teams into enterprise security departments.

The goal is to answer basic questions more easily.

• Who logged in?
• When did they log in?
• Did they use elevated privileges?
• Is this access still needed?
• Can we clean things up without making it a whole job?

For a lot of teams, simply having that visibility is a big step up from the usual situation, where access exists somewhere across a bunch of servers and nobody is completely sure what the current state is.

Built for the teams that usually get stuck in the middle

GrantSSH is not trying to be a giant enterprise access suite.

It is for the teams that still need to be responsible, but do not want a heavy-handed solution.

Small agencies. Development companies. SaaS teams. Freelancers with contractors. People managing client servers. Teams with a few Linux boxes, a few people, and enough access changes that the old way has started to feel messy.

These are the teams that often get stuck between two bad options.

On one side, there is the manual approach: edit files, copy keys around, update scripts, and hope nothing gets missed.

On the other side, there are large access platforms that feel expensive, complicated, and designed for a much bigger organisation.

GrantSSH is meant to sit in the middle.

Simple enough to start using without a huge project. Useful enough to replace the messy manual process. Practical enough that it fits the way developers already work.

Why simple is the point

It can be tempting to make tools like this bigger and bigger.

Add more layers. Add more opinions. Add more control. Add more infrastructure. Before long, the tool becomes the thing you have to manage.

We wanted to avoid that.

GrantSSH is built around a fairly straightforward belief: SSH access should be easy to see, easy to change, and easy to clean up.

When someone joins, adding them should not be a pain.

When someone leaves, removing them should not rely on memory.

When someone only needs access temporarily, that access should not quietly become permanent.

And when you need to understand who has been connecting to your servers, that information should not be buried or missing.

That is the kind of boring, practical problem GrantSSH is here to solve.

Not by replacing SSH. Not by locking you into a proprietary way of working. Not by taking control of your servers.

Just by making the access around SSH easier to manage.

Try GrantSSH

GrantSSH was built because we had seen the same SSH access problems in real teams, from different sides, and we wanted a simpler way to deal with them.

If your current process is still a mix of copied keys, old scripts, half-remembered server access, and the occasional "does this person still have access?" moment, GrantSSH is probably worth a look.

It is designed to help you keep normal SSH, reduce the manual work, and make server access easier to trust.

Because managing SSH access should not need to be an enterprise project.

• How GrantSSH works - permissions, agents, and SSH activity
• Features - access control, scheduling, and auditing capabilities
• How to audit SSH access across your fleet - a practical audit checklist