Offer only the guard's key, or the restriction is decorative #6

2026-08-28T18:00:05-07:00

dejima-agent commented

2026-08-28 18:00:05 -07:00

Summary generated by LLM agent

Reported from the first real run against a devbox: install-key installed the key and then reported all four checks wrong — the two the guard needs FAILED, and the two that must be refused were NOT REFUSED.

`ssh -i` does not mean "only this key"

It adds a key to the ones offered. With the operator's own key to that devbox present — or an agent holding one — ssh authenticated with that instead, and no forced command applied.

Every symptom follows exactly:

Check	What actually happened
`reach`	Ran as the operator, without sudo. The audit needs root, so it failed
`drift --state`	Same
`cat /etc/shadow`	Ran, and said permission denied — which contains no "refused"
`drift --accept`	Ran, failed for its own reasons, said no "refused"

The same line was in the guard itself, and there it is worse

install-key at least made a noise. dejima-guard would have collected happily on the operator's unrestricted key, delivered its alerts, and left the forced command protecting nothing — with nothing anywhere saying so, because everything works.

That is the failure mode this project keeps finding: not a thing that breaks, a thing that succeeds while the property it was there for is quietly absent.

The fix

Both pass -o IdentitiesOnly=yes whenever a key is named — and deliberately not when one is not, since with no -i there is nothing to restrict to and forcing it would refuse identities the operator arranged another way.

The NOT REFUSED message now names the two causes worth checking first, including a second unrestricted entry for the same key sitting above the good one: first match wins.

Tested

bats test/ — 44 passing, 3 new: that only the configured key is offered, that no key configured does not force the option, and that the installer's verification carries it too.

None of the existing tests could have caught this. ssh is stubbed throughout, and a stub does not care which key it was not given. It took a real devbox with a real second key on it, which is exactly the class of thing I flagged as unverifiable from here.

**Summary generated by LLM agent** Reported from the first real run against a devbox: `install-key` installed the key and then reported **all four checks wrong** — the two the guard needs `FAILED`, and the two that must be refused were `NOT REFUSED`. ## `ssh -i` does not mean "only this key" It *adds* a key to the ones offered. With the operator's own key to that devbox present — or an agent holding one — ssh authenticated with that instead, and no forced command applied. Every symptom follows exactly: | Check | What actually happened | | --- | --- | | `reach` | Ran as the operator, without sudo. The audit needs root, so it failed | | `drift --state` | Same | | `cat /etc/shadow` | Ran, and said permission denied — which contains no "refused" | | `drift --accept` | Ran, failed for its own reasons, said no "refused" | ## The same line was in the guard itself, and there it is worse `install-key` at least made a noise. `dejima-guard` would have collected happily on the operator's unrestricted key, delivered its alerts, and left the forced command **protecting nothing** — with nothing anywhere saying so, because everything works. That is the failure mode this project keeps finding: not a thing that breaks, a thing that succeeds while the property it was there for is quietly absent. ## The fix Both pass `-o IdentitiesOnly=yes` whenever a key is named — and deliberately not when one is not, since with no `-i` there is nothing to restrict to and forcing it would refuse identities the operator arranged another way. The `NOT REFUSED` message now names the two causes worth checking first, including a second unrestricted entry for the same key sitting above the good one: first match wins. ## Tested `bats test/` — 44 passing, 3 new: that only the configured key is offered, that no key configured does not force the option, and that the installer's verification carries it too. **None of the existing tests could have caught this.** `ssh` is stubbed throughout, and a stub does not care which key it was not given. It took a real devbox with a real second key on it, which is exactly the class of thing I flagged as unverifiable from here.

dejima-agent added 1 commit 2026-08-28 18:00:05 -07:00

Offer only the guard's key, or the restriction is decorative e7daa5c53b

Reported from the first real run: install-key put the key on the devbox and
then reported all four checks wrong - the two the guard needs FAILED, and the
two that must be refused were NOT REFUSED.

`ssh -i` ADDS a key to those offered. It does not restrict to it. So with the
operator's own key to that devbox present, or an agent holding one, ssh
authenticated with that instead and no forced command applied. All four
results follow exactly: reach and drift ran as the operator without sudo and
failed, and cat /etc/shadow ran and said permission denied, which contains no
"refused".

The same line was in the guard itself, and there it is the worse one. The
installer at least made a noise. The guard would have collected happily on
the operator's unrestricted key, delivered its alerts, and left the forced
command protecting nothing - with nothing anywhere saying so, because
everything works.

Both now pass -o IdentitiesOnly=yes whenever a key is named, and not when one
is not, since with no -i there is nothing to restrict to and forcing it would
refuse identities the operator arranged another way.

The NOT REFUSED message now names the two causes worth checking first,
including a second unrestricted entry for the same key above the good one -
first match wins.

`bats test/` 44 passing, 3 new. None of the existing tests could have caught
this: ssh is stubbed, and a stub does not care which key it was not given.

branderson approved these changes 2026-08-28 18:01:05 -07:00

branderson merged commit 8badca1df1 into main

2026-08-28 18:01:10 -07:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dejima/dejima-guard#6

Offer only the guard's key, or the restriction is decorative #6

ssh -i does not mean "only this key"

The same line was in the guard itself, and there it is worse

The fix

Tested

`ssh -i` does not mean "only this key"