Fixes #38425 - Make prune_known_hosts work on ip addresses

[adamlazik1]

Currently, prune_known_hosts does not work on ed25519 type SSH keys.
This causes issues for example when rebuilding a provisioned host with
the same ip address that uses ed25519 type keys. The rex jobs run on the
host fail becase of a conflicting ssh key in the known_hosts smart proxy
file. Normally, prune_known_hosts method is expected to take of such
keys.

prune_known_hosts uses the KnownHosts.search_for method from the net-ssh
gem to find the associated keys. While ssh-ed25519 is among the
supported types, for the method to process these keys additional gems
need to be present. You can confirm this by examining the links below
which point to the relevant parts of code in net-ssh. With the inclusion
of new gems the issue is no longer present.

1: https://github.com/net-ssh/net-ssh/blob/d9549e4226dc3aed12efcca24a8b6d349143f398/lib/net/ssh/known_hosts.rb#L106
2: https://github.com/net-ssh/net-ssh/blob/d9549e4226dc3aed12efcca24a8b6d349143f398/lib/net/ssh/authentication/ed25519_loader.rb

[adamlazik1]

As to how to actually properly include the packages, I am not sure whether I did it correctly since this is my first time doing something like this. Even though I included the packages in the Gemfile, I still had to run gem install --user-install ed25519 && gem install --user-install bcrypt_pbkdf, running bundle install from the smart-proxy dir did not install them. Please feel free to correct me and show me the correct way to install packages in case this approach is wrong.

[adamruzicka]

It seems that when the setting connect_by_ip is set to yes, the key associated with the ip that is stored in the known_hosts smart proxy file while running the first rex job on the host is of type ssh-ed25519. This differs from the type of key that is stored while running the first rex job on the host when connect_by_ip is set to no: ecdsa-sha2-nistp256

It seems odd that connect_by_ip would have any effect on this. I seem to be getting ssh-ed25519 when running against an el9.6 host no matter what I set it to. But yes, the host having ed25519 host keys (and both sides on agreeing to use them) could be the real cause.

[adamruzicka]

As to how to actually properly include the packages, I am not sure whether I did it correctly since this is my first time doing something like this.

Adding them to both the Gemfile and gemspec shouldn't be necessary, having them in gemspec should be enough.

Even though I included the packages in the Gemfile, I still had to run gem install --user-install ed25519 && gem install --user-install bcrypt_pbkdf, running bundle install from the smart-proxy dir did not install them.

In general you should never have to install things with gem install --user-install and then expect them to be usable in a bundler-controlled environment (assuming that's what your dev setup looks like).

[adamlazik1]

@adamruzicka Thanks for the review, I will keep the gems only in gemspec, then. I also reworded the commit message.

[adamruzicka]

Looks good on my end

[adamruzicka]

Thank you @adamlazik1 !

[ekohl]

Since it already shells out to call ssh, perhaps calling ssh-keygen -R is easier? That should also work with hashed hosts, if those exist.

[adamruzicka]

The actual cleanup is done by ssh-keygen -R (here), but there is a net-ssh-based check to see if there's anything to do to avoid needlessly spawning an external process (and a monitoring thread due to how open3 works).

[ekohl]

Ah ok. I didn't expect the check because it would trim down on the dependencies. That looks like the only reason net-ssh is pulled in now.