You can make a difference in the Apple Support Community!

When you sign up with your Apple Account, you can provide valuable feedback to other community members by upvoting helpful replies and User Tips.

User profile for user: FdeBrouwer
FdeBrouwer Author
User level: Level 1
24 points

After upgrading to Sequoia MacOS 15.0 cannot connect to it via SSH

After upgrading from Sonoma (MacOS 14) to Sequoia (MacOS 15) I was unable to connect to this Mac via SSH. I discovered the SSHD process has moved behind a tcpwrapper process. Most likely due to this change the key negotiations are missing while connecting via an Ethernet/Wifi interface resulting in no successful SSH connection to this upgraded Mac. When the connection is made on that Mac to the localhost/loopback-interface the negotiation is successful and a SSH-session can be established; so SSHD itself is working.


This is for me a very serious bug.


Please advice.


\



Some technical troubleshooting:


While performing basic tests the Mac running on MacOS 15 is misbehaving. A normal SSH connection fails before kex_exchange_identification and the Mac resets the session. The second try is just disconnected and not even showing the SSHD-version while connecting to an Ethernet/Wifi interface. The third try is presenting properly the SSHD-version on the localhost/loopback-interface address...


** connection to MacOS 15 / upgraded Mac:

MacOS15:~ fred$ ssh 10.0.0.166
kex_exchange_identification: read: Connection reset by peer   <-- the outside interface
Connection reset by 10.0.0.166 port 22


MacOS15:~ fred$ telnet 10.0.0.166 22 
Trying 10.0.0.166...
Connected to 10.0.0.166.
Escape character is '^]'.                    <-- after connection imediately kills the session
Connection closed by foreign host.


MacOS15:~ fred$ telnet 127.0.0.1  22
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
SSH-2.0-OpenSSH_9.8                         <-- sucessful connection, incl. version

Invalid SSH identification string.          <-- just enter to stop the negotiating...
Connection closed by foreign host.




While searching on internet for troubleshooting this connection I was pointed to this nmap tool. The first try is to receive the negotiations on the Ethernet interface and where none are returned. The second try is receiving the negotiation parameters via the loopback interface; and that is successful. The third try is receiving the negotiation parameters successfully from a Mac with MacOS 14. That version is not using a tcpwrapper.


** connection to MacOS 15 / upgraded Mac:

