Full Stack for Front End Engineers Exercise 8: Creating an SSH Key
This course has been updated! We now recommend you take the Full Stack for Front-End Engineers, v3 course.
Transcript from the "Exercise 8: Creating an SSH Key" Lesson
>> Jem Young: So, let's make SSH Key back in your favorite tool, the command line. Go ahead, in that cd into the .ssh directory, is to save your time in the future so you don't move your key.
>> Speaker 2: Before you jump in that next command, you might wanna check and see if they already have a key that they're using.
>> Jem Young: That's true. Actually, no, we'll make a new key. Yeah, I don't wanna confuse anybody. I have a lot of keys, too, and I just, I'm not gonna make a new one cuz I have a lot of keys. If you already have an SH key, go ahead and feel free to use that.
>> Speaker 2: [INAUDIBLE] if they're already using it some place
>> Jem Young: Yeah, that's fine. Again, cuz that's the great thing about public key authentication is I can reuse my public key infinitely cuz I'm the only one that has the key to unlock that. So, it's a-
>> Speaker 2: What I'm saying is if they already have a public and private pair, and they share that public key, say, for example, to GitHub.
[00:00:58] Okay, and they overwrite it. They'll have to submit the new key to GitHub.
>> Jem Young: Yeah, definitely do not overwrite your current keys. [LAUGH]
>> Speaker 2: That's what I'm saying.
>> Jem Young: I got you, all right, so I'm gonna go through this. I'll make a new key myself. [LAUGH] Just kick everyone out of the server.
[00:01:18] All right.
>> Jem Young: So, I'm gonna see, this is a shortcut.
>> Speaker 3: Just to be clear, you want them to make this on there own computer, not on that server, right?
>> Jem Young: Yes, I am sorry, you can exit out of that server just type exit to get out back on your home computer.
[00:01:34] So cd ~ is short for just your own home directory. So, if I see here, I'm back in my own home directory. cd ~/.ssh is where your ssh keys live, and I have a lot of SSH keys.
>> Jem Young: I'm just gonna clean up some of those, some file.
>> Jem Young: Yeah I should not play around with this directory
>> Jem Young: Cool, all right. So, I'm going to make a key, ssh-keygem-t, rsa is just an encryption strategy that we're going to use Rsa is just Pretty secure, and the t is just saying where you wanna use this for, the type encryption, for generating the key.
>> Jem Young: Give the file name. Do not use the default. If you just hit enter, you're probably. If you already have a key, you're gonna overwrite that. Do not overwrite your existing SSH key This is really important. You will get yourself into a world of hurt. So I'm going to call this one, my key.
[00:03:00] That's it. You can call it whatever you want. Just make sure it's memorable, but I'll just call it my key for the sake of the example. My key already exists. Good. I don't want to overwrite that. So I'm going to call this My key two. I'm going to put no passphrase cause I'm lazy, but you should put a passphrase on it.
[00:03:21] All right. That's it. So, move this up a bit.
>> Jem Young: Now I have a public private key. The public key is .pub the private key doesn't have a file type on it. So if I wanna look at that public key, or actually look at public key first, so I'll say my_key2.pub
>> Jem Young: This is what a public key looks like. As you can see it's extremely long. It's I don't want to say unbreakable but it's very, very difficult to hack this. The order of magnitude you need to break into this with a public key is pretty high. This is just a public key.
[00:04:07] I'm a show you my private key which you general don't ever wanna do to anybody. But since this is just for this test server. This is a private key. As we see it substantially larger. We're talking decades of computing time to break a private key. As we can tell this is much more security than password 1,2,3, 4, 5.
[00:04:31] This is why we use public private key. So is everybody with me so far?
>> Jem Young: Okay good we all have a key. So everybody has a public and private key? We're all good. All right. Because we are going to use this later. And you should have some sort of random marks.
[00:04:55] Yes, do not lose your private key. If you lose your private key, you have zero ways of getting it back, and getting back to that server. Especially, we're going to disable login with a password. That's because we all learned it's very insecure. So if you lose your private key you are screwed.
[00:05:12] [LAUGH]. We're in that realm now theres no handholding, if you do something you break your server, you loose your key, you change your permissions incorrectly, your locked out. No one can help you unfortunately, that's, you know, we're real engineers now this is serious. Yes.
>> Speaker 3: Question on tips on keeping your SSH keys organized.
[00:05:34] Like, they have many keys for many services. What's the best way to do that? They're asking, should you have one key for all the services or should you have a new key for each service?
>> Jem Young: That's a great question, Derek. A lot of +1s on that. I tend to use the same key depending on the level of security that I want for my service.
[00:05:53] So for my GitHub accounts, I use one SSH key for most things. But for Netflix services, things like that, I use a separate SSH key, just in case I lose my private key or somehow it gets compromised. Someone gets a copy of it, all my things aren't insecure.
[00:06:09] But inherently, the great thing about the public private key authentication system is that, you can reuse it over and over again. And you can be fairly confident that it's secure. But, do it to your own level of paranoia. If you're extremely paranoid, make a different key for every single site or every single system we need to login to.
[00:06:28] I like to give my naming scheme for what it is, so for date hub key, it's probably called jem_github, for my jemian.com login to that server it's probably called jemain.com. Just giving a name, so something that you remember, that the default system of ID underscore RSA, do not use that system is not helpful at all.
[00:06:47] Because once you make that key you have zero context on what that key was for and when you're trying to log into a server and you have like 50 keys it's not helpful at all to try each one individually.
>> Speaker 3: Follow up question was about the config file in the SSH directory.
>> Jem Young: Config file.
>> Speaker 3: They see a config file what do you do with it?
>> Jem Young: Just leave that alone. It's, we won't go into that today.
>> Speaker 2: So, just to offer, my way of doing it is I make an SSH key pair for every machine. And then just keep one for every machine.
>> Jem Young: That's smart. A lot of people that carry around a USB stick with all their private keys on it, which is pretty useful too unless somebody steals your-
>> Speaker 2: Actually let me amend that every user on the machine.
>> Speaker 2: Right, so if I have two users on each machine, each of them has there own SSH que.
>> Jem Young: Okay, that's smart too. Yeah.
>> Speaker 2: LIke I used virtual machines a lot, so each virtual machine, like vagrant, you know, each of those has their own SSH key.
>> Jem Young: Okay, that's useful too. Again, do it to your level of comfortability with security. I, in general don't have much to steal, not that it would stop anybody.
[00:08:06] Some people are just jerks. They'll break into things just cause they can. But in general, you can have probably one SSH key and use it for multiple services and probably be pretty secure. But, again, be vigilant about not sharing your private key and not losing your private key, so always have backups.
[00:08:26] Use Time Machine. Use some sort of Cloud backup that you want. And you should usually secure your private key with a password. Just in case someone gets it, they can't just easily break into your server.