Join Log in
Score:2
Eric W avatar Server

Error in libcrypto connecting RHEL 9 server to Centos 6 via SFTP/SSH

br flag
Eric W

I am trying to connect from a new RHEL9 server to an older Centos 6 server to SFTP files from the older server to the new one for an upgrade, but when connecting from 9 to 6 I get the following error:

[ewessel@ftp ~]$ ssh -v [email protected]
OpenSSH_8.7p1, OpenSSL 3.0.1 14 Dec 2021
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: configuration requests final Match pass
debug1: re-parsing configuration
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: Connecting to 10.30.1.250 [10.30.1.250] port 22.
debug1: Connection established.
debug1: identity file /home/ewessel/.ssh/id_rsa type -1
debug1: identity file /home/ewessel/.ssh/id_rsa-cert type -1
debug1: identity file /home/ewessel/.ssh/id_dsa type -1
debug1: identity file /home/ewessel/.ssh/id_dsa-cert type -1
debug1: identity file /home/ewessel/.ssh/id_ecdsa type -1
debug1: identity file /home/ewessel/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/ewessel/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/ewessel/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/ewessel/.ssh/id_ed25519 type -1
debug1: identity file /home/ewessel/.ssh/id_ed25519-cert type -1
debug1: identity file /home/ewessel/.ssh/id_ed25519_sk type -1
debug1: identity file /home/ewessel/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/ewessel/.ssh/id_xmss type -1
debug1: identity file /home/ewessel/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.7
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: compat_banner: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000002
debug1: Authenticating to 10.30.1.250:22 as 'ewessel'
debug1: load_hostkeys: fopen /home/ewessel/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: diffie-hellman-group-exchange-sha256 need=32 dh_need=32
debug1: kex: diffie-hellman-group-exchange-sha256 need=32 dh_need=32
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<8192<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_GROUP received
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: SSH2_MSG_KEX_DH_GEX_REPLY received
debug1: Server host key: ssh-rsa SHA256:nMDl3BNpsOOJ6gyMudi6szQS3Pchxe2Ttmj1dH9fLB8
debug1: load_hostkeys: fopen /home/ewessel/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host '10.30.1.250' is known and matches the RSA host key.
debug1: Found key in /home/ewessel/.ssh/known_hosts:1
ssh_dispatch_run_fatal: Connection to 10.30.1.250 port 22: error in libcrypto

if I try connecting the other way I get the following error:

[ewessel@ftp ~]$ ssh -v [email protected]
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 10.30.1.225 [10.30.1.225] port 22.
debug1: Connection established.
debug1: identity file /home/ewessel/.ssh/identity type -1
debug1: identity file /home/ewessel/.ssh/identity-cert type -1
debug1: identity file /home/ewessel/.ssh/id_rsa type -1
debug1: identity file /home/ewessel/.ssh/id_rsa-cert type -1
debug1: identity file /home/ewessel/.ssh/id_dsa type -1
debug1: identity file /home/ewessel/.ssh/id_dsa-cert type -1
debug1: identity file /home/ewessel/.ssh/id_ecdsa type -1
debug1: identity file /home/ewessel/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.7
debug1: match: OpenSSH_8.7 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug1: kex: client->server aes128-ctr hmac-sha1 none
no hostkey alg

Any idea on how to get these 2 machines to talk to each other? I'd like to copy the user files from the old machine to the new so I can decommission the old Centos 6 machine.

5652
2 + 0
ssh
Score:4
HBruijn avatar Server
in flag
HBruijn

RHEL 9 defaults to stronger cryptographic ciphers and algorithms, breaking compatibility with legacy systems.

Your options for the SSH daemon on the RHEL 9 system are:

  • Switch the system-wide cryptographic policy to a mode compatible with earlier releases as described in the RHEL 9 hardening guide. As root (or with sudo) run:

    # update-crypto-policies --set LEGACY
Setting system policy to LEGACY

    and reboot.

    Note: this changes all daemons and system settings and is a bit overkill if you only need to adjust the settings for ssh and sshd.

  • Exclude (only) sshd from the system-wide cryptographic policy. You opt-out by editing /etc/sysconfig/sshd and uncommenting the line # CRYPTO_POLICY= , (if necessary you can then adjust adjust /etc/ssh/sshd_config and add legacy crypto settings) and restart the ssh daemon.

For the ssh command line client on the RHEL 9 system: you're recommended to edit ˜/.ssh/config and override the modern/secure system wide ssh client defaults by adding a Host entry that adds support for suitable legacy encryption options for that particular host:

#    ˜/.ssh/config

Host rhel6.example.com
  KexAlgorithms +diffie-hellman-group14-sha1
  MACs +hmac-sha1
  HostKeyAlgorithms +ssh-rsa
  PubkeyAcceptedKeyTypes +ssh-rsa
  PubkeyAcceptedAlgorithms +ssh-rsa
+ 0
Score:-1
Ahmed Sahal avatar Server
je flag
Ahmed Sahal

To help resolve the error you encountered while connecting from a new RHEL9 server to an older CentOS 6 server for SFTP file transfer, follow these steps: Create a configuration file named "config" inside the ~/.ssh directory. The file should have no extension. You can use the command touch config to create it. Open the "config" file using a text editor of your choice, such as Vim, Vi, or Nano. Paste the following code into the "config" file:enter code here enter code here

KexAlgorithms diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1
HostkeyAlgorithms ssh-dss,ssh-rsa
Host rhel9.example.com
  KexAlgorithms +diffie-hellman-group14-sha1
  MACs +hmac-sha1
  HostKeyAlgorithms +ssh-rsa
  PubkeyAcceptedKeyTypes +ssh-rsa
  PubkeyAcceptedAlgorithms +ssh-rsa

Save the file after pasting the code. Restart the SSH server, either by restarting the sshd service or by rebooting the server. The exact method may vary depending on the distribution you are using. By following these steps, you should be able to eliminate the error you encountered while connecting to the CentOS 6 server. This configuration is also useful when connecting to a Cisco router via SSH.

+ 1
HBruijn avatar
in flag
HBruijn
IMHO there are several things wrong here: the first two lines in your proposed `~/.ssh/config` above the `Host` line set the default for *all hosts* rather than for only a specific host and are not needed . A ~/.ssh/config adjusts settings for the ssh/sftp/scp ***client*** and any changes there are picked immediately the next time you launch the client. Changing client settings does *not* require restarting the ssh ***daemon*** , let alone rebooting the server!
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.