3

I have updated my /etc/ssh/sshd_config file based on the answers provided here - OSX 10.11 enable ssh diffie-hellman-group1-sha1
https://stackoverflow.com/questions/26424621/algorithm-negotiation-fail-ssh-in-jenkins

# Ciphers and keying   
Ciphers 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,arcfour128,arcfour256,aes128-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com  

#RekeyLimit default none  
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1

And restarted the SSHD daemeon using these commands: 

sudo launchctl unload  /System/Library/LaunchDaemons/ssh.plist  
sudo launchctl load -w  /System/Library/LaunchDaemons/ssh.plist

But still I am getting the same error:

id$ git clone ssh://<user>@<host>:<port>/<repo>
Cloning into 'xxxxx'...
Unsupported KEX algorithm "+diffie-hellman-group1-sha1"
/Users/<user>/.ssh/config line 2: Bad SSH2 KexAlgorithms '+diffie-hellman-group1-sha1'.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists.

I am on OpenSSH_6.9p1, LibreSSL 2.1.8.

Any help here would be much appreciated.

Improve this question
1
  • From the error message, it looks like you might also want to double-check the contents of the /Users/<user>/.ssh/config client config file; I suspect that the culprit may lie there, not in the server-side config files.
    – Castaglia
    Mar 22, 2016 at 5:12

2 Answers 2

Reset to default
3

This feature (the + sign) is supported from openssh 7.0:

If you need to use this specific algorithm, you need to specify it directly in ~/.ssh/config, such as

KexAlgorithms diffie-hellman-group1-sha1
Improve this answer
5
  • Bad SSH2 KexAlgorithms '+ here because OpenSSH previous v7 does not "understand" the '+diffie-hellman-group1-sha1' syntax you used. I have that too with a Debian Jessie server. You can cure this by listing your server supported ciphers with ssh -Q cipher, copy/paste the result in sshd_config, then adding your wanted cipher. E.g Ciphers chacha20-poly1305@openssh.com, (...),diffie-hellman-group1-sha1. Note I've put no "+".
    – tuk0z
    Jan 31, 2018 at 16:29
  • that is precisely what I wrote in this answer.
    – Jakuje
    Jan 31, 2018 at 16:31
  • You pint pointed cause of OP's issue ; I explain how to cure it on the server side.
    – tuk0z
    Jan 31, 2018 at 16:35
  • 1
    @tuk0z The ssh -Q cipher lists client supported ciphers. The diffie-hellman-group1-sha1 is not a cipher, but key exchange algorithm. Doing as you wrote, would prevent your sshd server from starting, because it is invalid value for ciphers.
    – Jakuje
    Feb 1, 2018 at 8:29
  • 1
    Yes. So with OpenSSH previous v7 we need to add any supported Key exchange algorithm using the old syntax, e.g. KexAlgorithms [default Kex],diffie-hellman-group1-sha1 that is without the + in /etc/ssh/sshd_config. My bad for mixing Cipher and Kex in my previous comment and thank you @jakuje for noticing!
    – tuk0z
    Feb 17, 2018 at 8:40
0

Adding a login with options to .ssh/config on Mac OS X

I had a similar issue on Mac OS X 12.4 Monterey when logging in to an old Ubuntu server via SSH, so after reading this (and many other pages) and noting what the server offered on unsuccessful attempts, I tried adding the lines to my SSH config file as suggested above, but without success.

Then I tried logging in using the specific command and the first of three algorithms offered by the old server:

ssh -o KexAlgorithms=diffie-hellman-group-exchange-sha1 root@MYSERVERIP

(obviously replacing the latter with my servers IP address) which was successful.

Then because I use other SSH quick logins I added the following in "~/.ssh/config":

Host PETNAME
  HostName MYSERVERIP
  User root
  port 22
  KexAlgorithms=diffie-hellman-group-exchange-sha1

where "PETNAME" is a memorable name I allocated to the server, and "root" is the user - obviously this could be another username on the server.

I can now connect with ssh PETNAME on the command line (entering the password after the prompt).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.