Please help test recent changes

[Ángel]

On 2022-01-07 at 14:07 +1100, Damien Miller wrote:
> On Fri, 7 Jan 2022, Ángel wrote:
> > 
> > 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 :)

Thanks


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

That's how I envisioned it would work, as it is converted to hostkeys
on add.



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

Yes, it would be just a known_hosts lookup. If a host shares their key
on multiple ports, it is effectively the same key for ssh-agent.


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

So, what would the agent (which may have additional keys as well, such
as an unsrestricted id_rsa) do when, after the session-bind "now in
cetus" it receives a session-bind "now in scylla" ?



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

The source username for hop N would be the destination username for 
hop N-1. On origin we wouldn't really state a source user at host,
although if needed the user could be obtained with getpwuid(getuid())



> Thanks for the fixes and feedback!
> 
> -d

You're welcome!