openssh unix dev - Jan 2022 - Please help test recent changes

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

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