Please help test recent changes

[Jochen Bern]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20220107/2fe34409/attachment-0001.p7s>