Mostly, it’s that the fun people aren’t smart and the smart people aren’t fun.
April 2017
SSH without passwords, an intuitive explanation
..because I’ve never seen one.
LOTS of things in computing are badly named. I’m going to fix that. Public/private keys are certainly one of them. Let’s focus on when using them to log in to remote servers with SSH without a password.
Here’s a good way to think about it: Forget the idea that you’re creating two keys. You’re creating a lock and a key for that lock.
The “public key” is NOT a key at all. It’s a *lock*. Think either a padlock or combination lock.
The private key IS actually a key, it’s the key or combination for that lock.
Let’s say you’re trying to connect to a server called “remote” from a computer at “home.” Thus, “home” needs a key, and “remote” needs a lock. Here’s what needs to be done.
1) create the key and the lock at “home” (which you do at the same time.)
ssh-keygen -t rsa
(all the defaults are fine)
2) Next, put your new lock on “remote.”
ssh-copy-id user@remote
Done. That’s the *necessary* stuff. Now, because you are disabling passwords, here are some things you’re going to want to think about that I’m not going to cover here:
– You’ve made a key that can open a server, so now whoever has that key can do so. Keep it safe. Think about permissions and who has access to “home.”
– If you have multiple clients and multiple servers? The analogy sort of fails a bit here, multiple locks on one server means EACH individual key can open it, you don’t need all of them. That being said, you still probably want to do it this way, i.e. make one key(pair) for each home/client, not for each server.