SSH: “no matching key exchange method found. Their offer: diffie-hellman-group1-sha1”

Ao tentar acessar um servidor SSH qualquer com o habitual comando:

ssh [email protected]

Me deparei com a seguinte mensagem de erro:

Unable to negotiate with 192.168.1.1 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

Após algumas pesquisas na internet, consegui resolver simplesmente adicionando um simples parâmetro:

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 [email protected]

**Atualização**:

Devido a constantes atualizações do protocolo ssh, outros erros semelhantes podem ocorrer já que algumas criptografias já não são mais suportadas, ontem mesmo me deparei com outro erro e novamente tive que procurar a solução e a encontrei na [página oficial do projeto Open SSH](https://www.openssh.com/):

> OpenSSH implements all of the cryptographic algorithms needed for compatibility with standards-compliant SSH implementations, but since some of the older algorithms have been found to be weak, not all of them are enabled by default. This page describes what to do when OpenSSH refuses to connect with an implementation that only supports legacy algorithms.

Que em tradução livre ficaria mais ou menos assim:

OpenSSH implementa todos os algoritmos criptográficos necessários para compatibilidade com os padrões compatíveis de implementações SSH, mas uma vez que alguns dos algoritmos mais antigos tornaram-se fracos, nem todos eles são ativadas por padrão. Esta página descreve o que fazer quando o OpenSSH se recusa a conectar-se com algum servidor que suporta apenas algoritmos legados.

OpenSSH Legacy Options

When a SSH client connects to a server, each side offers lists of connection parameters to the other. These are, with the corresponding ssh_config keyword:

* KexAlgorithms: the key exchange methods that are used to generate per-connection keys
* Ciphers: the ciphers to encrypt the connection
* MACs: the message authentication codes used to detect traffic modification
* PubkeyAcceptedKeyTypes: the public key algorithms that the server can use to authenticate itself to the client
* For a successful connection, there must be at least one mutually-supported choice for each parameter.

If the client and server are unable to agree on a mutual set of parameters then the connection will fail. OpenSSH (7.0 and greater) will produce an error message like this:

Unable to negotiate with legacyhost: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

In this case, the client and server were unable to agree on the key exchange algorithm. The server offered only a single method diffie-hellman-group1-sha1. OpenSSH supports this method, but does not enable it by default because is weak and within theoretical range of the so-called Logjam attack.

The best resolution for these failures is to upgrade the software at the other end. OpenSSH only disables algorithms that we actively recommend against using because they are known to be weak. In some cases, this might not be immediately possible so you may need to temporarily re-enable the weak algorithms to retain access.

For the case of the above error message, OpenSSH can be configured to enable the diffie-hellman-group1-sha1 key exchange algorithm (or any other that is disabled by default) using the KexAlgorithms option – either on the command-line:

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 user@legacyhost

or in the `~/.ssh/config` file:

Host somehost.example.org
KexAlgorithms +diffie-hellman-group1-sha1

The ‘+’ before the list instructs ssh to **append** the algorithm to the client’s default set rather than replacing the default. By appending, you will automatically upgrade to the best supported algorithm when the server starts supporting it.

Another example, this time where the client and server fail to agree on a public key algorithm for host authentication:

Unable to negotiate with legacyhost: no matching host key type found. Their offer: ssh-dss

OpenSSH 7.0 and greater similarly disable the ssh-dss (DSA) public key algorithm. It too is weak and we recommend against its use. It can be re-enabled using the HostKeyAlgorithms configuration option:

ssh -oHostKeyAlgorithms=+ssh-dss user@legacyhost

or in the `~/.ssh/config` file:

Host somehost.example.org
HostKeyAlgorithms +ssh-dss

Depending on the server configuration, it’s possible for other connection parameters to fail to negotiate. You might find the Ciphers and/or MACs configuration options useful for enabling these. It’s also possible to query which algorithms ssh supports:

ssh -Q cipher # List supported ciphers
ssh -Q mac # List supported MACs
ssh -Q key # List supported public key types
ssh -Q kex # List supported key exchange algorithms

Finally, it’s also possible to query the configuration that ssh is actually using when attempting to connect to a specific host, by using the -G option:

ssh -G [email protected]

which will list all the configuration options, including the chosen values for the Ciphers, MACs, HostKeyAlgorithms and KexAlgorithms parameters.

*Ps.: Talvez depois, com tempo eu traduza isso.*