No matches found mac os

Question: Q: SSH — no matching host key type found

I’m for the moment a somewhat happy camper after installing MacOS Sierra. After a few hours, after the update, i was up for some ssh sessions to some of my servers and routers. Hmm, i can’t connect to the boxes. What’s up?

The first server responded with:

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

This issue was solved through a search on Google. The solution was (not to update the server, which i must do soon) to delete the remark pound «#» before the row that starts with «MACs hmac-md5,hmac-sha1, umac-64@openssh.com ,hmac-ripemd160» and add the row «HostkeyAlgorithms ssh-dss» last in the /etc/ssh/ssh_config file. Next i created a separat part for each server, that needs some legacy support

The second server responded with:

Unable to negotiate with port 22: no matching host key type found. Their offer: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ssh-ed25519

This issue is also solved. This solution wasn’t found on Google. I just thought this would work. I just added the algorithms «ssh-rsa,rsa-sha2-512,rsa-sha2-256,ssh-ed25519» after the «HostkeyAlgorithms ssh-dss» (be sure to add a «,»).

Question 1

Anyway. is there any security issues or other concerns that i should know with this lack of support, or is is just okey to add this in /etc/ssh/ssh_config file ?

Question 2

Which of this algos should not or should be used?

Question 3

What is the best practice and recommended configuration for the /etc/ssh/ssh_config file?

MacBook Pro with Retina display, macOS Sierra (10.12), null

Источник

Question: Q: ssh error no matching cipher found trying to connect

I am running macOS 10.13.2 I connect via terminal app with ssh to a non-mac system and am getting this error message:

Unable to negotiate with X.X.X.X port 22: no matching cipher found. Their offer: aes128-cbc,blowfish-cbc,3des-cbc

I don’t know how long this has been broken as I don’t connect to this server often. I would have thought it would work, since the /etc/ssh/ssh_config file has this for the defaults:

I don’t have ciphers defined in my

/.ssh/config file, so it should just be using the defaults.

Posted on Jan 9, 2018 12:06 PM

All replies

Loading page content

Page content loaded

Edit that line of the file to take out the «#». (Right now the cipher list is commented out.)

Jan 10, 2018 7:28 AM

Well, that does change the error message, but still doesn’t connect.

According to the comments at the top of the ssh_config file:

# Site-wide defaults for some commonly used options. For a comprehensive # list of available options, their meanings and defaults, please see the # ssh_config(5) man page.

the commented lines in it are just a listing of the defaults. They aren’t commented out, because they aren’t in use. So, uncommenting them really shouldn’t change the defaults being used, however, I tried it anyway, and I did get a different error this time:

ssh_dispatch_run_fatal: Connection to 10.2.47.23 port 22: DH GEX group out of range

Источник

macOS – SSH Error ‘No Matching Exchange Method Found’

KB ID 0001245В

Problem

Note Certified working all the way up to macOS Big Sur version 11.2.3

I thought my RoyalTSX had broken today, I upgraded it a couple of weeks ago, and I upgraded to macOS Catalina 10.15 the other day. After this, all my SSH sessions refused to connect with this error;

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

Note: You may also see the following error;

Unable to negotiate with x.x.x.x port 22: no matching cipher found. Their offer: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc

Update: 10/04/20: With newer equipment you may see the following error;

Unable to negotiate with x.x.x.x port 22: no matching MAC found Their offer: hmac-sha2-256

Mac SSH Error – Fix

This is not Apple’s fault, it’s OpenSSH version 7. SHA1 is weak, so support for it has been removed. Which is fine, but all my clients Cisco Firewalls/Routers/Switches are probably all using В RSA/SHA1. So until they re all updated I’m going to need to re-enable SHA1.

Open a terminal windows and execute the following;

Locate the line ‘В # В MACs hmac-md5,hmac-sha1, hmac-sha2-256 ,umac-64@openssh.com,hmac-ripemd160′В and remove the Hash/Pound sight from the beginning, and add the extra hashing algorithm that I’ve shown above in red.В

Locate the line ‘В # В Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc’В and remove the Hash/Pound sight from the beginning.

