Greetings,
Even though I had done the F33 upgrade sometime ago, I am only now seeing that it appears to have affected my rsync backups. When my CentOS server issues the rsync backup the following error appears: no hostkey alg rsync: connection unexpectedly closed (0 bytes received so far) [receiver] rsync error: unexplained error (code 255) at io.c(600) [receiver=3.0.6]
Any suggestions on how to resolve this? I've done some Googling; it seems that crypto policies have been upgraded; general suggestion is to regenerate keys; but so far I'm having no success restoring the rsync process.
Much thanks as always,
Max pyz@brama.com
On Sat, 21 Nov 2020 14:14:23 -0500 (EST) Max Pyziur wrote:
Any suggestions on how to resolve this?
I f33 install had to fiddle my ~/.ssh/config file to allow "deprecated" key types for my hostgator web page I update with rsync (hostgator is running an old ssh server version) I added these lines:
Host tomhorsley.com Port 2222 PubkeyAcceptedKeyTypes +ssh-rsa User tomhorsley
Now I can rsync to upload my web pages to tomhorsley.com
Something similar might fix your problem.
Hi
On Sat, 21 Nov 2020 14:14:23 -0500 Max Pyziur wrote:
Even though I had done the F33 upgrade sometime ago, I am only now seeing that it appears to have affected my rsync backups. When my CentOS server issues the rsync backup the following error appears: no hostkey alg rsync: connection unexpectedly closed (0 bytes received so far) [receiver] rsync error: unexplained error (code 255) at io.c(600) [receiver=3.0.6]
Seen that.
You have to change the configuration of sshd on your F33 machine.
I've chosen to not modify the crypto policies, but to enable ssh-rsa with a snippet under /etc/ssh/sshd_config.d/
-------------------- /etc/ssh/sshd_config.d/20-NAME.conf --------- # To load *before* 50-redhat.conf
# From /etc/crypto-policies/back-ends/opensshserver.config # then add ,ssh-rsa No +ssh-rsa allowed (seems) HostKeyAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,rsa-sha2-256,rsa-sha2-256-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-512-cert-v01@openssh.com,ssh-rsa
# Weird: this +ssh-rsa works here. # The setting (without +) in # /etc/crypto-policies/back-ends/opensshserver.config # do not lose this +ssh-rsa PubkeyAcceptedKeyTypes +ssh-rsa ----------------------------------------------------------------------
The 20- prefix is needed to be alphabetically before 50-redhat.conf that loads/include /etc/crypto-policies/back-ends/opensshserver.config
On Sat, 21 Nov 2020, Francis.Montagnac@inria.fr wrote:
Hi
On Sat, 21 Nov 2020 14:14:23 -0500 Max Pyziur wrote:
Even though I had done the F33 upgrade sometime ago, I am only now seeing that it appears to have affected my rsync backups. When my CentOS server issues the rsync backup the following error appears: no hostkey alg rsync: connection unexpectedly closed (0 bytes received so far) [receiver] rsync error: unexplained error (code 255) at io.c(600) [receiver=3.0.6]
Seen that.
You have to change the configuration of sshd on your F33 machine.
I've chosen to not modify the crypto policies, but to enable ssh-rsa with a snippet under /etc/ssh/sshd_config.d/
-------------------- /etc/ssh/sshd_config.d/20-NAME.conf --------- # To load *before* 50-redhat.conf
# From /etc/crypto-policies/back-ends/opensshserver.config # then add ,ssh-rsa No +ssh-rsa allowed (seems) HostKeyAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,rsa-sha2-256,rsa-sha2-256-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-512-cert-v01@openssh.com,ssh-rsa
# Weird: this +ssh-rsa works here. # The setting (without +) in # /etc/crypto-policies/back-ends/opensshserver.config # do not lose this +ssh-rsa PubkeyAcceptedKeyTypes +ssh-rsa
The 20- prefix is needed to be alphabetically before 50-redhat.conf that loads/include /etc/crypto-policies/back-ends/opensshserver.config
Thank you for your reply. I'll review this.
In the meantime, for the sake of expediency, I've issued the following command on the client F33 machines as root: update-crypto-policies --set LEGACY
Once executed, it says that the machine needs to be rebooted for the policies to properly go into effect.
This has caused the rsync backup that I have in place to function.
But in the current world, tougher rather than looser encryption is better.
Thank you again,
Max
Hi,
Max Pyziur wrote:
But in the current world, tougher rather than looser encryption is better.
With that in mind, instead of using older/weaker crypto on your Fedora host, you could use newer/stronger crypto from your CentOS 6 client¹.
Something like:
- Create an ECDSA key ssh-keygen -t ecdsa -b 384
- Set the HostKeyAlgorithms KexAlgorithms (on the command line or in an ssh config) KexAlgorithms ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1 HostKeyAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ssh-rsa,ssh-dss
¹ The ECDSA/ECDH algorithms are supported in openssh >= 5.3p1-95.el6_5. Though CentOS 6 will be EOL in a little over a week. So using weak algorithms is one of the lesser problems if you're running such a system. :)