7 Connecting Securely with SSH
SSH – short for Secure (Socket) Shell – facilitates secure two-way communication between your computer and the command line on a server. Using SSH, you can directly access the command line on a remote host like a server.
When you’re interacting with a server using SSH, you’ll have a terminal open on your laptop, but all the commands are actually running off on the remote server. This means that you’ll use the commands of your laptop’s operating system to start the SSH session, but then will switch to using Linux commands on the server itself.
In this chapter, you’ll learn generally what SSH is and how to use it from your command line.
7.1 How SSH works
SSH allows you to directly access the command line on a remote host from anywhere that can connect to it over a network. It is the main way to administer a server.
SSH works via the exchange of cryptographic keys. You will create an SSH key, which comes in two parts – the public key and the private key.
I believe the terms public key and private key are a little bit of a misnomer. The analogy to the real world is a little clearer by thinking of the private key as the key and the public key as the lock.
You’re the only one who has the key, but you can hand copies of the lock around so they can always verify that your key is the real one.
As the name might suggest, you keep the private key secret. The best practice is to never move it once it has been created. You can give the public key out to anywhere you might need to access using SSH. Popular targets include remote servers you’ll need to SSH into as well as remote git hosts, like GitHub.
SSH works on the basis of public key cryptography, which is really cool. It also defies common sense a little bit – it is a little strange that you create this two-part thing and it’s absolutely fine to hand one half around but really bad if you mix them up.
A short digression about the mathematics of public key cryptography may help clarify.
Public key cryptography relies on mathematical operations that are easy in one direction, but really hard to reverse. This means that if I’ve got the public key, it’s really hard to reverse-engineer the private key, but really easy to check that the private key is right if I’m given it up front.
An example of an operation like this is multiplying prime numbers together. Having a public key is just like being told a number – say \(91\). Even if you know it’s the product of two primes, it’ll probably take you a few moments to figure out the right primes are \(7\) and \(13\).
But if you already have \(91\) and I tell you that the right primes are \(7\) and \(13\), it’s super quick to check that those are indeed the right ones.
The biggest difference between multiplying \(7 * 13 = 91\) and modern encryption algorithms is the size of the number. Public key cryptography doesn’t use small numbers like 91. It uses numbers with 91 or 9,191 digits.
Modern encryption methods also use substantially more convoluted mathematical operations than simple multiplication – but the idea is completely the same, and prime numbers are equally important.
The point is that SSH public keys are very big numbers, so while someone could try to reverse-engineer the private keys by brute force, it’d take more time than we have left before the heat death of the universe at current computing speeds.
This is why you can give your public key to a server or service that you might not fully control. Someone who has your public key can verify that your private key is the one that fits that public key – but it’s basically impossible to reverse engineer the private key with the public key in hand.
However, it is totally possible to compromise the security of an SSH connection by being sloppy with your private keys. So while SSH is cyptographically super secure, the whole system is only as secure as you. Always keep your private keys securely in the place where they were created and share only the public keys.
7.2 Practical SSH usage
Before SSH will work, your keypair needs to be created and the public key needs to be shared. There are tons of guides online to creating an SSH key for your operating system – google one when you need it.
SSH has one of my favorite debugging modes.
If something’s not working when you try to connect, just add a -v to your command for verbose mode. If that’s not enough information, add another v for -vv, and even another!
Every v you add (up to 3) will make the output more verbose.
The way you register a keypair as valid on a server you control is by creating a user on that server and adding the public key to the end of the .ssh/authorized_keys file inside the user’s their home directory. More on server users and home directories in Chapter 11.
If you’re the server admin, you’ll have your users create their SSH keys, share the public keys with you, and you’ll put them into the right place on the server.
If you need to SSH from the server to another server or to a service that uses SSH, like GitHub, you’ll create another SSH key on the server and use that public key on the far end of the connection.
If you follow standard instructions for creating a key, it will use the default name, probably id_ed25519.1 I’d recommend sticking with the default name if you’ve only got one. This is because the ssh command will just use the keys you’ve created if they have the default name.
If you don’t want to use the default name for some reason, you can specify a particular key with the -i flag.
If you’re using SSH a lot on the same servers, I’d recommend setting up an SSH config file. You can include usernames and addresses in a config file so instead of typing ssh alexkgold@do4ds-lab.shop I can just type ssh lab.
A google search should return good instructions for setting up your SSH config when you get there.
7.3 Comprehension Questions
- Under what circumstances should you move or share your SSH private key?
- What is it about SSH public keys that makes them safe to share?
The pattern is
id_<encryption type>.ed25519is the standard SSH key encryption type as of this writing.↩︎