I have once written about how one can create a configuration file specifying the SSH connection parameters (hostname, port, MACs, ciphers, key exchange algorithms etc.) for different servers through aliases. Connecting via SSH in this manner is much more efficient since there is much less typing involved.
However, there are situations in which you might not want to add all settings for a given server to your ssh configuration file. One typical case is when you know you will connect to the server only a single time, but you have chosen a set of default cryptographic algorithms which the target server does not support. In this case, you might get errors like these:
no matching mac found: client hmac-sha2-512 server hmac-sha1,hmac-md5
no matching cipher found: client aes256-ctr server aes128-cbc,blowfish-cbc
Unable to negotiate a key exchange method
no hostkey alg
Each of the errors above says that the server does not support any combination of necessary cryptographic algorithms (ciphers, MACs etc.) you allow ssh to use. This might happen often if you try to connect to servers which are not actively maintained.
Luckily the solution is easy: just choose the cryptographic algorithms by hand to connect using methods which the server supports (although the example below specifies lots of things, you need only specify whatever is related to the error message you got):
ssh email@example.com -m hmac-sha1 -c aes128-cbc -o KexAlgorithms=diffie-hellman-group1-sha1 -o HostKeyAlgorithms=ssh-rsa
Here is a list with the main security parameters which can be specified (you can specify several possible algorithms for a given parameter by separating them with commas, e.g. -c aes128-cbc,aes128-ctr):
|-m <MACs>||specifies the allowed MAC(s)|
|-c <ciphers>||specifies the allowed cipher(s)|
|-o KexAlgorithms=<methods>||specifies the allowed key exchange algorithm(s)|
|-o HostKeyAlgorithms=<algorithms>||specifies the allowed authentication algorithm(s)|
To visualize the parameter negotiation, run the command above with the -vv option. Look for a set of messages similar to the ones shown below:
debug2: kex_parse_kexinit: diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa debug2: kex_parse_kexinit: aes128-cbc debug2: kex_parse_kexinit: aes128-cbc debug2: kex_parse_kexinit: hmac-sha1 debug2: kex_parse_kexinit: hmac-sha1 debug2: kex_parse_kexinit: none,firstname.lastname@example.org,zlib debug2: kex_parse_kexinit: none,email@example.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,blowfish-cbc,3des-cbc debug2: kex_parse_kexinit: aes128-cbc,blowfish-cbc,3des-cbc debug2: kex_parse_kexinit: hmac-sha1,hmac-md5 debug2: kex_parse_kexinit: hmac-sha1,hmac-md5 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib
The first set of highlighted lines shows the algorithms you allow, while the second shows the algorithms supported by the server. Unless you choose a set of algorithms which is fully supported by the server, you will get an error similar to the ones shown above. When in trouble, use the -vv option to figure out what the server actually supports, but keep in mind that the less secure the algorithms you use, the less secure your connection will be!
A list of ciphers, MACs, key exchange and authentication algorithms supported by your ssh installation can be seen in the manual of ssh_config: