 that comes up a lot as a Linux user is SSH keys. What are they? Why do they matter? Why are they more secure than using username and password? And which one should you use? There's a lot of options out there. So we're going to break down how to use an SSH key, how to generate one, which is arbitrarily easy, but which one should you be generating? That's what we're going to cover here. So before we get started on all that, let's first, if you'd like to learn more about me and my company, head over to LawrenceSystems.com. If you'd like to hire a short project, there's a hires button right at the top. If you'd like to help keep this channel sponsor free and thank you to everyone who already has, there is a join button here for YouTube and a Patreon page. Your support is greatly appreciated. If you're looking for deals or discounts on products and services we offer on this channel, check out the affiliate links down below. They're in the description of all of our videos, including a link to our shirt store. We have a wide variety of shirts that we sell and new designs come out. Well, randomly. So check back frequently. And finally our forums. Forums.LauranceSystems.com is where you can have a more in-depth discussion about this video and other tech topics you've seen on this channel. Now back to our content. So I always like to cite my sources, leave you with some more reading material to go dive into that'll be deeper and beyond this particular video. But this is a really nice write up over here on Medium. I will be posting on my forums some of the commands that I'm using here as well, but I'll also link to this article. And he's been on the channel before and I have an autographed copy of this book somewhere. I got to find, I got to reread it. Trust me, it's worth reading again is SSH Key Mastery, Open SSH Putty, Tunnels and Keys, IT Mastery Volume Edition. I've had Michael Lucas on the channel before and he literally wrote probably the book on SSH when it comes to just an amazing and vast amount of depth. I've skimmed it. I'll admit, sorry, Michael, if you're watching this, I have not completely read this book, but I have skimmed through it and it's on my to-do list very soon to completely go through it the latest edition. All right, back to the generating keys. So, if you're a DevOps engineer or web developer, there's a good chance you're already familiar with using SSH keys. There's some assumptions made in this that you at least know how to keys. Don't worry, we're going to get to how to produce them. But how to produce them first starts with which ones did you produce. There's actually a lot of different options when it comes to SSH keys, DSA, RSA, ECD, ECDSA and ED2519, the most recommended public key algorithm today. So, that's actually what we're going to do is show you how to generate them with these. Now, the only time you should probably be using some of the older ones here in 2020 is maybe you have some legacy systems that you have to manage that require these older keys. They're not a big deal. So, this is something you're going to have to face as a network engineer that, well, some equipment that should have been retired isn't, but you can have both keys. You can still use the more modern key system and in parallel at the same time have the older keys available in your system. I still have them in my system where I've installed these in a few places in, well, I should say within our jump box where we administer things. That's going to be a separate video that I'll talk about much later. Not in this video. It goes out of scope of how to set up a jump box, but essentially it's a way you keep keys so multiple people can manage them. But keeping those older keys sometimes is important for that older pieces of equipment. Now, the good news is you can always just use the newer keys for your modern systems and then keep those older keys laying around in there for the older systems that need that legacy and don't have the support for the modern systems. But I think anything in the last, like, eight years has had modern ED 2519 support. But obviously, if you've worked in network engineering for any time, you know that retirement age for some equipment is exceedingly beyond that. And of course, if you use some weird proprietary equipment, well, some of those vendors are using libraries that are older, even if the hardware is newer. All right. Not to get too far off topic on there, but let's get right into the key generation part of this. And they have all the breakdowns of why she uses key. And like I said, it dives into a lot of really wonderfully complicated math that keeps this all system secure and how public key authentication works. And essentially, the gist of it here is going to be you have a private key, the private key, and then there's a public key. The public key, well, I can give anyone. Matter of fact, I have. I give my public key out for free on my Github or to people that need me along in their systems. I can handle my public key, I can throw it out on the internet. It doesn't matter. It is only one piece of the key. It's basically a way you can lock your system. And so only the holder of the private key can get in. So with me having the private key, which please never put your private key anywhere on the internet, this happens. A lot of people do this. And if your keys are out there, you're in trouble because anyone with your private key can then log in the systems. So it is very imperatively important that this gets protected. Now we're going to start here with two Linux systems that neither one of these have any keys on them. We have our main system, and we'll assume like this would be the computer you're using that you want to generate your keys on, that you're going to keep secure and locked down. By the way, this is why full disk encryption is so important, because if someone were to get at your computer with an unencrypted disk, like for example, if it was off and you were able to access the files on there, they would be able to exfiltrate your keys. This is why having your home folder encrypted is important. Having your whole disk encrypted is even better as a mitigation against this, because you really have to keep these locked down. And you should back them up also in an encrypted manner. That, you know, how do I save my SSH keys comes up a lot. I'll show you where they're located, but yes, they really need to be backed up. So we're going to start here on the main system. We're going to go to dot SSH. By the way, this does work in the Windows subsystem for Linux. I'm not an expert on that particular usage of it, but I do know from talking to some of my friends that have been forced to use Windows in their life, that the Windows subsystem for Linux actually does have an ss.ssh folder and can generate keys and hold on to them, which is also a good reason if you're using even Windows computer, same answer, always keep it encrypted. But we'll look here in the dot SSH folder. So you see two files, authorized key and known hosts, authorized keys are the public keys that are allowed to log into this system. So we'll go over here to the system seed SSH. No authorized key file, because no one currently is authorized with a key to log into this system. So there's no authorized keys on this one. I SSH did and I have my keys from my laptop so I can get into this main system for demonstration. So clear. Now, clear this one real quick. The IP address of this is 192.168.3.168. So we can go ahead and SSH root at 192.168.3.168. And it lets me log in with username password pretty straightforward. So now let's go ahead and generate some keys and copy them over. So we know we can log in, because we need to be able to at least log in once to get those keys copied over. And here's the command we're going to use to generate the key. So it's SSH key gen dash A. What the dash A is going to do is basically run through iterations to create a lot of randomness to create a very random key. This is one of the attacks that people talk about when there's not enough entropy or not enough random. And if you generated a key based on some predictable amount of information, maybe someone could reverse engineer and derive your key. It's an edge attack. It's a really complicated math in there. But that's why you want to run some level of dash A and we'll say 100 iterations that will go through there. The key type ed2519. The file specified right here is where it's going to save it to. So dot SSH dash underscore ed2519. And we're going to give it a name. And this is important because for tracking purposes, you may want to give it like your name. So you know which key that was, you could name them. And we're going to use this one for our friend Hans at Detroitutdlingcompany.com. Empty for passphrase. This is an option right here. If you want to have an encrypted passphrase, that is something you can go that goes a little beyond a scope of this. But for the most part, that's something that is an option you can do. So now it's generated. It's depending on how fast your computer is. It may pause right there. This is on a fast system. So it did that pretty fast. So here are the two keys. So if we look at the id.pub, that is it. SSH. This piece right here, that's all you need. And the SSH, the key type there and the person it belongs to, that is the publicly available. I can email that to anyone. I can publish it on the internet. I can post it publicly so people can download it. And that's the only thing they have to put into their authorized key file to allow me to log in. Now here comes the more complicated part. Here is the id.pub, there. id 2519. This is the open SSH private key. Do not. And don't worry, I'm destroying these after this particular video. Both of these virtual machines and this private key will be destroyed. And it's word wrapping, but you can get the idea what this private key looks like. There you go. That is the private key. And this is what you really have to keep. Once you've set these private keys up, if they get out there, anyone with this private key can log into any system with your public key installed. So usually you put these public keys all over the place to make it easy to administer your servers without passwords and don't lose them. That's the important part. But how do we get them over easily to the other system? So as I showed here, it's only gotten known host. There's no authorized key. Now you can manually create that file, authorized keys and just drop the public key in there. That's one option. A matter of fact, when I'm building systems or if you look at the way you can build a system or init scripts, you frequently will have them pull your public keys in. That way you never have to worry about passwords. I have a link below for an offer code for digital ocean. For example, if you create a server in digital ocean, you can have it automatically drop in your public key. That way as soon as the server is created, you never have to have a password to log into it. It's never exposed to a potential brute force SSH attacks by username and password. And we'll show you at the end of this how to disable that. So we're going to go here SSH copy ID. So we don't know we can SSH in, which is always the first step. So actually, clear SSH route. We know we can get into there at route at 192.1683.168. So we're just going to go over here. Copy ID. Fix that real quick with a typo. It's SSH copy ID route at 192.1683.8. All right, number of keys added one. So now we can go here. There's our authorized key file. There is that SSH ID 25 519 key. And now I can log in. So if we go back and SSH route at 192.168.3.168, it logs in with no problem. So now we have that authorized key in there. So we can now be in and show you from this target system here, there we're on that system versus now we're back on the main system. So that's the easy way just to copy the keys over. Now, if you were to lose these keys though, so over here, and we were to lose this particular key, or we can just move it somewhere else, move it to temp real quick. And we tried SSH back in. It's going to prompt us for the password again. Now a little background of what's actually happening behind the scenes. When you SSH, and also it was added dash fee, you can see it's going to attempt each key it finds, but it doesn't find them. So these are the different key types, like I mentioned in beginning RSA, DSA, and this one right here is going to try to offer them, going to try each one see if they work and away they go. So let's actually move that from slash temp back to the SSH folder. And then we will do the same thing. Do a dash fee. And now you're going through the same thing goes through identity files, looks for them finds which one matches finds out if it accepts it. SSH authorized keys agent finds it away we go. Now if you wanted to remove access over here, we'll just edit the authorized key file. And then we'll go ahead and delete that right there. And this is in case you had multiple keys inside of here, you can delete only the keys you want because they can have any authorized keys file as it name implies it's plural. And you could have many different keys on there. But that means by the way, it didn't log us out. So if you ever have lost your keys, you also have to kill any sessions that you have open because it removing the key once you're already authenticated, it doesn't kick that person out. So right there's that me logged in from that system. So now we're going to go ahead and log out again. But if I up arrow and try to go back in prompts me for a password again. So then we can always go back and just copy copy ID, put the password in and that authorized key is back in here. Clear. So my face isn't in the way clear. Now we're back up at the top. Now the last little piece I want to cover is a bit of housekeeping as I call it. If you want a system to be a little bit more secure. And once you put these keys in, that's great. Except you noticed I was able to log in with passwords. Now we're going to disable password. And probably maybe you don't want people logging in as root. So I'll show you where that setting is on there. So we're actually going to clear this side because we're in we don't really need to change anything else. So now we'll go to and we'll just use my favorite editor Vim slash Etsy SSH SSHD and password authentication is set to yes. You'd want that set to no. So this is that file. And matter of fact, there's a few there's a lot of different options in here for modifying things. But we're going to focus on the password authentication. So we want to change that to insert no, and then permit root login. So here are the options for permitting root login. Do you want permit root login? Maybe. Maybe it's convenient that you manage things as root that is up to you. There are lots of debates about that because with great power, you know, comes many responsibilities and including logging in as root all the time, you better be very careful what you're doing. And we'll just block this one out. So you can say permit root login, but prohibit password. So we'll change that to there and we'll, well, we can just go ahead and we don't really even need that one. But permit root login prohibit password means we can only log in with SSH keys. So once you've done this service SSH restart. And now without the authorized keys, we're not going to be able to log into this system. So if I exit up arrow, permission denied, my public key on my particular laptop is not on there, but I can go into my SSH keys. There's my key and there's mine right here, the pub key right there that I'm looking for. All they do is get that key onto the computer, whichever way I need to. And from there away you go. Now, one last thing is SSH keys are stored on a per user basis, both for the system you're generating them on. They're stored in the SSH folder. So if you generate them as whatever username, that's where you're going to find them. And the same thing with the target system, for each user, you can have a different SSH key. So maybe you have one that logs in as a separate user so you can sudo to root. So you can have, you know, whether admin or base level user, Tom, if you will, that you set up on a system, that way you can log into that and go over and switch to be root. So there's nothing in the root folder. So there's not even a potential with no keys in root to log in, but you can log in as another user and switch over. So that is just the methodology they use, which keeps it very simple. So every user can have even completely separate, which is ideal. Now, as far as like the key management, and maybe I'll do a video later on this particular topic is when you're dealing with a group of people at a company, you usually use what they refer to as like a jump box. I think it's maybe referred to as a bastion server as well. Basically, you control access to that particular server, and then you permit access to that particular server to other systems. And it's kind of a way to centralize management instead of letting everyone just have the rest of each keys everywhere, which becomes a real pain to manage. You have something simple like a single server. So if I ever have to change keys, I can then change them all from one server, and then I'm only controlling access to and from one particular server in my network that allows my staff to get out to others. That's kind of the premise of how that works. And at some point, maybe I'll do a video on that as well. Let me know in the comments below if you've got other comments, concerns, suggestions of how this should be done, and I'll leave the command list over on a forum link below on here. So if that clears up the SSH key management that seems to come up whenever people see me just logging in real quick to all the servers I spin up, and yes, I do have both in my digital ocean servers and my local servers, they automatically drop my keys and every time I spawn a new server, that makes making videos a lot easier. It makes testing a lot easier because now I don't have to go through and restrict them. And yes, even those are lab servers, their default setting is no password authentication allowed. To me, this just makes a lot more sense, because even in lab environments, you just don't want to make that mistake. You don't want to leave simple passwords or anything like that. You want to always be using keyed authentication. And I will say this because me and Michael Lucas had a talk about this. SSH he loves, but it also terrifies them. We have become a bit of a monoculture in administration with SSH. SSH is well vetted, very secure, but you know, people have asked what happens if they find a major flaw in SSH? And my answer is go home. Just go to live on a farm or something because the internet will break catastrophically if SSH keys. If someone found some easy way around the SSH system, trust me, people are trying all the time. They're having flaws in like the earlier versions of SSH one exploits available. But since we've moved to the more modern version, it is a well vetted protocol. It is a very good encryption protocol and watch my video on things like proxy chains and all the other stuff that you can tunnel over an SSH tunnel when you get in. It's amazing. But yeah, it's very scary that we all rely on a single protocol for a massive amount of administration across a lot of networks for very critical systems. All right. And thanks. And thank you for making it to the end of the video. If you like this video, please give it a thumbs up. If you'd like to see more content from the channel, hit the subscribe button and hit the bell icon if you'd like YouTube to notify you when new videos come out. If you'd like to hire us, head over to laurancesystems.com, fill out our contact page and let us know what we can help you with and what projects you'd like us to work together on. If you want to carry on the discussion, head over to forums.laurancesystems.com where we can carry on the discussion about this video, other videos, or other tech topics in general. Even suggestions for new videos, they're accepted right there on our forums, which are free. Also, if you'd like to help the channel in other ways, head over to our affiliate page. We have a lot of great tech offers for you. And once again, thanks for watching and see you next time.