I have a M1 Mac mini that I use to back up several Macs. I log in via ssh. Since I upgraded to Sequoia I can not ssh into the mini if the firewall in on. I made sure the firewall rule allows ssh-keygen-wrapper. If I turn off the firewall ssh works fine. What am I missing.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
MacOS Sequoia builtin firewall does not allow SSH login
- Thread starter dimme
- Start date
- Sort by reaction score
I'm having firewall issues with SSH as well, but my problem isn't quite the same:
From my Mac, I ssh into a local server running in my LAN. After a few minutes I get this error:
I can trigger it by ssh'ing into pretty much any server or computer on my network and then executing a command like:
within 10 - 30 seconds, the connection drops with the error above.
Happens with IPv4 and IPv6. Happens with Terminal and iTerm apps.
Disabling the firewall fixes the issue.
From my Mac, I ssh into a local server running in my LAN. After a few minutes I get this error:
Bad packet length 2489765067.
ssh_dispatch_run_fatal: Connection to 192.168.30.2 port 22: Connection corruptedI can trigger it by ssh'ing into pretty much any server or computer on my network and then executing a command like:
ping google.comwithin 10 - 30 seconds, the connection drops with the error above.
Happens with IPv4 and IPv6. Happens with Terminal and iTerm apps.
Disabling the firewall fixes the issue.
Hmmm, I'm not seeing this issue. I'm using the SecureCRT app to SSH out to my home server. The firewall is enabled on my MBP. I'm not having any drops or other weirdness.
Firewall is bugged since the previous version of macOS as well. If you switch it off it may still be running. They if you switch it on, just maybe you will disable it. There is no way to predict it sometimes.
There's another thread about firewall problems on here somewhere. It looks like it's a bit of a mess. I can't get apps to communicate with each other via UDP ports unless I disable the firewall.
The Firewall may be part of the trouble, but at least some of the disconnections above are likely due to macOS changing the MAC address of the Wi-Fi interface. By default Sequoia "rotates" the Wi-Fi MAC (media access control) address at frequent intervals.
This is set in System Settings > Wi-Fi > Details... > Private Wi-Fi address. This can be:
Off - it will use the MAC address in the Wi-Fi hardware,
Fixed - it will use a pseudo-random MAC address but keep it the same for that network,
Rotating - it will change frequently.
The trouble with rotating is that a change of MAC address will mess with a) DHCP and IP address and b) the ARP cache on connected devices.
Make sure it is set to Off or Fixed. You will now get a little Privacy Warning triangle - ignore it. The "Learn more..." link doesn't mention the "Private Wi-Fi address" setting.
Apple has not fully thought through the implications of "rotating".
This is set in System Settings > Wi-Fi > Details... > Private Wi-Fi address. This can be:
Off - it will use the MAC address in the Wi-Fi hardware,
Fixed - it will use a pseudo-random MAC address but keep it the same for that network,
Rotating - it will change frequently.
The trouble with rotating is that a change of MAC address will mess with a) DHCP and IP address and b) the ARP cache on connected devices.
Make sure it is set to Off or Fixed. You will now get a little Privacy Warning triangle - ignore it. The "Learn more..." link doesn't mention the "Private Wi-Fi address" setting.
Apple has not fully thought through the implications of "rotating".
Are you certain it rotates MAC address for an active connection as opposed to just randomising it when connecting?
MAC addresses are not a per connection property.
It's the hardware address for the interface and, in simple scenarios, a one-to-one pairing with an IP address(any IP address must resolve to exactly one and only one MAC address - though multiple IPs can resolve to same MAC).
When a MAC address changes, it changes for all connections on that interface. All other systems will update their ARP IP->MAC mapping. How this will affect active connections(on various OSs including routers with custom network drivers + hardware accel off-loading) is hard to predict as it's not considered "normal" for IP->MAC mapping to change on a regular basis.
A bit of experimentation shows that it is not changed frequently - even following reboots. So I now think it is not likely to be big issue.
This is what worries me.
Not to be too repetitive, but I have an M2 MBA and an Intel iMac (2019). I've always been able to log on to one from the other using public key authentication. Obviously, remote login is enabled on both. Not so obviously, the firewall is disabled on both.
I can no longer ssh into either machine from the other Mac. This is what a verbose login looks like:
I can log on from either Mac to a Raspberry Pi:
And, I can login to the M2 MBA Mac from the Pi:
But not to the Intel iMac from the same Pi:
Note that the firewall is disabled on the Intel iMac, so there should be no problem with port 22.
And, at this point, I'm stuck.
I can no longer ssh into either machine from the other Mac. This is what a verbose login looks like:
Code:
Fifteen:~ mnewman$ ssh -vv sellotape
OpenSSH_9.8p1, LibreSSL 3.3.6
debug1: Reading configuration data /Users/mnewman/.ssh/config
debug1: /Users/mnewman/.ssh/config line 3: Applying options for *
debug1: /Users/mnewman/.ssh/config line 37: Applying options for sellotape
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to sellotape port 22.I can log on from either Mac to a Raspberry Pi:
Code:
Fifteen:~ mnewman$ ssh raspsky
Linux raspsky 5.10.103-v7l+ #1529 SMP Tue Mar 8 12:24:00 GMT 2022 armv7l
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Oct 2 13:44:30 2024 from 192.168.0.78
pi@raspsky:~/webcam $And, I can login to the M2 MBA Mac from the Pi:
Code:
pi@raspsky:~/webcam Me$ ssh mnewman@fifteen
Last login: Wed Oct 2 13:44:54 2024 from 192.168.0.65
Fifteen:~ mnewman$But not to the Intel iMac from the same Pi:
Code:
pi@raspsky:~/webcam $ ssh -vv mnewman@sellotape
OpenSSH_7.9p1 Raspbian-10+deb10u4, OpenSSL 1.1.1n 15 Mar 2022
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "sellotape" port 22
debug2: ssh_connect_direct
debug1: Connecting to sellotape [192.168.0.75] port 22.
debug1: connect to address 192.168.0.75 port 22: No route to host
ssh: connect to host sellotape port 22: No route to hostNote that the firewall is disabled on the Intel iMac, so there should be no problem with port 22.
And, at this point, I'm stuck.
Guess what works?
Code:
Fifteen:~ mnewman$ ssh sellotape.local
Last login: Wed Oct 2 14:19:51 2024 from fe80::4d5:db02:81d6:74d5%en1
Sellotape:~ mnewman$
Sellotape:~ mnewman$ ssh fifteen.local
Last login: Wed Oct 2 14:21:20 2024 from fe80::450:cba3:1b05:cffa%en0
Fifteen:~ mnewman$
Hey, the OP question got immediately hijacked by a different ssh problem.
Has anyone else seen / fixed / identified the OP issue? I also cannot ssh into my Mac (running Sequioa 15.0.1) via name.local.
Doing so works fine via direct IP, dns forward, and tailscale. It *only* fails via name.local. (Yes, the apps have local network access.)
Has anyone else seen / fixed / identified the OP issue? I also cannot ssh into my Mac (running Sequioa 15.0.1) via name.local.
Doing so works fine via direct IP, dns forward, and tailscale. It *only* fails via name.local. (Yes, the apps have local network access.)
15.0.1 is still broken for me across quite a few machines.
- SSH and SMB connections keep failing. Disabling the firewall is a workaround but not a great one.
- 15.0.1 is now interrupting and messing with VPN connections which didn't happen in 15.0.
- The network framework seems now to be causing application lockups such as Cyberduck now frequently freezes, needing a force quit. This didn't happen in 15.0.
- My Ubuntu servers UFW firewall are reporting ddos attempts from the Mac IP addresses. For some reason the machines are now making rapid and mass connections to the servers when a single attempt is made. This is causing the Ubuntu firewall to think its being attacked.
- SSH and SMB connections keep failing. Disabling the firewall is a workaround but not a great one.
- 15.0.1 is now interrupting and messing with VPN connections which didn't happen in 15.0.
- The network framework seems now to be causing application lockups such as Cyberduck now frequently freezes, needing a force quit. This didn't happen in 15.0.
- My Ubuntu servers UFW firewall are reporting ddos attempts from the Mac IP addresses. For some reason the machines are now making rapid and mass connections to the servers when a single attempt is made. This is causing the Ubuntu firewall to think its being attacked.
I had this issue. It was indeed annoying. You don't need to delete the firewall or change anything with the MAC-address.
You can just add ssh to the allow filter for the firewall. This solution worked for me. Credit goes to Okin19 on r/macOS.
# Add SSH explicitly
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /usr/bin/ssh
# if you’re using Homebrew’s SSH:
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /opt/homebrew/bin/ssh
You can just add ssh to the allow filter for the firewall. This solution worked for me. Credit goes to Okin19 on r/macOS.
# Add SSH explicitly
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /usr/bin/ssh
# if you’re using Homebrew’s SSH:
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /opt/homebrew/bin/ssh