SSH fails after migration


I recently migrated from x86 IPFire architecture to the new 64-bit architecture. Upon completion of the migration, I discovered that some legacy CentOS 6.0 machines can no longer SSH into IPFire. The legacy devices could successfully login to the IPfire prior to the migration.

On the CentOS devices I receive this message:
[root@somehost ~]# ssh root@xx.xx.xx.xx -p 222
no hostkey alg

On the IPFire Server I see the message in the log:
Unable to negotiate with xx.xx.xx.xx port 44902: no matching host key type foun d. Their offer:,,ssh-rs,,ssh-rsa,ssh-dss [preauth]

I realize the CentOS machines are EOL. They are currently in the process of being upgraded.

Why did this stop working? I realized there are stronger ciphers and keys available now, but this was working prior to the firewall migration.

If this is due to the absence of legacy host keys on the firewall or something with the architecture change, is there a way to allow IPFire to accept the legacy host keys temporarily while I migrate the older systems to a later OS?


Did you run the steps listed in the wiki architecture change page

If yes then the problem is likely that the default settings of openssh changed with regard to keys in the recent core updates, so that would likely be between the last 32 bit IPFire and the current 64 bit IPFire.

Openssh used to still accept the ssh-rsa keys that were based on sha1, however sha1 has been considered very weak and insecure for some time and the towards the end of 2021 the openssh version no longer enabled that key type to by default. Now the key that is used is ssh-rsa2 which is still an rsa key but it uses the stronger sha2 hash with 256 or 512 bit.

Here is the input from the openssh changelog for version 8.8p1

Potentially-incompatible changes ================================ This release disables RSA signatures using the SHA-1 hash algorithm by default. This change has been made as the SHA-1 hash algorithm is cryptographically broken, and it is possible to create chosen-prefix hash collisions for <USD$50K [1] For most users, this change should be invisible and there is no need to replace ssh-rsa keys. OpenSSH has supported RFC8332 RSA/SHA-256/512 signatures since release 7.2 and existing ssh-rsa keys will automatically use the stronger algorithm where possible. Incompatibility is more likely when connecting to older SSH implementations that have not been upgraded or have not closely tracked improvements in the SSH protocol. For these cases, it may be necessary to selectively re-enable RSA/SHA1 to allow connection and/or user authentication via the HostkeyAlgorithms and PubkeyAcceptedAlgorithms options. For example, the following stanza in ~/.ssh/config will enable RSA/SHA1 for host and user authentication for a single destination host: Host old-host HostkeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms +ssh-rsa We recommend enabling RSA/SHA1 only as a stopgap measure until legacy implementations can be upgraded or reconfigured with another key type (such as ECDSA or Ed25519).

If you have to stay with the insecure ssh-rsa based on sha1 hash then you would need to add in the enabling of that key into your ssh conf file on IPFire. I can’t remember what the command is but if you search on the openssh website or look

Bear in m ind that if you change the config to include these lines and enable that key type then you must not do a save on the IPFire WUI ssh page or the config will be overwritten. It will also be overwritten if you reboot or if a core update occurs so you will need to redo the changes in the config in any of those cases.


Hi Adolf,

Thanks for the information. I did run the architecture mitigation. I enabled the legacy hostkey on my firewall, it persisted after a save and reboot (/etc/ssh/sshd_config). I’ll probably take this approach for the time being. The old systems will be retired soon, and I’ll remove the config lines in sshd_config. Here are the lines I added:
# TEMPORARY - Allow legacy support of CentOS 6 Systems

Thank for your help,