On 06.01.22 23:52, Damien Miller wrote:
2. Restricted agent keys. This is a large set of changes to add destination- and path-restricted keys to ssh-agent. A full writeup is at on the website at https://www.openssh.com/agent-restrict.html - I'm interested to hear feedback on how this works in practice, UI and things that could be improved (as well as bug reports).
Quick introductory remark 1: The text speaks of "italicised" and "bolded" parts of the syntax definitions, but there seems to be no such markup within the HTML's '<pre class="proto">' blocks that contain those fixed-width-font snippets.
QIR2: Haven't got the time, offhand, to actually run tests; I hope to get at that later. Hence, purely theoretical ranting for now.
---------------I have to admit that I'm somewhat losing orientation among all the variations of multi-hop connections that OpenSSH offers by now. To wit:
------- A. Plain CLI Chaining: hostA$ ssh -A hostB hostB$ ssh [ -A ] hostC [...] also: hostA$ ssh -A hostB 'ssh hostC ...'Out-of-the-box minimal-config-effort way to do it. (Also what we're bound to see when a third party sets up a "proper" non-GUI jump host into their networks and gives us access, as it puts config of the second hop entirely into the jump host and thus *their* hands, but that's unlikely to be relevant to the topic of agent forwarding, of course.)
------- B. Tunneling: hostA$ ssh -D $PORT hostB hostA$ ssh -o "ProxyCommand $THRU_LCL_SOCKS_AT_$PORT" hostC(There are variants, like using LocalForward's or some non-OpenSSH-provided proxy, but I don't see that making for a relevant difference in *this* discusson.)
We use that one *a lot*, because in order to fully support customers' systems, we have to access them with browsers as well as per SSH. Our own new *outgoing*-to-customers jump host is essentially based on such configs.
------- C. ControlMaster D. ProxyJumpHaven't used either much myself, so I'm unclear on relevant details for the time being. I see ProxyJump recommended in your document, and I hear that ControlMaster is quite popular in larger sites where a Nagios/Icinga/... runs checks on target hosts through (multi-hop) SSH logins (because it wraps the thousands/h of "virtual" SSH logins into a few actual TCP connections, and thus avoids triggering rate limits all over the place).
-------Now, back to the topic at hand: Agent forwarding is unnecessary in scenario B, and in scenario A, while the agent runs on hostA, all the automatic maintenance of known_hosts for the hosts you actually *use* the forwarding for happens on hostB. Yet, having them properly listed in the known_hosts *on hostA* is vital for the new usage-restrictions mechanism.
Also, in scenario B, the user will likely know that he's accessing hostC via hostB, and might try to restrict the key to "hostB>hostC", but hostB actually remains transparent to the ssh connecting to hostC and the restriction will fail.
(If someone could pinpoint where known_hosts automaintenance actually happens in cases C and D, I'd be grateful. Since both are implemented *exclusively* in OpenSSH AFAIK, there *would* be the remote possibility of having them automaint known_hosts *both* on the jump host and the machine running the agent ...)
---------------Pondering the concepts behind the term "hostnames": Our company doesn't maintain oodles of internally-visible-only DNS entries. The supporters typically have a well-padded ~/.ssh/config with lots of entries like, e.g.,
Host CustX-SrvY HostName 12.34.56.78 # Customer X's public IP Host CustX-SrvZ HostName 192.168.76.54 # To be gatewayed through SrvY(We're used to having to set up a new *server* to replace the old one for the customers every now and then, so propagating new/changed IPs/entries by word of mouth works quite well. :-3 )
So, we have a loosely-defined "Host" name, an IP for the "HostName", and possibly a couple DNS cherries on top, in case OpenSSH makes any automated lookups. AFAICT it's the "HostName" that becomes the key in the known_hosts file, and thus, we would have to use *that* in the "ssh-add -h ..." parameters, too ...
... ugh. Finding and editing *one* entry in .ssh/config when an IP changes is OK-ish, but sifting through possibly elaborate destination constraints for every instance where the host may have been chosen to serve as a jump host ...
I might be missing loads of other people's use cases here, but if an abstract concept of forwarding constraints were to be introduced in our company, the most viable approach would IMHO be that of administrative zones. As in, "this is a cert issued to me by customer X's CA, and I want it forwarded *only* *via* the known gateways into X's internal network, so let me markup those in my .ssh/config with 'AuthZone CustX' and load the cert with 'ssh-add -A CustX $CERTFILE'" ...
(... which *might* be doable with several agents on different ports *as long as* I do not also have to use my "normal" keypairs to get around within X's network ...)
Kind regards, -- Jochen Bern Systemingenieur Binect GmbH
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
