SSH to MacOS refuses public key authentication

Question

When I use ssh from a desktop linux machine to my MacOS laptop my public keys are rejected. I am able to connect using a password.

I have looked at several questions similar to this one (e.g. 522652, 1335103 and 471753) but none provide an applicable solution that I hadn't already tried.

Ordinarily at this point I would suspect that I didn't have the key in my agent or that the .ssh/authorized_keys file was not correct.

From the Mac laptop (target):

$ /bin/ls -ld ~/.ssh{,/authorized_keys}
drwx------  11 rik  staff   352 Oct 30 21:49 /Users/rik/.ssh
-rw-r--r--   1 rik  staff  1981 Oct 30 21:27 /Users/rik/.ssh/authorized_keys

From the linux desktop (source):

$ ssh-add -L
ssh-rsa AAAAB3[...]2akN7r /Users/rik/.ssh/id_rsa
ssh-rsa AAAAB3[...]Ig+DS3 /home/rik/.ssh/id_rsa

I have copied my authorized_keys to a raspberry pi and am able to ssh to that. Using ssh -vvv to each machine provides yet more clues.

To the raspberry pi:

...
debug1: rekey after 134217728 blocks
debug2: key: /home/rik/.ssh/id_rsa (0x55a9f8044310), agent
debug2: key: /Users/rik/.ssh/id_rsa (0x55a9f8049330), agent
debug2: key: /home/rik/.ssh/id_dsa ((nil))
debug2: key: /home/rik/.ssh/id_ecdsa ((nil))
debug2: key: /home/rik/.ssh/id_ed25519 ((nil))
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/rik/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
...

That's what I want to see (send 50, receive 60). Here is the same section when connecting to the Mac laptop:

...
debug1: rekey after 134217728 blocks
debug2: key: /home/rik/.ssh/id_rsa (0x5633631f5310), agent
debug2: key: /Users/rik/.ssh/id_rsa (0x5633631f6950), agent
debug2: key: /home/rik/.ssh/id_dsa ((nil))
debug2: key: /home/rik/.ssh/id_ecdsa ((nil))
debug2: key: /home/rik/.ssh/id_ed25519 ((nil))
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/rik/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Offering RSA public key: /Users/rik/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /home/rik/.ssh/id_dsa
...

This shows that the server is willing to accept publickey in general but not these specific keys. Again, I'm looking for a server side misconfiguration. On MacOS the configuration is in /private/etc/ssh.

$ grep '^[^#]' /private/etc/ssh/sshd_config
AuthorizedKeysFile  .ssh/authorized_keys
UsePAM yes
AcceptEnv LANG LC_*
Subsystem   sftp    /usr/libexec/sftp-server

I don't see anything wrong with that, but maybe the issue is there.

So next I looked at console output to see if something shows up there. In the console app I consistently get these 6 lines at each ssh attempt:

error   22:25:56.376189-0400    sshd    send failed: Invalid argument
error   22:25:56.376624-0400    sshd    send failed: Invalid argument
error   22:25:56.376676-0400    sshd    send failed: Invalid argument
error   22:25:56.400722-0400    kernel  Sandbox: sshd(1215) deny(1) mach-lookup com.apple.logd
error   22:25:56.400952-0400    kernel  Sandbox: sshd(1215) deny(1) mach-lookup com.apple.diagnosticd
error   22:25:56.689723-0400    kernel  Sandbox: com.apple.WebKit(37255) deny(1) mach-lookup com.apple.CoreDisplay.Notification

Seeing Sandbox in that and noticing a line from an older version of my sshd_config I copied it in and restarted ssh.

The line:

UsePrivilegeSeparation sandbox      # Default for new installations.

To restart ssh:

# launchctl stop com.openssh.sshd
# launchctl start com.openssh.sshd

This had no effect, so I reverted that configuration change. A search related to that led me here. I have confirmed that "Settings|Security & Privacy|Privacy|Full Disk Access|sshd-keygen-wrapper" is checked.

I recently upgraded to Catalina on my laptop. I have not used ssh to connect to it in quite some time, but I know that it has been working in the past.

I considered that Catalina might have become more restrictive about the types of public keys that it accepts. So I generated a fresh key into a different file, added the public key to my authorized_keys, added the key to my agent, verified that the agent had the new key, and tried again. If greater restrictions on the key type is the cause then they forgot to upgrade ssh-keygen defaults to match. (But I'm not going to say Apple wouldn't do something like that.)

I am at a loss to figure out how to get publickey authentication working again. Any suggestions would be welcome.

Answer 1

Thanks to Spiff for leading me in the right direction. The problem was permissions of my home directory, not the .ssh subdirectory.

I disabled sshd temporarily by unchecking Prefrences|Sharing|Remote Login. Then I ran /usr/sbin/sshd -d to get verbose output. It included this line:

Authentication refused: bad ownership or modes for directory /Users/rik

So I changed the permission to 755 and it now works.

Thanks again to Spiff.

Answer 2

I saw this same error message and tried the permissions angle to no effect. The problem wound up being that my .ssh was a symlink. I removed the symlink and moved the .ssh folder back into ~ and restarted sshd to get it working again.

The steps for troubleshooting were:

1. unload sshd sudo launchctl unload /System/Library/LaunchDaemons/ssh.plist

2. start sshd from the command line sudo /usr/sbin/sshd -d

3. try to connect ssh thehost

4. Observe the output of the daemon:

   debug1: sshd version OpenSSH_7.9, LibreSSL 2.7.3
   ...
   Authentication refused: bad ownership or modes for directory /Wherever
   ...
   Failed publickey for user from ipaddr port xxxxx ssh2: RSA SHA256:some
   ...
   

5. rm .ssh && mv wherever/.ssh ~/.ssh

6. stop the daemon CTRL-C

7. restart the daemon sudo /usr/sbin/sshd -d

8. etc.

9. When things are hunky dory again, reload sshd sudo launchctl load /System/Library/LaunchDaemons/ssh.plist

Answer 3

Typical Mac Troubleshooting technique...did you enable and disable remote management? I have a similar problem I cannot resolve with VNC (which is loosely associated with SSH tunnels). The VNC password will not allow a connection but the using Username and Password does.

I also wonder if this is some security restriction.

Answer 4

I was on Windows so maybe someone will find this helpful as I was running into a very similar issue trying to ssh into a windows computer from my macbook. ssh-copy-id doesn't work in this situation and I had already tried all the permission checks and quadruple checked the public/private keys were where they should be.

The sshd debug tip was helpful and I was running into an issue where when the Public Key Auth was working when in debug mode using the following powershell commands

Stop-service sshd
C:\Windows\System32\OpenSSH\sshd.exe -d

**In debug mode, it will only allow one connection and then stop after client disconnects

But wouldn't work while running as a service. That led me to check the Windows Services and lo and behold, the "OpenSSH Authentication Agent" service was disabled. I changed it to Automatic and started that service which fixed the problem. Sheesh don't know when, why or who thought it was a good idea to disable that but I guess 4 hours spent on this ended in triumph =_=.