When attempting to establish an SFTP/SSH connection between RHEL 9 (with OpenSSL 3.0.1) and CentOS 6 (running OpenSSL 1.0.1e-fips), we encounter fundamental cryptographic incompatibilities. The error messages reveal two distinct problems:

# From RHEL 9 to CentOS 6:
ssh_dispatch_run_fatal: Connection to 10.30.1.250 port 22: error in libcrypto

# From CentOS 6 to RHEL 9:
no hostkey alg

The root cause stems from OpenSSL 3.0's stricter security policies and the deprecation of older algorithms. CentOS 6's OpenSSH 5.3 attempts to use SHA-1 based RSA signatures, while RHEL 9's OpenSSH 8.7 enforces stronger defaults.

First, modify the RHEL 9 client configuration to support legacy algorithms:

# Create or modify ~/.ssh/config
Host legacy-server
    HostName 10.30.1.250
    User ewessel
    KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
    HostKeyAlgorithms ssh-rsa,rsa-sha2-256,rsa-sha2-512
    Ciphers aes256-ctr,aes192-ctr,aes128-ctr
    MACs hmac-sha2-256,hmac-sha1

Update the server's SSH configuration to support modern protocols:

# Edit /etc/ssh/sshd_config on CentOS 6
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
HostKeyAlgorithms ssh-rsa,rsa-sha2-256,rsa-sha2-512
Ciphers aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-256,hmac-sha1

For RHEL 9, you can temporarily relax cryptographic policies:

# Set legacy policy temporarily
sudo update-crypto-policies --set LEGACY

# Verify the change
sudo update-crypto-policies --show

If SSH/SFTP proves problematic, consider these alternatives:

# Using rsync with reduced security
rsync -avz -e 'ssh -o KexAlgorithms=diffie-hellman-group14-sha1' ewessel@10.30.1.250:/source/path /destination/path

# Using netcat for large transfers
# On CentOS 6:
tar -czf - /path/to/files | nc -l 1234
# On RHEL 9:
nc 10.30.1.250 1234 | tar -xzf - -C /destination

After making these changes, test the connection with verbose output:

ssh -vvv legacy-server
sftp -v legacy-server

When attempting to establish SSH/SFTP connections between modern RHEL 9 systems (running OpenSSL 3.0) and legacy CentOS 6 servers (using OpenSSL 1.0.1), administrators frequently encounter the "error in libcrypto" message. This stems from fundamental changes in OpenSSL's architecture and default security policies.

The debug output reveals critical version mismatches:

RHEL 9: OpenSSH_8.7p1, OpenSSL 3.0.1
CentOS 6: OpenSSH_5.3p1, OpenSSL 1.0.1e-fips

OpenSSL 3.0 introduced significant architectural changes including:

• Provider-based cryptographic operations
• Stricter default security policies
• Deprecated algorithms (like SHA-1 in some contexts)

For temporary file transfers, modify the RHEL 9 SSH client configuration:

# /etc/ssh/ssh_config.d/10-legacy.conf
Host legacy_centos6
    Hostname 10.30.1.250
    KexAlgorithms diffie-hellman-group-exchange-sha256
    HostKeyAlgorithms ssh-rsa
    Ciphers aes256-ctr
    MACs hmac-sha2-256
    PubkeyAcceptedKeyTypes ssh-rsa
    StrictHostKeyChecking no

For production environments, consider these approaches:

# Option 1: Intermediate jump host with compatible OpenSSL
ssh -J bridge_host@modern_openssl user@centos6

# Option 2: Rebuild CentOS 6 OpenSSH with backported security
# Requires EPEL repository:
sudo yum install centos-release-SCL
sudo yum install rh-ssl102 openssh-server

While downgrading cryptographic policies enables connectivity, implement additional safeguards:

# Network-level protection
iptables -A INPUT -p tcp --dport 22 -s 10.30.1.225 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP

# SSH service hardening on CentOS 6
echo "Protocol 2" >> /etc/ssh/sshd_config
echo "PermitRootLogin no" >> /etc/ssh/sshd_config
service sshd restart

When SSH proves problematic, consider:

# Using rsync via temporary NFS share
mkdir /mnt/temp_share
mount -t nfs 10.30.1.225:/home /mnt/temp_share
rsync -avz /mnt/temp_share/ /new_server/home/