2

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.

  • 1
    Run sshd verbosely and see what it logs. – Spiff Oct 31 '19 at 15:14
  • @Spiff See the two output blocks right after "To the raspberry pi:" as well as the conclusions about those that immediately follow. The pi output was included to demonstrate the desired verbose output. – Rik Renich Oct 31 '19 at 17:31
  • 1
    I only see the verbose output from the ssh client. I was suggesting you need to look at the verbose output from sshd, (the ssh server process) on the Mac. – Spiff Oct 31 '19 at 18:32
  • @Spiff Excellent idea. Do you know how to do that? Is there a setting in sshd_conf? – Rik Renich Oct 31 '19 at 22:07
2

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.

  • Thanks for detailing how you resolved this - your approach enabled me to quickly debug an ssh config issue I'd had on one machine. – arcdale yesterday
0

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.

  • I tried all four combinations of enabling "Remote Login" and "Remote Management". The only change was as you might expect, unable to login when "Remote Login" is disabled and no change otherwise. – Rik Renich Oct 31 '19 at 14:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.