I recently, after accidentally overwriting the private key on one of the 3 computers on my LAN, decided to reimplement passwordless, key-pair authentication on these systems. The idea is that each of the three should be able to log in to any of the other two without using username/password credentials, but rather using key pairs. I got it successfully set up and working on one of them (machine1 in the examples below, which runs OpenSSL 1.1.0f, btw). Then I repeated, with appropriate modifications, the set-up process on the other two machines (which, incidentally, run LibreSSL 2.5.5).

Everything works as expected when I ssh from machine1 to either machine2 or machine3: no sort of password prompt. But when I try to ssh from either machine2 or machine3--either into machine1 or into each other--I get a password prompt like the following: This happens whether I rely on configuration data contained in ~/.ssh/config, or whether I issue a command like In other words, it looks like the problem machines will not complete the negotiation unless I enter the passwords I set up for their private keys. Same happens from machine3 when trying to ssh into either machine1 or machine2.

I'm trying to figure out what could be going on here. I've checked permissions and have tried re-entering public keys into the relevant authorized_keys files, but without success so far (still get password prompt). I've looked at sshd configuration options and all seems to be fine there. /etc/ssh/ssh_config on all machines looks to be identical (just looking over them by eye--did not run diff on them). Anyone have suggestions on what could be going on here or things I might try, in order to get passwordless negotiation operative? Perhaps I'm bumping into some incompatibilities between LibreSSL and OpenSSL here? I'll post some relevant data excerpts below.

Permissions on relevant files (not identical but very close and all within accepted parameters, as I understand them):
Sample session initiated from one of the two problem machines, where password is asked:
Content of ~/.ssh/config from one of the machines that's not working as needed (~/.ssh/config necessary owing to the fact that I have not used the default naming scheme for private keys):
Sample session from machine1, which works as desired:
Input will be appreciated.

When you created the keys you entered a passphrase which is a password that locks your private key. In a nutshell if someone gains physical access it will prevent them from accessing remote systems.

You can change the passphrase using the command
ssh-keygen -p

Yes, that's how it should work. Perhaps on machine1 you have ssh-agent setup so that you only need to enter the password once per session (or you have an empty passphrase on machine1's private key)? What does running on machine1 give you?

1 members found this post helpful.

Thanks for your input, ntubski and michaelk. Running that command on the machine where I can log in without being challenged for a password (the one that runs openssh) I get: Does that tell us anything? I don't think I set up an empty passphrase on machine1, but that's something I'll have to double-check.

Ok, you've put me onto the right path for identifying the user error here, ntubski and michaelk. This is a matter of user error/faulty memory, since ssh-keygen -yf machine1.rsa simply cat's the key's contents to stdout. To me that means that, contrary to my recollections about creating this key some years ago, I did, in fact, leave the passphrase empty. This has also helped me comprehend something important about the workings of key-negotiated ssh: namely, that it does not, without addition of other aids such as ssh-agent, allow one to forego entering passwords (if they've encrypted their private key with a passphrase). Since I have just now created the keys for machine2 and machine3, I do definitely remember setting passphrases for those. So, unmysterious mystery solved here. Thanks.

You may want to install the keychain package on each machine and create a .keychain directories in each home directory.

Thanks for the great suggestion, KenJackson. I'm currently testing it and it looks like this utility could serve my needs really well. Heck, I might even add a passphrase to the key I only recently realized had not been set up with one, if this utility continues to perform as well as it has been so far!