Update net-ssh to support RHEL 9 / AlmaLinux 9 / RockyLinux 9

[sspans-sbp]

🗣️ Foreword

Thank for taking the time to fill this bug report fully. Without it we may not be able to fix the bug, and the issue may be closed without resolution.

👻 Brief Description

The current version of net-ssh that's used by test-kitchen doesn't support SHA2 signatures.
The older SHA1 signatures have been deprecated and are not enabled in EL9 distributions.

The most recent net-ssh release 7.0 is the first version that supports the required signatures.

net-ssh/net-ssh@a45f54f
net-ssh/net-ssh@d9b2f09

OpenSSH deprecation notice: https://www.openssh.com/txt/release-8.7

Version

3.3.1

Environment

[Details about the environment such as the Operating System, cookbook details, etc...]

Scenario

I'm trying to run 'kitchen converge' on an AlmaLinux 9 host.

Steps to Reproduce

Run a kitchen test on an Almalinux 9 instance with the default sshd config.

Expected Result

SSH connections to newer OpenSSH work.

Actual Result

The SSH connection fails:

$ kitchen test --destroy=always $SUITE
-----> Starting Test Kitchen (v3.3.1)
-----> Cleaning up any prior instances of <default-almalinux-9>
-----> Destroying <default-almalinux-9>...
       Finished destroying <default-almalinux-9> (0m0.00s).
-----> Testing <default-almalinux-9>
-----> Creating <default-almalinux-9>...
       Bringing machine 'default' up with 'cosmic' provider...
       ==> default:  -- Start port : 22
       ==> default:  -- End port   : 22
       ==> default:  -- ICMP code  : 
       ==> default:  -- ICMP type  : 
       ==> default: Waiting for SSH to become available...
       ==> default: Machine is booted and ready for use!
       ==> default: Machine not provisioned because `--no-provision` is specified.
       Waiting for SSH service on x.x.X.131:56732, retrying in 3 seconds
       Waiting for SSH service on x.x.X.131:56732, retrying in 3 seconds
       Waiting for SSH service on x.x.X.131:56732, retrying in 3 seconds
       Waiting for SSH service on x.x.X.131:56732, retrying in 3 seconds

➕ Additional context

Backporting the following two commits resolves the issue:

net-ssh/net-ssh@a45f54f
net-ssh/net-ssh@d9b2f09

[sidxz]

Adding Oracle Linux 9 to the list as well.

[carlosmmatos]

When is this expected to be fixed/released?

[Stromweld]

@vkarve-chef This should be a quick and easy one to fix RHEL 9 support. Simply need to update the dependency version of net-ssh.

[Stromweld]

looks like it actually is an issue with net-scp forcing dependency to be less than 7 for net-ssh. #1905

[carlosmmatos]

So the main gemspec has the updated versions, just hasn't been cut in a new release from what I can make of it.. but out of curiousity, if you take a look at Vagrant's gemspec, they are not using net-ssh > 7 and yet I can vagrant ssh into a RHEL9 distro no problem.. I may be overlooking it though. just a thought

[Stromweld]

a workaround for test kitchen is to set the transport to ssh and set the username and password opttions. This bypasses the ssh key and the issue with old algorithm being dropped till the new net-ssh which supports the latest algorithms can be integrated into the build.

[Firenice03]

RHEL9 systems (Cent/Rocky/Alma etc) with fully updated ChefWS VirtualBox Vagrant

• "Waiting for SSH service on 127.0.0.1:22##, retrying in 3 seconds"

Versions: running on Windows 10
Vagrant 2.3.4 and Virtualbox 7.0
Chef Workstation version: 22.12.1024
Chef Infra Client version: 17.10.0
Chef InSpec version: 4.56.20
Chef CLI version: 5.6.8
Chef Habitat version: 1.6.521
Test Kitchen version: 3.5.0
Cookstyle version: 7.32.1

Adding transport under platforms - in the below format (cause I had to go find a correct format) ;)

 - name: rockylinux-9
    transport:
        username: uname
        password: pword 

This does allow for a kitchen create/converge to complete without the SSH service error.
If wanting to log into the system via kitchen login, it will prompt for the password....

OR if this is forgotten and you're watching SSH retry every 3 seconds and just want it to work....
Via the Hypervisor (VBox in my case) log into the VM and issue with elevated access (sudo)
" update-crypto-policies --set DEFAULT:SHA1 "
it will suggest a reboot - but its not needed, SSH will instantly connect.

Thought I'd help those that may be pulling their hair out...
As its in Test Kitchen and nothing production I don't think there is much harm is using the deprecated policy..