OpenSSH 8.5 released

Posted Mar 4, 2021 11:33 UTC (Thu) by nye (subscriber, #51576)
In reply to: OpenSSH 8.5 released by josh
Parent article: OpenSSH 8.5 released

As in you're re-using the same host key on hundreds of machines, or you're connecting to the same machine via hundreds of aliases? Both of these seem like pretty niche use cases that I'd only expect to see in some kind of automated environment (probably involving throwaway test systems in the first case, given the risk involved in reusing a key).

OpenSSH 8.5 released

Posted Mar 4, 2021 11:37 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

No, reusing the same IP for different throwaway hosts.

OpenSSH 8.5 released

Posted Mar 4, 2021 12:21 UTC (Thu) by nye (subscriber, #51576) [Link] (1 responses)

Well unless those hosts are reusing the same host key then there won't be any "other host names/addresses already associated with the key", so you can't end up with a list containing hundreds of entries.

(And if they *are* reusing the same key, then you still won't end up with such a list unless you connect via a new throwaway DNS name for each one instead of using a fixed hostname or the unchanging IP address.)

OpenSSH 8.5 released

Posted Mar 4, 2021 22:06 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Uh, the hosts will have different keys but the same IP. So you get the dreaded "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED" message from SSH each time you try to connect.

OpenSSH 8.5 released

Posted Mar 4, 2021 16:16 UTC (Thu) by josh (subscriber, #17465) [Link] (5 responses)

Same virtual machine, same host key, no hostname, different IPs.

OpenSSH 8.5 released

Posted Mar 4, 2021 17:43 UTC (Thu) by nye (subscriber, #51576) [Link] (4 responses)

Now I'm *really* curious. What's the application here? No worries if it's something you can't/don't want to go into.

OpenSSH 8.5 released

Posted Mar 4, 2021 22:06 UTC (Thu) by josh (subscriber, #17465) [Link] (3 responses)

Virtual machine instances that are regularly shut down and brought back up, and don't have or need a static IP. Start instance, get IP for instance, SSH to instance, work with instance, shut down instance.

OpenSSH 8.5 released

Posted Mar 7, 2021 12:21 UTC (Sun) by vadim (subscriber, #35271) [Link] (2 responses)

You can configure a DHCP server to hand out leases for a long time, like a month or even a year.

Then you'll have a lot less of this happening, as each VM will end up using the same address virtually all the time.

OpenSSH 8.5 released

Posted Mar 7, 2021 15:12 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

> Then you'll have a lot less of this happening, as each VM will end up using the same address virtually all the time.
Then you'll run out of addresses, since VMs are disposable and each new VM gets a new MAC.

OpenSSH 8.5 released

Posted Mar 8, 2021 0:22 UTC (Mon) by josh (subscriber, #17465) [Link]

Cloud providers don't typically do this in their DHCP servers. (And I think it makes sense that they don't, for a variety of reasons, not least of which that it's better to show people very quickly that IPs will change, rather than let them experience breakage later on.)

My use case: one hundred systems with the same ssh host key

Posted Mar 8, 2021 17:13 UTC (Mon) by emmi3 (subscriber, #62443) [Link]

I have the following setup: nearly one hundred thin clients for home office use ("Telearbeit" / tele work) running from the same live linux image.

The (cutomized) images are built using live-build form debian-live. Normally live-build would delete the ssh host key during build time and live-config would create a new ssh host key on every startup. This was undesirable since ssh would complain about the changed host key after every reboot of the thin client. Therefore I baked one predefined host key directly into the image.

The thin clients are connected to our university environment via wireguard using a 10-something private subnet. Thus we have nearly one hundred different physical hosts (with different but fixed IPs and hostnames) using the same ssh host key.

I don't see anything wrong with this setup and I think this is a valid use case. If my ssh client starts complaining about all those hosts having the same host key, I will have to start creating separate keys for every client and distributing them like I do with the wireguard preshared keys and other client specific data right now. No big deal, but I don't really see any benefit from this.