Description of problem:

FIPS compliance mandates that chacha20-poly1305@opnessh.com cipher not be used. Satellite 6.15 uses this cipher as the default connection when provisioning a RHEL 9.5 image that is not FIPS compliant due to the presence of the RbNaCl gem on the Satellite.

How reproducible:

Every time

Is this issue a regression from an earlier version:

Unknown

Steps to Reproduce:

Change the IP address to a valid IP address for your testing environment and run the command from a 6.15 Satellite with rubygem-net-ssh-7.2.0-1.el8sat.noarch installed:

foreman-rake console << EORAKE
def ssh
  Fog::SSH.new("10.13.255.300", "root", {:password => "redhat", :verbose => :debug})
end
ssh.run('hostname')
EORAKE

Actual behavior:
The satellite will default to using the cipher chacha20-poly1305@opnessh.com likely because of the change introduced in net.ssh-7.2-beta:
https://github.com/net-ssh/net-ssh/blob/d9549e4226dc3aed12efcca24a8b6d349143f398/CHANGES.txt#L24C56-L24C62 

Expected behavior:
This cipher should not be used if system's crypto policy is set to FIPS.

Business Impact / Additional info:

Satellite 6.16 no long has the gem RbNaCl installed so it chooses a different cipher.

https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/security_hardening/switching-rhel-to-fips-mode_security-hardening#federal-information-processing-standards-140-and-fips-mode_switching-rhel-to-fips-mode

"FIPS in crypto-policies
The FIPS system-wide cryptographic policy helps to configure higher-level restrictions. Therefore, communication protocols supporting cryptographic agility do not announce ciphers that the system refuses when selected. For example, the ChaCha20 algorithm is not FIPS-approved, and the FIPS cryptographic policy ensures that TLS servers and clients do not announce the TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 TLS cipher suite, because any attempt to use such a cipher fails."