Host key verification (known_hosts) with ProxyJump/ProxyCommand

[Stuart Longland VK4MSL]

On 18/8/23 18:37, Jochen Bern wrote:
> On 18.08.23 07:39, Darren Tucker wrote:
>> On Fri, 18 Aug 2023 at 15:25, Stuart Longland VK4MSL <me at vk4msl.com> 
>> wrote:
>> [...]
>>> The crux of this is that we cannot assume the local IPv4 address is
>>> unique, since it's not (and in many cases, not even static).
>>
>> If the IP address is not significant, you can tell ssh to not record
>> them ("CheckHostIP no").
> 
> If I understand correctly, you need to *know* the target system's local 
> 172-ish IP to be able to log in. If so, and your DNS admin frowns at 
> setting up 16 million RRs to cover 172.0.0.0/8 in preparation, sslip.io 
> might be helpful.
> 
> https://sslip.io/

That's a handy little service… not sure of its long-term stability 
though for production use, but one to have a closer look at and keep in 
the memory bank.

It's not so much the DNS admin frowning on its use.  I think the subnets 
involved are /24s and our public DNS infrastructure is Amazon AWS 
managed via Terraform, so it could be scripted if we wanted such detail 
to be publicly visible.  (And we do have a couple of private IPs visible 
on our domain -- mostly so Let's Encrypt can validate the host exists.)

The biggest impediment is the constrained nature of the routers that 
we're using as bastion hosts on site.  We'd have to deploy the DNS 
server either on the router itself, or at a static address within reach 
of it (and configure the router to use that resolver).

 From what I understand of ProxyJump:

	ssh -J proxyuser at proxyhost targetuser at targethost.domain

targethost.domain would need to be resolved by proxyhost, not the local 
client.

Another approach would be to set up /etc/hosts on the bastion, if it 
were a conventional Linux machine I'd have little issue with this.  I'm 
not sure OpenWRT (or at least Teltonica's flavour of it, which is an 
older release) would maintain /etc/hosts changes persistently.

> Otherwise, and assuming a *manageable* (mainly, enumerable) population 
> of remote sites, I wonder whether this approach might work, too?
> 
> Host    Perth-47
>      HostName        172.23.45.47
>      ProxyJump        Perth-GW
>      GlobalKnownHostsFile    /dev/null
>      UserKnownHostsFile    ~/.ssh/known-in-Perth
> Host    Adelaide-11
>      HostName        172.45.67.11
>      ProxyJump        Adelaide-GW
>      GlobalKnownHostsFile    /dev/null
>      UserKnownHostsFile    ~/.ssh/known-in-Adelaide
> 
> (Yes, I realize that with target IPs being *potentially dynamic* per 
> DHCP, having known hostkeys indexed by site *and IP* might still turn 
> out to be bothersome.)

Ahh okay, so you can have a separate `UserKnownHostsFile` per host entry.

The situation we have is our workstations' .ssh/config actually imports 
config files from elsewhere (git repo):

Include /home/me/workplace/ops/config/ssh/prod/*
Include /home/me/workplace/ops/config/ssh/dev/*
Include /home/me/workplace/ops/eng-ssh/*-config

So assuming one of those files was 
/home/me/workplace/ops/eng-ssh/bigcust-config

# Bastion router on the site, VPNing back to the office
Host bigcustomer-00123-bne-md01
     HostName	10.20.34.5
     UserKnownHostsFile bigcustomer-00123-bne-md01-hosts

Host bigcustomer-00123-bne-br01
     HostName    172.30.0.100
     ProxyJump   user at bigcustomer-00123-bne-md01
     UserKnownHostsFile bigcustomer-00123-bne-md01-hosts

Host bigcustomer-00123-bne-md02
     HostName	10.20.34.6
     UserKnownHostsFile bigcustomer-00123-bne-md02-hosts

Host bigcustomer-00123-bne-br02
     HostName    172.30.0.100
     ProxyJump   user at bigcustomer-00123-bne-md02
     UserKnownHostsFile bigcustomer-00123-bne-md02-hosts

Would the UserKnownHostsFile be relative to the current working 
directory of the `ssh` process at the time of its call, or would it 
figure out that these files are relative to 
/home/me/workplace/ops/eng-ssh/bigcust-config?

If the latter, I could then store that in the git repository (as a 
*signed* git commit, so it can be authenticated later) which would offer 
similar benefits to the `ExpectHostKey` I made earlier.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
   ...it's backed up on a tape somewhere.