MacOS15:~ fred$ nmap   --script ssh2-enum-algos -sV -p 22  10.0.0.166
Starting Nmap 7.95 ( https://nmap.org ) at 2024-09-18 17:51 CEST
Nmap scan report for MacOS15 (10.0.0.166)
Host is up (0.00021s latency).

PORT   STATE SERVICE    VERSION
22/tcp open  tcpwrapped                          <-- tcpwrapped ??

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 0.87 seconds


MacOS15:~ fred$ nmap   --script ssh2-enum-algos -sV -p 22  localhost 
Starting Nmap 7.95 ( https://nmap.org ) at 2024-09-18 17:51 CEST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000096s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.8 (protocol 2.0)             <-- not tcpwrapped !!
| ssh2-enum-algos: 
|   kex_algorithms: (12)
|       sntrup761x25519-sha512@openssh.com
|       curve25519-sha256
|       curve25519-sha256@libssh.org
|       ecdh-sha2-nistp256
|       ecdh-sha2-nistp384
|       ecdh-sha2-nistp521
|       diffie-hellman-group-exchange-sha256
|       diffie-hellman-group16-sha512
|       diffie-hellman-group18-sha512
|       diffie-hellman-group14-sha256
|       ext-info-s
|       kex-strict-s-v00@openssh.com
|   server_host_key_algorithms: (4)
|       rsa-sha2-512
|       rsa-sha2-256
|       ecdsa-sha2-nistp256
|       ssh-ed25519
|   encryption_algorithms: (6)
|       chacha20-poly1305@openssh.com
|       aes128-ctr
|       aes192-ctr
|       aes256-ctr
|       aes128-gcm@openssh.com
|       aes256-gcm@openssh.com
|   mac_algorithms: (10)
|       umac-64-etm@openssh.com
|       umac-128-etm@openssh.com
|       hmac-sha2-256-etm@openssh.com
|       hmac-sha2-512-etm@openssh.com
|       hmac-sha1-etm@openssh.com
|       umac-64@openssh.com
|       umac-128@openssh.com
|       hmac-sha2-256
|       hmac-sha2-512
|       hmac-sha1
|   compression_algorithms: (2)
|       none
|_      zlib@openssh.com

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 0.32 seconds



** connection to MacOS 14 / not yet upgraded Mac:

MacOS15:~ fred$ nmap   --script ssh2-enum-algos -sV -p 22 10.0.0.192   
Starting Nmap 7.95 ( https://nmap.org ) at 2024-09-18 18:10 CEST
Nmap scan report for MacOS14 (10.0.0.192)
Host is up (0.00033s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.7 (protocol 2.0)       <-- not tcpwrapped !!
| ssh2-enum-algos: 
|   kex_algorithms: (12)
|       sntrup761x25519-sha512@openssh.com
|       curve25519-sha256
|       curve25519-sha256@libssh.org
|       ecdh-sha2-nistp256
|       ecdh-sha2-nistp384
|       ecdh-sha2-nistp521
|       diffie-hellman-group-exchange-sha256
...etc...




MacBook Pro 16″, macOS 15.0

Posted on Sep 18, 2024 9:23 AM

Reply
Question marked as Top-ranking reply
User profile for user: liubomyr144
liubomyr144
User level: Level 1
14 points

Posted on Oct 4, 2024 2:59 AM

I think it was fixed in 15.0.1. My test macbook connects via ssh with the firewall enabled after the update. I'm additionally testing it on other macbooks

View in context
23 replies
User profile for user: FdeBrouwer
FdeBrouwer Author
User level: Level 1
24 points

Sep 19, 2024 7:13 AM in response to Derek92

FYI: I have a company MacBook and FireWall disabling is not allowed...

Thanks for pointing this out; I will check the configuration with my IT-department.



However it's strange... Although the FireWall is enabled the TCP-session gets established; i.e. 3-way handshake is successful and the session is immediately stopped/reset by the MacOS15 Mac; see the tcpdump below:

    • De initial 3-way handshake is working; see flags :: [S] -> [S.] -> [.]
    • The reset flag cam from MacOS15, see flags :: [R.]
    • MacOS15 IP=10.0.0.166 / MacOS14 IP=10.0.0.192


MacOS14:~ fred$ sudo tcpdump -n port 22
tcpdump: data link type PKTAP
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on pktap, link-type PKTAP (Apple DLT_PKTAP), snapshot length 524288 bytes
16:02:14.334652 IP 10.0.0.192.49514 > 10.0.0.166.22: Flags [S], seq 219563245, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 291445944 ecr 0,sackOK,eol], length 0
16:02:14.336804 IP 10.0.0.166.22 > 10.0.0.192.49514: Flags [S.], seq 4033135703, ack 219563246, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 3618246782 ecr 291445944,sackOK,eol], length 0
16:02:14.336850 IP 10.0.0.192.49514 > 10.0.0.166.22: Flags [.], ack 1, win 2058, options [nop,nop,TS val 291445946 ecr 3618246782], length 0
16:02:14.337953 IP 10.0.0.192.49514 > 10.0.0.166.22: Flags [P.], seq 1:22, ack 1, win 2058, options [nop,nop,TS val 291445947 ecr 3618246782], length 21: SSH: SSH-2.0-OpenSSH_9.7
16:02:14.338297 IP 10.0.0.166.22 > 10.0.0.192.49514: Flags [.], ack 1, win 2058, options [nop,nop,TS val 3618246784 ecr 291445946], length 0
16:02:14.339649 IP 10.0.0.166.22 > 10.0.0.192.49514: Flags [.], ack 22, win 2058, options [nop,nop,TS val 3618246785 ecr 291445947], length 0
16:02:14.439428 IP 10.0.0.166.22 > 10.0.0.192.49514: Flags [R.], seq 1, ack 22, win 2058, length 0



Reply
User profile for user: yue106
yue106
User level: Level 1
20 points

Sep 27, 2024 4:49 AM in response to FdeBrouwer

I have this problem also with upgrade or new install to MacOS 15.0.

The reason or solution is, you have to use

ssh -o PreferredAuthentications=password hostIP -l userXX ( or userXX@hostIP)


and after you can then copy your pubkey to ~/.ssh/authorized_keys on Mac 15.0 you can use

ssh userXX@hostIP


I have try a little in /etc/ssh/sshd_conf, no success. I have to use the above workrounds.


Reply
User profile for user: freezerdev
freezerdev
User level: Level 1
8 points

Sep 23, 2024 3:36 PM in response to FdeBrouwer

It sounds like I'm having a similar issue. I have a MacMini I run as a headless server, connect to it remotely using both SSH and VNC. Last week I upgraded to Sequoia and both SSH and VNC stopped working. I did find a "workaround" When I power up the MacMini, I cannot connect remotely through any means. But if I connect a physical keyboard to the machine and login locally, then from that moment on I can connect using SSH and VNC. So the act of logging in locally once "fixes" SSH and VNC, at least until the machine is rebooted.


Apple must fix this. I'm lucky in that I can connect a keyboard and login locally each time I power up this machine. Can you imaging someone running this as a headless server in a datacenter or server room!?!

Reply
User profile for user: plughxyzzyfee
plughxyzzyfee
User level: Level 1
8 points

Oct 2, 2024 7:07 PM in response to FdeBrouwer

What just worked for me is:

  1. turn off the remote access in System-settings|General|Sharing
  2. run 'su Administrator' in a terminal
  3. run 'sudo visudo /private/etc/sudoers' and allow admin to use sudo by uncommenting the line around line 60 (this may not be strictly necessary but since I did it, its here).
  4. run 'sudo /usr/sbin/sshd'

At this point you can test if you can log in (ssh user@target) from another machine.


HTH


Reply
User profile for user: Guy Mccusker
Guy Mccusker
User level: Level 1
9 points

Sep 28, 2024 4:07 AM in response to yue106

For what it's worth, this approach of insisting on password authentication did not resolve the issue for me. My machine is behaving exactly as in the OP of this thread, same results from tcpdump.


If I switch off the firewall, ssh works as it should. But I am not allowed to leave the firewall disabled so I would love a resolution to this issue.


There are content filters running on my machine: Microsoft Defender and Crowdstrike Falcon. I am not able to disable them but I wonder if they might be part of the issue?

Reply
User profile for user: lux_150
lux_150
User level: Level 1
8 points

Sep 30, 2024 11:42 AM in response to lux_150

Until the problem is confirmed by Apple... I think it works when I disable the firewall.


Other than that, it seems to block the connection depending on the presence or absence of an app registered in the "local network".


But the route to disable the firewall is not normal... I think it's just a way to wait for quick confirmation.

Reply
User profile for user: Monty443
Monty443
User level: Level 1
8 points

Oct 28, 2024 10:56 AM in response to FdeBrouwer

For me the fix was simple, the Sequoia update overwrote the /etc/services file and in so doing changed the custom set ssh UDP and TCP port back to default port 22. Really annoying as I had no physical access to the machine when it updated and so had to travel to fix it. The future proof fix for me is making the file immutable with 'sudo chflags simmutable /etc/services' to prevent it being overwritten by future updates. This might not be the fix everyone's looking for but it was the one thing that fixed this problem for me since updating.


Details:

MBA - macOS 15.1

Mac mini - macOS 15.1

Firewall was on for both

no 3rd party firewall was active or installed on both machines

Reply

After upgrading to Sequoia MacOS 15.0 cannot connect to it via SSH

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.
Learn more Sign up