SSH says no matching key exchange method, but the client lists the method as available

Two adjacent things that bite in the same situation.

Ciphers and MACs go the same way. The removals happen in waves across releases, so a machine that connected to your switch last year may refuse this year after an upgrade, with a different algorithm named each time. If you maintain old equipment, expect this as a recurring maintenance item rather than a one-off.

Distribution-level crypto policies can override your config. Several distributions now ship a system-wide policy that constrains what SSH will do regardless of per-host settings. If your host block appears to be ignored, that is usually why, and the fix is at the policy level rather than in your config file.

The long-term answer for a switch is firmware, if any exists. Where it does not, the config entry is a legitimate way to keep managing hardware that outlived its crypto.

The distinction that resolves this: supported and enabled by default are two different lists, and the command you ran shows the first one.

Modern SSH clients still contain the code for a number of older algorithms, so they appear when you ask what is compiled in. But they have been removed from the default offer list because they are considered too weak — small key sizes, or hashes no longer trusted. The client will use them only if you ask explicitly, which is exactly what you discovered.

So nothing is inconsistent. The client is saying "I know how to do that, and I will not do it unless you insist." Your config entry is the supported way to insist.

That design is deliberate: it lets old equipment keep working while making sure nobody connects to it weakly by accident.

The config entry is the right answer, and it is worth writing it narrowly rather than globally:

Host old-switch old-switch.internal 10.0.0.5
    KexAlgorithms +diffie-hellman-group1-sha1
    HostKeyAlgorithms +ssh-rsa
    PubkeyAcceptedAlgorithms +ssh-rsa

Three things worth noting.

The leading plus sign appends to the default list instead of replacing it. Without it you have restricted this host to exactly one algorithm, which usually works and occasionally produces a much more confusing failure later.

You will very likely need the host key and public key lines too. The key exchange is only the first negotiation that fails; once you fix it, the next one fails, and people often think their fix did not work.

And scope it to the specific host. Putting weak algorithms in a global block quietly weakens every connection you make from that machine, which is the actual risk here rather than talking to one old switch.

Useful debugging note since you mentioned there is no extra-verbose flag: there is, it is just repeated. ssh -vvv gives three levels, and the negotiation section shows both sides' offered lists side by side.

Reading those two lists next to each other turns this class of problem from guesswork into a set intersection you can do by eye, and it tells you immediately which negotiation stage is failing rather than which one you assumed.