17

I have a shell server on an embedded system (It's a 32Bit ARMel system). When I go to login to it, I use:

$ ssh root@ip 
Unable to negotiate with ip port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss

I tried to give it one of the expected cypher types with the -c option:

$ ssh -c ssh-dss root@ip 
Unknown cipher type 'ssh-dss'

or:

$ ssh -c ssh-rsa root@ip
Unknown cipher type 'ssh-rsa'

So I'm not sure what to do next. I have a UART serial console I can send commands to, but I'd rather be on SSH. I know it's running the service, but I don't know how to log in to it.

Improve this question
0

4 Answers 4

Reset to default
23

I see this a lot with legacy Cisco embedded systems whose firmware can no longer be upgraded to modern ssh standards.

In addition to Host Key Algorithm, you may need to use an obsoleted Key Exchange Algorithm, and/or Cipher specification as well.

Bash Example:

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1\
 -oHostKeyAlgorithms=+ssh-rsa\
 -oCiphers=+aes256-cbc\
 <user>@asa5505

The good news is that OpenSSH (what I use) usually tells me what algorithms or cyphers are being offered - otherwise I might have to do a lot of trial and error.

If I do, available protocols can be listed in OpenSSH with:

ssh -Q [ciphers|hostkeyalgorithms|kexalgorithms|...]

Update: As there seems a lot of interest in doing this using ssh_config (thanks, Bob,Z,et al), I will provide an example for that method:

############################################
# ~/.ssh/config
Host 'asa5505*'
        KexAlgorithms +diffie-hellman-group1-sha1
        HostKeyAlgorithms +ssh-rsa
        Ciphers +aes128-cbc

Because these protocols have been deprecated for security reasons, you should restrict default usage with a "Host" or "Match" qualification so they are only used on those legacy targets that require them.

Likewise, you should avoid putting these exceptions into /etc/ssh/ssh_config or under /etc/ssh/ssh_config.d/ unless your intent is to have all current and future users utilize them by default.

For all the gritty details, see:

man ssh_config
Improve this answer
4
  • yeah, its a 32 bit armel system, but Im still thinking I may try to compile a newer version of ssh.
    – j0h
    Commented Nov 27, 2022 at 18:22
  • 1
    Not even an option on my Cisco routers, @j0h. But, as long as OpenSSH keeps supporting the obsoleted ciphers/algorithms, I wouldn't even bother. I just write a macro for connecting to each of them and forget about it.
    – Frobozz
    Commented Nov 27, 2022 at 18:40
  • 3
    @Frobozz You should be able to save server-specific client configs in ssh_config.
    – Bob
    Commented Nov 28, 2022 at 5:47
  • An ssh_config example would be good to have here for posterity. I'll add one. Thanks, @Bob.
    – Frobozz
    Commented Nov 29, 2022 at 16:59
18

Try using this:

ssh -oHostKeyAlgorithms=+ssh-rsa root@ip

Notes:

Improve this answer
3
  • 3
    Would be interesting to find out why this even needed. Apparently openssh knows which algo is required because the server tells it so, and it has the support, so why a special setting is required to connect? Is it considered insecure?
    – Andrew Savinykh
    Commented Nov 27, 2022 at 23:57
  • 9
    @AndrewSavinykh Yes, modern SSH clients will refuse to use outdated crypto (e.g. anything based on sha1) by default, while those old algorithms are the only ones supported by legacy devices. You have to manually opt in by telling the client "yes, I know this is kinda insecure, connect anyway, it's still better than telnet". (That's still way better than enabling old crypto globally as that would also enable downgrade attacks on connections to servers that are perfectly capable of modern crypto.)
    – TooTea
    Commented Nov 28, 2022 at 8:38
  • 2
    Slightly confusingly, multiple "algorithms" can be used with the same key. So "ssh-rsa" keys are still fine in the default configuration, but the "ssh-rsa" algorithm is not because it uses sha1 based signatures.
    – plugwash
    Commented Nov 28, 2022 at 17:47
5

It also depends on what you're running on your own machine. If you're running something like Arch or Fedora36+, which is on OpenSSL3.0, then older algorithms have been deprecated or disabled. I've had to include this configuration inside my ssh config being on 3.0 connecting to older servers:

HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
Improve this answer
4
  • 1
    Might consider adding a "Host" or "Match" restriction to limit usage of the deprecated protocols to just those targets that still require them.
    – Frobozz
    Commented Nov 29, 2022 at 2:23
  • 1
    This also apply to MacOs Ventura 13.0.1
    – JFL
    Commented Nov 29, 2022 at 15:35
  • adding "PubkeyAcceptedAlgorithms +ssh-rsa" after "HostKeyAlgorithms" resolved my problem.
    – nix
    Commented Apr 26, 2023 at 11:09
  • fedora 38 with OpenSSL 3.0.8 7 Feb 2023 (Library: OpenSSL 3.0.8 7 Feb 2023) works.
    – Nick Dong
    Commented Aug 31, 2023 at 15:21
0

A neat trick, that works as of now and could help the backward compatibility if the algorithms ever get removed from OpenSSH, is using a container of an older Linux distro image.

There is more overhead (although the container could be kept around at the cost of a few tens MB), and with possible security risks (possibly unmatained OpenSSH versions) that may or may not be acceptable.

Here's a one-liner, with its own limitations:

docker run --rm -it debian:jessie sh -c 'apt-get update && apt install -y --force-yes openssh-client && ssh the_host

Improve this answer

Not the answer you're looking for? Browse other questions tagged .