Then paste the following on the end;

Mac SSH Error – Quitting Nano

To quit nano, use the Ctrl-X key combination. because you are working on has been modified since the last time you saved it, you will be prompted to save the file first. Type y to save the file.

Theres no reason to reboot, it should work straight away.

But Wait – Theres More!

This is going to happen every time you upgrade your mac, I’ve started taking a backup of the ssh_config file, then I can just restore it back again, like so;

Backup macOS SSH Settings & Ciphers

Restore macOS SSH Settings & Ciphers

Related Articles, References, Credits, or External Links

Author: PeteLong

101 Comments

I tried your work around, but it only gives me a different error. Is it possible that something more needs to be changed? Thanks

What Error did you get?

Fixed the issue immediately. Thanks

2018 and this advice is still good. Fixed my problem too. Thanks!

nice it works and solve the issues…

Worked for me, 2019

2020 still working !! I fixed my problem too.

End of 2020, and this still works to get me on legacy systems.

Is it possible you forgot a comma , after typing in hmac-sha2-256? Because that’s what I did at first try 😛

Thanks a lot for this. Helped me straight away.

No Probs – Glad to help рџ™‚ P

Still perfect.
Thanks For all.

Thanks for this.Work just as described!

Worked like a charm – Thanks!

It Works! Thanks

It didn’t like me allowing that line. It kept throwing up a new error, though to be fair, my line was longer and looked different.

However, putting the pound sign back and just adding that bit to the bottom worked straight away.

Thanks for the help.

Using all 3 changes will invalidate all host-keys in ‘known_hosts’.
Only the last line was actually needed for me: KexAlgorithms diffie-hellman-group1-sha1

With the caveat that this will force all ssh negotiations down to this less secure protocol.

A better option is to leave /etc/ssh/ssh_config alone alltogether, and create

/.ssh/config in your home-dir (alongside the known_hosts file)
In

/.ssh/config create an entry as follows for the equipment that use this key-exchange. Use as identification the name or ip you actually use on your commandline. (i.e. use ‘192.168.0.1’ or ‘firewall’ if you use ‘ssh 192.168.0.1’ or ‘ssh firewall’)

#force key exchange:
host 192.168.0.1 firewall.local firewall
KexAlgorithms diffie-hellman-group1-sha1

That worked also. Thanks!

This is great. I updated my Mac to 10.13.6 on 12/26/2018 and both my SSH and Sublime Text SFTP stopped working. (But my Cyberduck SFTP and Microsoft Remote Desktop continued to work.)

Using the steps in the initial post didn’t work for me. It resulted in an alert that I would be open to a “Man in the Middle” attack and it didn’t allow me to continue.

However, this comment helped me fix this issue. Now my SSH and Sublime Text SFTP work by creating a

/.ssh/config file in my local user folder and adding the lines at the end of the file. (Note: 999.999.9.9 is the IP address of the remote server you want to log into.)

# force key exchange:
host 999.999.9.9 firewall.local firewall
KexAlgorithms diffie-hellman-group1-sha1

Thanks a lot, this worked a treat for me. : )

Источник

Michael Stenberg

SSH fails with “no matching mac found”

So interesting error today. When trying to login to a system via SSH remotely after an upgrade (presumably due to updates to the code/security settings); I was getting errors like the below output:

From the above the SSH connection was failing. As a result; the general option to review this or why is to then go through the ssh -vvv output tests from my last article below.

From there; and using the output for the connectivity; we can then use the ssh -vvv IP_HERE to check/test the connection from the client machine (assuming this is from a Linux client).

From there; we have the output below:

From there; we can break this down in a few pieces of information.

For starters we have the very start of the output with:

This helps to confirm the OpenSSH is version 4.3p2 on the system and further below we have the destination system’s version:

And from there; we have the OpenSSH 6.6.1 version on the system. This is at least preliminarily the first red flag. The remote system is on a much newer code version and the machine I was trying to SSH from had a significantly older SSH version that couldn’t communicate/match the HMACs between the two systems (this could end up being ciphers, key algorithms, bit length or other various flags).

In a preliminary sense, the most likely fix would be to update the OpenSSH on the system that has the problem authenticating (or an operating system update). If unsure of the impact to updating the OpenSSH library; then you can further check what options the remote system has and if it can enable a matching protocol.

From the earlier output we then have the output below which shows the hmacs the client has available to use:

The next step to check this is to go to the remote machine we had failures to login to. To do this, we can try an updated SSH program, another machine, KIPMI, RMM or Console through a hypervisor or locally. In either case once logged in; we can then run a similar test with the SSH connection.

To do this you can run: sshd -vvv localhost and you’ll get output like before and we’ll then get the list of hmacs from the system hosting the SSHD service.

With the sent section from the same destination machine, you can see the entire list of all available hmacs (unless restricted in the configuration).

Now, given that output we have the listed hmacs below from the client, current SSHD service and destination. I purposely left them identified across the lines currently so we can see which hmacs in red would potentially work.

Source HMACS	Destination HMACs	All Possible HMACs on Destination
hmac-md5-etm@openssh.com
hmac-sha1-etm@openssh.com
umac-64-etm@openssh.com
umac-128-etm@openssh.com	umac-128-etm@openssh.com
hmac-sha2-256-etm@openssh.com	hmac-sha2-256-etm@openssh.com
hmac-sha2-512-etm@openssh.com	hmac-sha2-512-etm@openssh.com
hmac-ripemd160-etm@openssh.com
hmac-sha1-96-etm@openssh.com
hmac-md5-96-etm@openssh.com
hmac-md5,hmac-sha1
umac-64@openssh.com
umac-128@openssh.com	umac-128@openssh.com
hmac-sha2-256	hmac-sha2-256
hmac-sha2-512	hmac-sha2-512
hmac-ripemd160	hmac-ripemd160
hmac-ripemd160@openssh.com	hmac-ripemd160@openssh.com
hmac-sha1-96	hmac-sha1-96
hmac-md5-96	hmac-md5-96
hmac-md5
hmac-sha1

Now, given the above, we have the lists:

Sent hmacs:

Available hmacs:

hmac-sha2-512-etm@openssh.com
hmac-sha2-512
hmac-sha2-256-etm@openssh.com
hmac-sha2-256
umac-128-etm@openssh.com
umac-128@openssh.com

All hmacs on Avamar grid:

hmac-md5-etm@openssh.com
hmac-sha1-etm@openssh.com
umac-64-etm@openssh.com
umac-128-etm@openssh.com
hmac-sha2-256-etm@openssh.com
hmac-sha2-512-etm@openssh.com
hmac-ripemd160-etm@openssh.com
hmac-sha1-96-etm@openssh.com
hmac-md5-96-etm@openssh.com
hmac-md5,hmac-sha1
umac-64@openssh.com
umac-128@openssh.com
hmac-sha2-256
hmac-sha2-512
hmac-ripemd160
hmac-ripemd160@openssh.com
hmac-sha1-96
hmac-md5-96

Now final step is to then take the few matching hmacs and add it to the current list of available hmacs. We can then get a list of hmac like the output below.

Then with the above; you now have the updated list of HMACs. In referencing the prior Article I had on SSH/SSHD service configuration; you can then update the /etc/ssh/sshd_config file for the value: MACs to then specify the difference for the systems.
https://www.ssh.com/ssh/sshd_config/

In short note: we can then update the value for MACs below in the /etc/ssh/sshd_config and restart the SSHD service on the destination system.

And once you update the configuration file (you can use the vi editor); you can then run the below command from my earlier reference to make sure the config file is fine.

sshd -t

Once confirmed it’s okay; you can then run service sshd restart and then you should be able to SSH to the grid from the earlier system.

It’s important to note however, that the system changes here are ultimately attempting to give a newer system that is more secure to allow an old client/package system to authenticate. In the general case, it’s best to check into updating the OpenSSH library/package on the client system but above is a general example of how you can compare the hmacs, or use similar steps on the ciphers or key algorithms due to this mismatchn.

Источник