The problem with servers

Until now, getting into a machine with Golem had one requirement: someone on the other side had to start the agent and send me the connection line. On a user’s computer that works well, because the person is there and wants my help.

Servers are different. Nobody sits in front of a server. When a software company started using Golem with its technicians, the first thing they told me was that, to get into a customer’s server, they first opened an AnyDesk, Splashtop or RustDesk session only to start Golem and copy the line. Two remote access tools for a single job, and the second one depended on the first.

They asked me for something like the unattended access of those tools, and that is what Golem 1.4 brings.

Why a token in a file was not enough

The quick solution would have been to leave the agent running as a service, with a fixed token stored on disk, so the technician could connect whenever they wanted. I ruled it out straight away. A fixed token in a file is a password that never expires, that works for anyone who copies it and that nobody remembers to change when a technician leaves the company. On a customer’s server, with their business data inside, I did not want to leave that behind.

So the design starts from three ideas:

  • The server is not left open. It waits, and only opens when someone from the right company knocks.
  • Each technician gets in with their own credential, which carries their name and expires after 30 days.
  • Each session starts with a new token and closes by itself when idle.

How it works

It is installed once on each server, with someone from the customer present or through the usual remote session:

golem guardian install --credential C:\Golem\technician.cred

That leaves a Windows service, Golem Guardian, which starts with the machine, and a lock next to the executable. The lock says which company’s credentials can open that server. The installation prints two values that go into the inventory: an eight digit slot and the Guardian’s identity, a fingerprint that identifies that server.

As soon as the service is registered, the .cred file is deleted from the server. It is only needed to install the Guardian: it is not used again after that, and the lock keeps no copy. Leaving it there would mean leaving a technician’s credential on a machine that is not theirs, even though without their key, which only lives on their own computer, it opens nothing.

From then on, a technician gets in from their Claude with the eight digits:

golem_connect 3050 7712

Their client leaves a knock at my portal, signed with their computer’s key. The Guardian asks the portal every minute whether anybody has knocked. When it finds the knock, it checks the credential, that it belongs to the company in the lock, that the key is the technician’s, the time, that it is not a repeat, and the signature. If everything matches, it opens a session with a new token and returns it to the technician encrypted, so that only their computer can read it. On a server behind a router it also opens a Cloudflare tunnel, only for as long as that session lasts. The server does not listen to anything from outside.

The portal acts as a mailbox and cannot read what goes through it. It keeps the slot, a check value for that slot’s secret, and the encrypted knocks and answers. It does not know the server’s name or its IP. What the Guardian publishes is signed with its identity, and the technician’s client remembers that identity the first time it gets in, the way SSH does with the servers it knows: if one day someone answers with a different one, it does not connect.

What the server’s owner sees

The software company’s customer also needs to be able to know what happens on their machine. The Guardian writes it down in two places:

  • In the Windows Event Viewer: the installation, every session that opens and closes with the technician’s name, and every refused knock.
  • In golem-audit.log, next to the executable: every action of every session, with no tokens or credentials.

They can also close the door whenever they want. golem guardian remove, in an administrator console, removes the service, the lock and the certificate, and the server goes back to being one without a Guardian.

What the company does

Technicians are managed from the portal, under Technicians (/portal/team), with the account that holds the license. Each technician generates a key on their computer, which never leaves it, and the company adds them with their name, their e-mail and the public part of that key. The portal returns the credential, which the technician installs on their computer. It renews by itself when it has less than seven days left.

When you remove a technician, bear in mind that the server checks the credential on its own, without asking the portal, so removing them stops it from renewing but does not cancel it on the spot: the one they already have keeps opening until it expires, at most 30 days later. To cut access immediately, run golem guardian remove and install again on each server, which gives a new slot and a new identity.

Tested on real servers

Before publishing it I tested it on a real server, against my production portal and with the signed executables. The test I cared about most was restarting the server without anybody logging in afterwards. The Guardian was up and waiting twelve seconds after Windows started, and we got in with the eight digits, with the same slot and the same identity as before.

Those tests produced fixes that ship in 1.4.2. Under the Guardian there is no desktop, so the screenshot tools answer that there is no screen, and none of them suggests anything that could throw out whoever is connected through AnyDesk, Splashtop, RustDesk or RDP. install warns you if a golem serve window holds its port, and if the service does not start, Windows retries it by itself and status says why.

Who it is for

The Guardian is for companies that support their customers’ servers, and it comes with the Golem Company license: unlimited technicians within the company, not bound to any machine and with no charge per server. With the single technician and team licenses, Golem works as it always has, with the connection line or with the twelve digits of the Assistance.

The full documentation, with the installation, the two modes (behind a router or with a reachable IP) and what to do about each message, is in the Guardian guide. Prices are on the pricing page.