Re: Please help test recent changes

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



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

Haven'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

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux