Firewall Issues - ssh_dispatch_run_fatal errors during SSH

So with respect, security is a layered architecture. The default MacOS firewall, while less than optimal for many reasons and uses; still DOES block by default most inbound connections at a minimum. I too personally use Little Snitch as I want way more security than the default provides; however having this as a base doesn't hurt.

That being said, there's another issue here. Many companies REQUIRE that filter to be enabled as part of security profile; or other things are disallowed. So in those cases you're ****** if you do and ****** if you don't ;) I am probably gonna have to revert to a previous backup tonight to get back to functionality.

So with respect, security is a layered architecture. The default MacOS firewall, while less than optimal for many reasons and uses; still DOES block by default most inbound connections at a minimum. I too personally use Little Snitch as I want way more security than the default provides; however having this as a base doesn't hurt.

That being said, there's another issue here. Many companies REQUIRE the Firewall to be enabled as part of security profile; or other things are disallowed. So in those cases you're ****** if you do and ****** if you don't ;) I am probably gonna have to revert to a previous backup tonight to get back to functionality.

sandinak wrote:

The default MacOS firewall, while less than optimal for many reasons and uses; still DOES block by default most inbound connections at a minimum.

The default firewall configuration allows any built-in app, and any 3rd party signed app, to accept incoming connections. It doesn't block anything. In some versions, if you manually change settings to block software, it will just change it back to allow. But assuming you have a version that works, then it is only going to block local connections, like from your printer or other computers in your house. For the vast majority of users, no outside connection is going to make it past their modem in the first place.

That being said, there's another issue here. Many companies REQUIRE that filter to be enabled as part of security profile; or other things are disallowed. So in those cases you're ****** if you do and ****** if you don't ;) I am probably gonna have to revert to a previous backup tonight to get back to functionality.

This is a user-to-user support forum for consumer users. Companies typically have all kinds of specialized configurations and software that we don't have and can't support.

For those of you bypassing by disabling the firewall -- that's not a practical solution for enterprise users who either should not or cannot disable firewall. macOS developers, I hope you're tuned in to these discussions -- it's a huge blocker for those of us who rely on Mac as a developer's tool.

lolaunderthegate wrote:

For those of you bypassing by disabling the firewall -- that's not a practical solution for enterprise users who either should not or cannot disable firewall.

Just for clarification. I understand if you have some corporate policy that requires the firewall. You probably also have some corporate policy to install antivirus and key loggers. Corporate IT is hilariously incompetent.

But we don't work for your company. We can't fix those policies. All we can fix are your Mac problems.

I have contacted apple support seems like there is no fix at the moment which really sucks and is a complete and total blocker for any of use that need remote access to remote machines. This completely blocked me and made my mac a giant paper weight. I hope they fix this bug soon. Cant believe such a basic thing was not tested...

I came on to post a different question, but thought this post was potentially relevant.

I factory reset to Sonoma and upgraded to Sequoia yesterday. I before started adding anything, I was updating the settings, layouts, folders etc to make sure things are how I like it to be.

For some reason a few folders and items have been added to my shared folder - which I've never seen before. I don't think I've had anything in my shared folder before. (it might've always been there and that I wasn't observant/forgot)

So the new folder/items that have been put there are:

'/Users/Shared/Relocated Items/Configuration/private/etc/ssh.system_default'

Inside the ssh.system_default folder there is:

• crypto.conf symlink
• crypto/
  • apple.conf
  • fips.conf
• ssh_config.d/
  • 100-macos.conf
• sshd_config.d
  • 100-macos.conf
• moduli
• ssh_config
• sshd_config

Again, this could be absolutely fine/normal, but I was coming on here to ask if it was and saw this thread about ssh issues, so decided to message here first to see if maybe this is what's causing an issue for you?

@SamWantsYouToChill

that's pretty interesting.... but my ping times aren't that erratic. that's bonkers!

I just lose connection randomly from RDP or SSH.

thought it was my HUB at first but seems to coincide with the latest upgrade

I may abandon Mac soon, if what you're saying it true about it being there for ages !

Version 15.0.1 still has the same issue, and it's becoming really frustrating! Sometimes the problem occurs immediately after connecting to the server via SSH. I've also encountered some SSL issues.

I'm surprised Apple allowed this bug to persist in 15.0.1, especially since it was reported before the release of 15.0!

Upgraded to 15.0.1 this week on my work laptop (MBP 2020 Intel i5)

I've never had this issue before, but now I get it often, with messages like

Bad packet length 261593430.

ssh_dispatch_run_fatal: Connection to <ipaddress-removed> port 22: Connection corrupted

My issue may be somewhat different from this original issue posted here. I had a web page that would only open about 1/2 of the time (happened several times a day). After trying all settings I found another link from another user indicating it may be related to having both ethernet and WiFi on at the same time (service order has ethernet first). But after turning off WiFI no more web page loading issues for the last two days so I'm keeping my fingers crossed. Never had this issue prior to Sequoia 15.0.1

"I just updated to 15.1 and looks like the issue has been resolved already."

Don't celebrate just yet. You can't possibly know whether the issue is fixed this quickly. This issue is random and not easily reproducible, and even worse, it might be there but mild that it's not noticeable at times. You should wait weeks before deeming is fixed.

So, I upgraded to 15.1 today in the morning, and got the issue again a few hours later. Told you... don't celebrate way too early:

$ ping 192.168.1.1
64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=430.883 ms
Request timeout for icmp_seq 1
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1191.281 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=218.189 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.737 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.756 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.681 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=0.896 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=0.834 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=987.689 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=0.573 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=924.024 ms
64 bytes from 192.168.1.1: icmp_seq=11 ttl=64 time=43.525 ms
64 bytes from 192.168.1.1: icmp_seq=12 ttl=64 time=0.605 ms
64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=0.518 ms
64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=0.711 ms
64 bytes from 192.168.1.1: icmp_seq=15 ttl=64 time=0.736 ms
64 bytes from 192.168.1.1: icmp_seq=16 ttl=64 time=0.686 ms
64 bytes from 192.168.1.1: icmp_seq=17 ttl=64 time=0.666 ms
64 bytes from 192.168.1.1: icmp_seq=18 ttl=64 time=0.711 ms
64 bytes from 192.168.1.1: icmp_seq=19 ttl=64 time=663.760 ms
64 bytes from 192.168.1.1: icmp_seq=20 ttl=64 time=0.743 ms
64 bytes from 192.168.1.1: icmp_seq=21 ttl=64 time=0.752 ms
Request timeout for icmp_seq 23
64 bytes from 192.168.1.1: icmp_seq=22 ttl=64 time=2362.481 ms
64 bytes from 192.168.1.1: icmp_seq=23 ttl=64 time=1357.555 ms
64 bytes from 192.168.1.1: icmp_seq=24 ttl=64 time=350.827 ms
64 bytes from 192.168.1.1: icmp_seq=25 ttl=64 time=0.721 ms
64 bytes from 192.168.1.1: icmp_seq=26 ttl=64 time=0.798 ms
64 bytes from 192.168.1.1: icmp_seq=27 ttl=64 time=0.676 ms
64 bytes from 192.168.1.1: icmp_seq=28 ttl=64 time=0.782 ms

Turning off the firewall helped... but didn't completely fix the problem. We're still where we are. You may or may not get the issue based on the things I explained in my first post here.

I wasn't too hopeful because the release notes didn't contain any networking fixes. Square one again.

tgarons wrote:

The issue in this thread is ssh_dispatch_run_fatal errors during SSH. 15.1 fixes that.

No, it doesn't. You not facing it within a few hours doesn't mean it doesn't happen. Please stick to sound logic principles, and give it a few weeks at least. There's no way you could rule out the issue in one day. It doesn't help. Again, the internet is flooded with complaints about timeouts and connectivity, and everyone thinks it's fixed, until they get the issue again. The least we can do is be patient.

Quick update, I am member of an large company internal mailing list where we've been discussing this extensively. The new 15.1 does seem to improve the performance relative to this problem; but does NOT fix it. People are seeing issues over time that seem to mimic the existing behavior that's been problematic. I have more or less decided NOT to upgrade to 15 unless/until forced by my company; and for personal and stage use ( I work on traveling shows ) we will definitely NOT be upgrading until this issue is dealt with.

Love you Apple.. you know I do given how much buyin I have; but this is the line. We really REALLY need to hear this will be addressed long term. If I can't trust the system to have consistent networking on a closed network on stage moving low-mid level traffic .. I will have to move to other solutions. Thanks in advance