10

I want to connect to a very old Linux system and try:

[krud@specht ~]$ ssh [email protected]
Unable to negotiate with 192.168.1.10 port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1

I read this page: ssh unable to negotiate - no matching key exchange method found

but if I try something like:

[krud@specht ~]$ ssh -oKexAlgorithms=+diffie-hellman-group1-sha1  [email protected]
Unable to negotiate with 192.168.1.10 port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss

Also adding the cipher type results in nothing:

[krud@specht ~]$ ssh -oKexAlgorithms=+diffie-hellman-group1-sha1  -c ssh-rsa [email protected]
Unknown cipher type 'ssh-rsa'
[krud@specht ~]$ ssh -oKexAlgorithms=+diffie-hellman-group1-sha1  -c ssh-dss [email protected]
Unknown cipher type 'ssh-dss'

How can I login?

Can I add older algorithms to my new Linux installation?

Any other chance to do some backup here without using scp?

Improve this question
2
  • 2
    Perhaps you already know this, but just in case: those old algorithms have been deprecated because they're considered less secure. If you value security, it's recommended to upgrade that old machine to get access to newer, more secure algorithms. And that's just SSH; that old machine likely has other vulnerabilities in its software, so exposing it to networks (let alone the Internet) carries risk. Commented Jun 8, 2024 at 13:58
  • It is absolutely clear that outdated software is harmful. But this system is stored on the attic, connected to the local network only on demand and used only to run very outdated old software which we do not have sources from. Commented Jun 10, 2024 at 7:29

2 Answers 2

Reset to default
19

Adding a cipher type option is not the right response to the no matching host key type error. ssh-rsa and ssh-dss belong to HostKeyAlgorithms and/or PubkeyAcceptedAlgorithms; they are not cipher types at all, so trying to add them to the -c option just causes ssh to immediately reject the command.

You might want to add a block like this to your ~/.ssh/config file:

Host nicename
    User zfrdh
    HostName 192.168.1.10
    KexAlgorithms diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
    HostKeyAlgorithms ssh-rsa,ssh-dss

Then you can try connecting with just ssh nicename.

Note that just adding the old algorithms back in to the KexAlgorithms and HostKeyAlgorithms lists may not work with some old SSH implementations, as they may not have allocated a sufficiently large buffer for all the protocol options a modern SSH client may wish to negotiate. If this happens to you, just offer it the algorithms it can understand to make the list of negotiables shorter, as I've done above.

If you use key authentication, and have moved to newer key formats on any systems that support it, you might want to add options like this to the Host block above:

    ForwardAgent no
    IdentityAgent none
    IdentitiesOnly yes
    IdentityFile ~/.ssh/old_key_for_old_systems/id_rsa

to prevent the old remote sshd's little head from exploding from all the new key types and other new stuff your new SSH client/agent may have available :-)

Depending on exactly how you are trying to authenticate and how old the remote sshd implementation is, you may need to add even more options.

Improve this answer
1
  • Specifically if using an RSA key (as your example suggests) and the server is doesn't support rsa-sha2 for host auth because it's old (as opposed to insanely configured) it most likely doesn't support rsa-sha2 for user auth either, so OpenSSH >= 8.8 needs PubkeyAcceptedAlgorithms or now-deprecated PubkeyAcceptedKeyTypes . And newer key types (ecdsa, ed25519) may fail on the old server, but keyfile format does not matter: an RSA key stored locally in a "BEGIN OPENSSH PRIVATE KEY" new-format file will work to exactly the same extent as an old-format "BEGIN RSA PRIVATE KEY". Commented Jun 10, 2024 at 4:25
3

Oh man this is a familliar frustration. The SSH UI could really stand to be a little kinder to the users in the error messages and let you know what options you have at hand to control these circumstances. I can appreciate that they don't for a variety of reasons, but even referencing a section of the man page in the error messages would save many people plenty of hair pulling and gnashing of teeth.

Simply put, +oKexAlgorithms= is where you specify the now-obsoleted algorithms you wish to temporarily renable - as you've discovered.

What you're looking for is -oPubkeyAcceptedKeyTypes=, where you specify the now-obsoleted key types. You may also find a need for -oHostKeyAlgorithms=

Putting these together, you'll get something roughly like the following which I regularly need to access an obsolete and non-upgradable system on my LAN.

ssh -oKexAlgorithms=+diffie-hellman-group-exchange-sha1 -oPubkeyAcceptedKeyTypes=+ssh-rsa -oHostKeyAlgorithms=+ssh-rsa [email protected]

Naturally, you may need to adjust these for your use cases.

I hope it helps.

(and if you can, upgrade the version of ssh on that system so you can quickly forget these option flags!)

Improve this answer
1
  • This is backwards; you only use KexAlgorithms for the kex algorithms, not the others, and you absolutely need HostKeyAlgorithms for the server in this Q, but you only need PubkeyAcceptedAlgorithms (or obsolete KeyTypes) if authenticating the user with an RSA or DSA (DSS) key, which the Q does not state. Commented Jun 10, 2024 at 4:29

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.