Passwordless SSH into MacOS Ventura doesn't work

You can use this method to transfer the .pub key

ssh-copy-id -i ~/.ssh/id_ed25519.pub   user@remote.host 

Creating a passwordless ssh-keygen key

ssh-keygen -t ed25519 

 # Enter file in which to save the key (.../.ssh/id_ed25519):< accept default; just hit enter > 

 # Enter passphrase (empty for no passphrase): < leave blank; just hit enter > 

 # Enter same passphrase again:               < leave blank; just hit enter > 

Why is ed25519 recommended:

https://medium.com/risan/upgrade-your-ssh-key-to-ed25519-c6e8d60d3c54

NOTE: I am using passwordless keys on Ventura, and on older macOS, OS X, Mac OS X versions going back to Snow Leopard 10.6 (maybe even before).

I also use the same keys on my work Linux hosted development and test systems. Plus AIX and Solaris.

pts wrote:

…

Enter passphrase for key 'Users/[user]/.ssh/id_rsa':

To remove the passphrase (and thus also decrypt the private key) without re-generating the key pair…

ssh-keygen -p

Related: https://www.unixtutorial.org/changing-passphrase-to-your-ssh-private-key

pts wrote:

I don't follow this either. At that point that you refer to, when I simply press return (i.e., I don't enter any passphrase at all) then it skips to asking for the password for the remote machine (i.e., the very thing I'm trying to avoid). This is not at all intuitive... Why is it asking for a passphrase at that first step yet accepting nothing (except an empty return)?

Unix is not known for its consistency, nor its simplicity.

ssh works with a local private key, and a remote and public key, and often requires way too much manual setup for my own preference.

ssh can have a passphrase on the private key, and can encounter a password on the remote login when the remote public keys are not sent up correctly, when the local private or remote public key are not the expected format as expected by the local or remote system or the local private key or remote public key are not protected appropriately.

If a passphrase is set up on the private key, it will have to be specified on the ssh command, or the passphrase removed and the private key decrypted. I linked to how to remove the passphrase from the private key, if one has been set.

Differing from other implementations, macOS allows the ssh private key to be added to Keychain, as well:

https://apple.stackexchange.com/questions/48502/how-can-i-permanently-add-my-ssh-private-key-to-keychain-so-it-is-automatically#250572

When using ssh and it’s doing something unexpected, add -v, -vv, or -vvv to the ssh command to get some, or to get more, or to get extensive additional debugging information shown. Wading through that output takes time, amd some familiarity with how ssh works. But it is very useful for troubleshooting ssh connections.

DigitalOcean has an ssh intro here:

https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys

You set a password for the certificate. It’s asking for that password in order to use the certificate. You have to create a certificate without a password.

pts wrote:

I don't follow this either. At that point that you refer to, when I simply press return (i.e., I don't enter any passphrase at all) then it skips to asking for the password for the remote machine (i.e., the very thing I'm trying to avoid). This is not at all intuitive... Why is it asking for a passphrase at that first step yet accepting nothing (except an empty return)?

The passphrase is to protect the keys (encryption, I think). If you enter a password, it encrypts the key so you have to decrypt to use. If You don't enter a passphrase, you don't need to enter it to use the key.

It asks in case you want one. Unix tries to remove useless steps. The other method would be:

Do you want a passphrase?

Yes, ok, please enter.

Here are your protected keys.

No passphrase, here's your unprotect keys.

With the current implementation it asks for a passphrase, processes it if you enter one, and doesn't encrypt if you don't. Much more efficient.