Please help test recent changes

[Damien Miller]

On Fri, 7 Jan 2022, Ángel wrote:

> 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.

Good point; done :)
 
> 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.

This works already, mostly. The wildcard will be expanded by ssh-add
to all available hostkeys that match it before the key is added.

> 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"

Not really - it might be possible to look up a hostkey with an embedded
port number, but there's no validation of it by the protocol thereafter.

> 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.

If the target user forwarded their agent to cetus, then the origin
agent would have received a session-bind@ message informing it of this.
Since there are no onward delegations from that host, any attempts to
use keys from there should fail.

> 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.

I thought about this, but there is no way to enforce it. The source
username isn't part of any data that ssh-agent can strongly trust
(whereas the destination username is), and the only way the agent could
obtain it is inferring it by the path. However, paths aren't super
trustworthy and the inferrence would be shaky if the user logged in
to the same host as multiple users.

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

Thanks for the fixes and feedback!

-d