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@xxxxxxxxxxxxxxxxxxxxx: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@xxxxxxxxxxxxxxxxx" \
-h "scylla.example.org" \
-h "scylla.example.org>medea@xxxxxxxxxxxxxxxxxxxxx" \
~/.ssh/id_ed25519
Poseidon is root on cetus, and wants some files that medea saves in
charybdis.
When victim logs in as perseus@xxxxxxxxxxxxxxxxx (forwarding ssh-
agent), Poseidon impersonates perseus and logs in to
poseidon@xxxxxxxxxxxxxxxxxx *without using this key* (e.g. with
keyboard-authentication). He is then able to connect to
medea@xxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxx>medea@xxxxxxxxxxxxxxxxxxxxx"
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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
