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

Posted on Feb 26, 2025 11:35 AM

I'm posting this just in case anyone else is still running into this issue. I had the exact same error as everyone else in the thread on a new MacBook Pro running Sequoia. I tried the fixes suggested in this thread but none worked.


I did discover that when I executed:


sshd -T


I would get the following error:


/etc/ssh/sshd_config.d/101-authorized-keys.conf: No such file or directory


Checking the file with `ls`, I was able to determine that the file was a symlink to:


/etc/static/ssh/sshd_config.d/101-authorized_keys.conf


but that the symlink target did not exist. I deleted the broken symlink (`rm /etc/ssh/sshd_config.d/101-authorized-keys.conf`), restarted SSH and now I can connect to the new laptop.

29 replies

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

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



Feb 6, 2025 8:25 AM in response to FdeBrouwer

Similar issues here however I can connect, albeit breifly.


debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Thu Feb  6 15:18:00 2025
machine@mba ~ % debug3: send packet: type 1
client_loop: send disconnect: Broken pipe


I get a shell prompt, can hit CR a maximum of 2 times, at that point it becomes unresponsive and then eventually disconnects. This only works if I pass the option to use a password on the ssh command.


This is a brand new machine, to replace an old broken one. I need ssh access, desperate for a solution.


This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

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.