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

Question

Level 1

28 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

Answer 1

Top-ranking reply

dieselweasel

Level 1

4 points

Feb 26, 2025 11:35 AM in response to FdeBrouwer

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.

Reply

Answer 2

Dec 21, 2024 5:02 PM in response to FdeBrouwer

The bug is still present on 15.2, but I think I've just found the cause. I tried running sshd from terminal and got this:

debug1: sshd version OpenSSH_9.8, LibreSSL 3.3.6
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0664 for '/etc/ssh/ssh_host_rsa_key' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
debug1: Unable to load host key "/etc/ssh/ssh_host_rsa_key": bad permissions

I'll try to fix the permissions and edit this with the results.

Reply

Answer 3

Derek92

Level 1

42 points

Sep 19, 2024 6:26 AM in response to FdeBrouwer

I was having this issue too with Remote Desktop needing ssh to work. In the end, disabling the firewall fixed my ssh issue. I'm sure there's a way to add sshd to the exceptions list, but I haven't figured that out yet.

Reply

Answer 4

FdeBrouwer Author

Level 1

28 points

Sep 29, 2024 5:37 AM in response to Derek92

The force password authentication worked for me; using option: PubkeyAuthentication=no ...

FYI:

I have filed a bug-report for this issue: FB15296036

It includes also misbehaving DHCP-client in MacOS15...

Reply

Answer 5

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

Answer 6

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

What just worked for me is:

turn off the remote access in System-settings|General|Sharing
run 'su Administrator' in a terminal
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).
run 'sudo /usr/sbin/sshd'

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

HTH

Reply

Answer 7

Mikweb

Level 1

8 points

Oct 5, 2024 2:56 AM in response to FdeBrouwer

I solved by disabling “private wifi address” option

Reply

Answer 8

Oct 10, 2024 5:25 AM in response to liubomyr144

Updating to 15.0.1 also resolved this for me. Thank you for the heads up on that: it allowed me to nudge our system administrator to let me install this update sooner than it would normally become available.

Reply

Answer 9

Mikweb

Level 1

8 points

Oct 4, 2024 5:23 AM in response to Guy Mccusker

I solved by disabling “private wifi address” option

Reply

Answer 10

Nov 24, 2024 4:15 PM in response to FdeBrouwer

In the firewall settings, sshd-session has been set to block. Restore to allow.

Reply

Answer 11

Oct 4, 2024 4:12 AM in response to plughxyzzyfee

This also did not work for me :( The only thing that works so far is disabling the firewall.

Reply

Answer 12

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

Answer 13

Dec 21, 2024 5:24 PM in response to AlvaroBecerra

The bug is still present on 15.2, but I think I've just found the cause. I tried running sshd from terminal and got this:

debug1: sshd version OpenSSH_9.8, LibreSSL 3.3.6
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0664 for '/etc/ssh/ssh_host_rsa_key' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
debug1: Unable to load host key "/etc/ssh/ssh_host_rsa_key": bad permissions

I fixed it with:

$ sudo chown -R 600 /etc/ssh/*key

It will ask for your password. You have to deactivate and then reactivate Remote Login.

Reply

Answer 14

Oct 4, 2024 2:59 AM in response to FdeBrouwer

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

Reply

Answer 15

yue106

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