If you are doing a lot of stuff in Linux, a common need is to open a remote command-line on a remote system. For example, if you were connecting from your computer to a Raspberry Pi. The modern way to do this is to use Secure Shell (SSH). From a Linux or Mac machine, you’d typically do:
$ ssh jdoe@exampleserver
to connect as jdoe (a valid account on the remote, exampleserver). Normally, you’d then be prompted for jdoe’s password. However, a different way, and very secure alternative is to use SSH, using keys instead of the account password.
SSH uses Public Key Infrastructure (PKI) technologies, similar to how SSL/TLS (think, https:// websites) work. The idea is that you have a keypair. A mathematically-connected pair of keys. Whatever you encrypt with one, you can decrypt with the other. So, you take one side and call it (and treat it as) a private key. You take the other side of the keypair and you share with anyone/everyone – you call that your public key.
This is significant because at the beginning of an SSH handshake, the client already exchanges his/her public key with the server. Then, a key-exchange is done (typically for an AES256 key) using each others public key, then future traffic is encrypted/decrypted only with the AES key that each party knows. This is assuming that you can then authenticated with the users passwords too.
By the way, this more-secure PKI is only used to exchange a key because AES-256 encryption is is 4x to 29x faster than PKI!
Instead, you could just use that public key which they already provided, as proof that they are a trusted user. So, what you can do is for SSH, tell it that when people connect with this particular public key, then they should be allowed-in with no further prompting. Why is this good?
- The client doesn’t necessarily need to know the password. Access is based off of what you have, not what you know.
- It’s more convenient for the client because you just connect with no prompting.
- If the client has been compromised, the server can stop access by removing that public key from a file (~/.ssh/authorized_keys) and won’t necessarily need to change the password.
With all of that said, how do you actually do this?
How to set it up:
First, you’ll need a program called “ssh-copy-id”. Yes, you could accomplish the same thing with an SSH command, but I found this to be simpler! Anyhow, this is already installed on Ubuntu and many Debian-based systems. if it isn’t, you can run:
$ sudo apt-get install openssh-client
on MacOS X, you’d do:
$ brew install ssh-copy-id
Before we use that tool, if you haven’t done this already, take a minute to generate a strong keypair. Use a command like this:
$ ssh-keygen -t rsa -b 4096 -C jdoe@localmachinename
where “jdoe” is your local account name, and “localmachinename” is the name of your computer; the computer from which you are connecting. By default, this will create two files off of your home directory in ~/.ssh/ called “id_rsa” (this is your private key) and “id_rsa.pub” (this is your public key).
Now, instead of SSH’ing to the remote machine like normal, just run:
$ ssh-copy-id jdoe@remotemachine
where “jdoe” is the account on the remote machine, and “remotemachine” is the computer to which you want to connect. Here is a complete example:
as “rseder” running on “robuntu”, I copy my public key to account “pi” on “raspi02”. Then, immediately after: I SSH into raspi02 and I am no longer prompted for that password.
If you did this more than once or want to revoke someone’s access, that is granted on a per-user basis. Remember, we SSH doing a user@host. So, in the home directory of the target user on the remote system, there will be a .ssh folder with a authorized_keys file. There is one public key per line with your identity at the end (e.g. jdoe@exampleclient). Just remove the line from that file which corresponds to the client user access you wish to revoke.