Please help test recent changes

[Ángel]

On 2022-01-07 at 09:52 +1100, Damien Miller wrote:
> Hi,
> 
> We've landed some fairly significant changes in OpenSSH recently and
> would appreciate your help in testing them. The biggest of the
> changes
> are:
> (...)
> 
> All of these changes are in git and will be in tomorrow's snapshot
> (20220108).
> 
> Thanks!
> 
> Damien Miller

Hello Damien

That's very interesting.

I have thought about this some time ago (maybe it was mentioned on this
list?), but I had only considered each ssh(1) prepending its parameters
to the agent. This approach is more robust, although I would include in
SSH_AGENTC_EXTENSION a string for identifying how the connection was
made (typically the ssh call, which could be untrue, of course). This
could be useful for debugging, or when there are earlier hops through
unknown hosts.


I think the document should reference somewhere the more secure option
of chaining ssh connections using ProxyJump, that this restriction
doesn't apply there and ssh-agent considers such connections as local.


As a further step, I would add the ability to specify wildcard
destinations, e.g. 
  ssh-add -h "*.prod.example.com" ~/.ssh/production.key

for a key which could be used on any subdomain of prod.example.com, but
not anywhere else.

The restrictions are expressed in a right-associative way, which IMHO
seem unintuitive. Something like "charybdis.example.org from
scylla.example.org" or "charybdis.example.org<scylla.example.org" would
perhaps emphasize better the beginning of the restriction is not fixed.
What do other people think about it?

It's not mentioned in the document, but I expect that when ssh-add parses
restrictions that they support ports as well 
   ssh-add -h "scylla.example.org>medea at charybdis.example.org:2222"



I think "the keys for all the hosts that the user lists must be present
in the right place (the machine running ssh-add) and the right time."
intends to be "*at* the right time.", but it's probably better to state
explicitly "at the time ssh-add is run".

I see ssh-add gets added -H to choose a known_hosts file, good. But the
text in ssh-add.1 "ssh-add will use the default ssh_config(5) known
hosts files:", while strictly correct, may make it seem that it will
somehow parse ~/.ssh/config or /etc/ssh/ssh_config for
UserKnownHostsFile directives. I suggest
"ssh-add will use the known hosts files:
~/.ssh/known_hosts, ~/.ssh/known_hosts2, /etc/ssh/ssh_known_hosts, and 
/etc/ssh/ssh_known_hosts2, which is the default used by ssh_config(5)" 



A potential issue I see is, given the example:

   $ ssh-add -h "perseus at cetus.example.org" \
             -h "scylla.example.org" \
             -h "scylla.example.org>medea at charybdis.example.org" \
             ~/.ssh/id_ed25519

Poseidon is root on cetus, and wants some files that medea saves in
charybdis.
When victim logs in as perseus at cetus.example.org (forwarding ssh-
agent), Poseidon impersonates perseus and logs in to 
poseidon at scylla.example.org *without using this key* (e.g. with
keyboard-authentication). He is then able to connect to 
medea at charybdis.example.org using the forwarded ssh-agent.

(he could have used an evil ssh(1) to lie and run it directly from
cetus with a fake binding, but since he needs a valid login to scylla,
it's easier this way)

This is likely unexpected, but I don't see an easy way to avoid it. One
could force the whole path to be connected with the same key (maybe the
code already does this?), but that would forbid using multiple keys
along the path (e.g. one key for the bastion host, then jump from it to
the dev environment that uses its own dev key)

First of all, I think we need to be able to state the source user:
          -h "perseus at scylla.example.org>medea at charybdis.example.org"
which requires a new field 'string from_username' on
SSH_AGENT_CONSTRAIN_EXTENSION.

And perhaps ssh-add should default that field to the current user if
unset, although I would consider alternate User values in ~/.ssh/config
to be relatively common.


Finally, two minor nitpicks: a stray backslash in '\public'
and s/pursues/pursued/


Sorry for the long list of comments!


Best regards

Ángel