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@xxxxxxxxxxxxxxxxxxxxx: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@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. > > 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@xxxxxxxxxxxxxxxxxx> > > medea@xxxxxxxxxxxxxxxxxxxxx" > > 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@host, although if needed the user could be obtained with getpwuid(getuid()) > Thanks for the fixes and feedback! > > -d You're welcome! _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev