 Welcome to the Home Lab Show, Episode 38, Managing SSH Keys. This is a question that came up a lot out of our topic on SSH specifically, and we wanted to talk a little bit more in general. Why I say we, I want to Jay to talk about it more, because I don't know that I'm following as much best practice. Jay is, well, this is more his realm. He knows this side a little better than I do. I know how to manage SSH Keys for my servers. Jay is going to talk about how to manage it for your servers and then, well, all the other servers you may do if you're looking for a career in this, and there's not a one-size-fits-all. It turns out even amongst my Linux expert friends such as Jay, there's different opinions on here. So this is a methodology or methodologies we may talk about today, but there's always more reading and always more learning, and there's always better methodologies coming out in the future. But hopefully we're going to lay some groundwork for you on how to do this. I'm pretty excited about this topic. But before we dive into it, another place you can manage your SSH Keys is Linode, and we have them as a sponsor for this podcast. They've been a sponsor since the beginning for us. We really like Linode. Thank them for all of this, and it's very applicable when you're setting up your Linode instance. The best way to do it, Jay, would be putting your SSH Keys in. Yeah, absolutely. No password authentication allowed. Well, we shouldn't anyway. Right. So they make that really simple to do when you're deploying their systems. You can have your public keys available. They can automatically deploy them in there. So any of the projects we've talked about on here, well, many of the projects I should say we've talked about on here, maybe not 100 percent of them, you can run over in Linode. It's a great place. We need to run something in a cloud that's up and running. We were laughing about that because there's a few clouds that are having a rainy day right now. Yeah, like the stormy day. I mean, we have a logging vulnerability with related to Java and AWS outage right now. We have a lot of fun going on. A lot of fun going on right now. Lots of things to patch and update. But we'll thank Linode for being a sponsor of the show, and if you have any systems in Linode running anything with log4j, please tell me that you're not listening to this while waiting to patch. That's not our topic of the day. You should be patching whatever software needs to be patched. If you have something that has a dependency, please patch it. But thanks again for Linode for sponsoring and yeah, we won't I'm hoping there's some time in the future when there's not an egregious thing on fire, but it's the Internet and this will happen again. Yeah. You know, I've always, ever since I started doing podcasts years ago, I've always wanted that moment where I'm like breaking news, this just in, like literally as we're talking, like something amazing happens, but so far it's always been before we hit the record button or the previous day, but I'll get that moment one day. I just can't wait just a person thing. I mean, this is somewhat, you know, we, I don't know that there's really anything I've got some videos on my channel and me and Jay, we're talking a little bit, Jay's probably going to publish a video on this topic as well, because there's a lot of different aspects to it. And when we have a flaw this large, I know people may want us to do the podcast on it, but unfortunately it just segues off for this particular podcast. It's more about patching all your individual things, unless you're a listener that's also a software developer using this, there's not always as much for you to do as a homelabber because just patch all the things. You know, I just released two different videos on Unify patches or an example. I know it's popular in the homelab. Get it patched. That's it. There's not, if you want to know more about vulnerability, read about it. It's, it's on every headline. It's hit all the mainstream media. It's gotten so bad. So wow. Yes. Yeah. Nonetheless. All right. Let's get started on SSH keys. So we can quit rambling about all the other fun stuff on there. I do see, I will mention, I see two things mentioned that we're not covering today, but at least we honor to do list. Teleport is pretty cool looking product. There's some videos you can find by say his name in those comments. And I'll give him a shout out here. That digital life you can find his YouTube channel, but he's done some videos and teleport. It's pretty cool. But we're not covering that today. And there's also a SSH and the certificate management. Are we covering that at all today? No, not today. No, that's going to get its own dedicated future. Probably video on Jay's channel where he's going to dive into that. That's not a today topic. We're specifically going to talk about key management here. Cause one thing the certificate management stuff is a little bit more nuanced. I see people love it. I see people hate it. I've been to say with what Jay said, there's not enough documentation for clarification on it. Would I say that correctly, Jay? Yeah. For the most part, there's a lot of companies out there that, you know, in the enterprise they have their own way of managing keys. And, you know, it's not like they just go out and go out in the public and say, here's how we do it. Here's where we store our keys. And here's how we cash them and, you know, age them out and things like that. You know, cause they're just not trying to advertise exactly how their system works. So there's going to be some gray areas here. I think the important thing to keep in mind is that we're talking about, I'm not going to say the basics is probably more intermediate level things, but there's no shortage of other ways of doing it. So we're going to get all kinds of comments like, what about X? What about Y? And they're already starting to come in before I even mentioned it. And those are all valid. Those are all valid solutions. I will be looking into teleport. I'll be looking into vault of a number of other things. I'll be doing a video on Yuba keys at some point. I've already done one, but it's, it hasn't aged well. So I'll be redoing it. So there's going to be no shortage of content about the other things. But until we get to those other things, we, I mean, we have to have a baseline here. And I think that's what this video is going to be. Yeah. Cause a lot of people just in general managing and creating SSH keys and making sure you have some methodology by which you manage them with your servers is where you should start and have a good working knowledge of it. That way you can better understand the difference between basic SSH, SSH key management and does something more advanced like using vault or using teleport. And the other challenges become when you introduce other third party software in there, you don't just add complexity. You increase that surface. Now, right, surface increases come with some convenience, but you always just have to be thinking about that. Just, it's more of an understanding. Cause when I say there's a flaw in SSH keys, you're like, well, I'm using this as our flaw in this too. You know, and right now we don't know of any flaws, but these are just things you think about as, as you add complexity to your environment, think about the chain reaction of all the things you have to be keeping track of is one more system in the machining that you build that you have to keep track of. So we're just start simple here. Yeah. Yeah, definitely. So a couple of things to mention before we get started, I have an entire video that's an open SSH guide. It's quite long, but you can go in the description. I'm pretty sure I put time codes in there and look at the specific section. So if you know, like a lot about open SSH, you don't have to watch the whole thing unless, you know, you're new to this. Also, I have two videos that are like 99% done pending a, you know, I just watch it, watch them one final time, make sure everything's fine. They're pretty much ready to go right now. And they're, they're related, but not the first one is going to be about SSH config files. It's all about that one thing, something I've covered before, but it'll be a dedicated video just on that. But the second video that I've done is about multiple SSH keys, a topic today, but I kind of consider that SSH config file video to be a prerequisite, not because it's a, you know, related concept is just, um, it, there's, you'll understand when you see the second video, because it all comes around full circle. And then also we have an episode in this podcast where we talk about open SSH. So I'm going to skip what open SSH is and all of that kind of thing because, you know, if you don't know, you could watch that previous episode or any one of my videos and, you know, get the information there. But I think the only thing to know is that it's a remote management solution. There you go. That we're, you know, logging in remotely to systems because we don't want to waste gas driving all the way across town to the data center when we could be managing our servers and our pajamas while we're watching Seinfeld. I don't know. Um, exactly. Okay. So SSH key management, um, why is this even a topic? Why do we need to talk about this? Well, first of all, a quick aside, I've said this before, password authentication is bad. It's easy, not necessarily easy depending on your password, but people can attempt to brute force your systems. Now, one argument straight away is, you know, some people are probably thinking all of my stuff is behind my firewall. None of it is publicly accessible. So why does it matter if I use SSH keys in my home lab or just use password authentication? The short answer, there's nothing wrong with that. If there's no capability whatsoever for someone from the outside to, you know, connect to something on the inside, if it's completely segregated, then I think, um, the only risk would be that I could think of if someone literally stole your equipment and then they had your password too, but then they have your equipment so they can just get into, they can just take the hard drives out and get whatever they want. Um, so I mean, you can make the argument that password authentication is probably fine in the home lab, but my counter to that is SSH keys are the proper way to do it. And part of the home lab is learning how to do it right and getting that into your muscle memory. So yeah, you're going through an extra step, but I think that it'll become muscle memory. It has for me, I use SSH keys on everything. And if it's publicly available, you really should be using SSH keys for sure. For sure. And you know, there's the risk of lateral movement. This is still something that kind of needs to be thought about where somehow, and there was recently some CVEs found, uh, in browsers, numerous browsers really this whole year has been a collection of them for all the different browser platforms. It's not calling anyone out. But if someone gets inside your network, the next thing they look for is what else can I get a hold of? Is this computer valuable or can I laterally move across your network between servers? If they have an opportunity and no one's thinking that your computer would be the attack mode for the server sitting next to it that's on the same network, uh, being able to brute force that is obviously a prime opportunity where they can get around your network and find things. So even though you're thinking it's behind a firewall, I don't publicly expose it. This is one of the reasons is still best security practice to do it. And even in the lab environment, when I'm spinning up servers, when I spin on my lab servers, I still have SSH keys in them. I have password authentication turned off even though their lab, even though they're ephemeral, they're going to be destroyed when I'm done with whatever demo I'm doing is kind of the don't let your guard down for a second. Um, there was a recent debrief by a cyber security company who was, uh, doing proper disclosure of an internal problem they had. They had a password that was left on a demo machine and nothing bad happened because it's part of their demo infrastructure where they do demos. But someone did log into their demo machine and I thought it was cool. They did a debrief on this because like we should have not let RDP open even though it was a demo machine and it was low risk and it's an isolated separate environment, boy, something still did happen and that the thing that our user could be connecting to it and something happening is why overall do it right. That's the, as much as I can hammer that home. Exactly. And to piggyback on that, there's also the vulnerability chain, which is essentially what you were saying, but one scenario could be, well, I guess to take a step back, there's a few types of homelab people, right? There's the, um, people like a lot of us, we have something like PF sense or open sense or something like that, maybe even, even a custom Debian firewall or whatever. And we, it's completely up to date, right? Cause, you know, we're awesome like that. And then the other kind of homelab person is the kind that has some really amazing servers, but they have that D link router from 10 years ago, that's no longer actually getting updates. Cause it's all about priorities, prioritizing those really awesome, powerful servers more than, you know, your firewall in that case, if you're router or whatever your, your device that sees the internet, if it's old, it's, you know, not being updated, then someone breaks into that. They have a, you know, command prompt. And then from there, they probably have access to SSH, depending on what the firmware contains. And then they can try to brute force systems that are connected to that device and then keep going just like you were saying, they could just keep trying to go through the network. If they don't have your SSH key, then, you know, that stops them right then and there. But it's all about the attack surface, which is one of the first things we'll get to. But SSH keys are something that you generate. I'm not going to go into too deep, too much detail what they are because we've already talked about it, but it's a public and private key relationship. You have a public key and a private key for every SSH key, the private key stays with you, the public key, you can put it on a billboard in the middle of an interstate, it's fine. You can throw it up on GitHub. It's fine. Never throw up your private key anywhere, but the public key is public in every sense of the word. So talking about the threat surface for a moment. I think this is kind of what's really going to bring it home because the question from a newcomer might be, should I just use one SSH key on everything? Now let's paint that picture for a moment. So on your home lab, you have password authentication disabled because you have SSH key authentication enabled, and that's how you log into all your stuff, even the computer setting next to you. That's how you do it. And then you get a new job. Let's just say you're now a Linux administrator, you're making some big money and as part of the job, I need you to generate a public key for the servers on your work computer. And someone might say, well, I already have a key. I'll just copy the keys over to the work laptop. And now you're logging into work systems with the same key as your home system. So if it leaks out, you know, that's a that threat surface contains all the machines at work that have that key plus all your home machines. I mean, you're wide open. What are the chances that your key is going to leak? And when I mean leak, the private key leaks, which in that case, you can't really trust it anymore. I don't know. I mean, it really depends on how well you protect it. People make mistakes. Maybe you accidentally revealed it in the clear somewhere. Now you can no longer trust it. At that point, you have to go through all of your systems. Hopefully you have something like Ansible where you'll have to do it once and revoke it. But then then all your work systems, you have to, you know, take it out of there too. It just becomes a big thing. And even worse, you know, if you have a managed service provider that is using the same SSH key on like 2000 clients and that key leaks, then 2000 clients could be, you know, compromise, they can get in, they can get compromised. Yeah, that's the word. I don't know why I sometimes forget that word. But anyway, yeah, they get compromised. And then if you have just one key per client, then possibly one client might have been compromised. But I think that's a lot less of a legal issue than all of your clients being compromised. But then the problem is, well, if you have 2000 clients, you have 2000 keys. So what the heck do you do about that? And that's kind of where we have this problem. Because, you know, I've seen people that have like 20 different SSH keys or however many in their dot SSH folder on their computer. And then they go to SSH into a server and then it tells them that they've tried too many times and they're locked out. And the reason ends up being because it's going to try the first key, then the second one, then the third one, there's only a certain number of keys that it'll try before the server is like, whoa, you're trying way too many keys here, like slow down and then locks you out for a bit. I've seen that happen. So SSH key management can be kind of a challenge and it's a confusing thing because I don't feel like there's a lot of information out there about how to actually do it, which is, you know, obviously our topic for today. Yeah. And managing it, a lot of it's going to come down to managing it with the config file is probably the easiest way to make this work. Yep. And that's, that's exactly something we're going to talk about. So as an aside, like most of what I'm talking about now is in the two videos that I'm releasing, this is just a different format. So, you know, I guess for the people that are listening to this episode, you pretty much are getting the gist of what I'll talk about, but still watch the video because sometimes visual is better for these kinds of things. Anyway, so the first question then, like I mentioned is, should I use the same key and everything? My answer is no, don't don't do that. Generate multiple keys and excuse me, what I do generally is I, when I'm generating a new key with the SSH key gen command, I'll give it some kind of name that I don't like to use the default name because if you do, then you could accidentally overwrite it. If you're generating a new key and then you press enter too quickly and then now you just, you know, wrote over your key, you know, that's not good. So if you have your, the keys you use as a different name, different file name on your system, then you don't have to worry about the key getting like stomped on by another SSH key gen command because it's just going to use the default name. If your keys don't use the default name, you don't worry about it. So hypothetically, you could have an SSH key for your home systems. And if you do Linux stuff professionally, then you could, or maybe a managed service provider is a better example. So that's what I'll go with. If you, if you work for a managed service provider, maybe you have a key for Acme, then you have a key for this, this company, then a key for that company. And you separate them based on that, which I feel is the best way to do it. Now, before you get to that though, I think the most important thing to know is always use a passphrase because that really helps if your private key leaks. If your private key leaks, you should absolutely revoke the key. Even if you do have a passphrase, chances are whoever got a hold of the private key will not be able to use your private key without the passphrase unless you, unless they do have the passphrase and you don't know that they have it. So you don't know, you don't know what they know or what they don't know. If your key leaks, it's gone. I don't care how secure it is or how, if you have like a 64 character passphrase or something insane like that, it doesn't matter revoke it. But still with it, with the passphrase, you have that extra layer that it's as far less likely they can use the key if they steal your private key than if you don't have a passphrase. So definitely use a passphrase. It's it's it's one of those simple things. I know it's slightly inconvenient because you just want the key to log in. You don't want to be prompted for anything. But go that little bit extra. And I'll admit to have been lazy and some of my lab stuff may not have it. But I recommend doing it. I will slightly draw a line at my lab stuff, probably not having SSH path. I mean, I should upgrade that. How's that? Jay, Jay's not going to be going. Yeah, you had this discussion offline. He's like, yeah, Tom, you know, I shouldn't do that. And I'll admit I'm guilty of it too. So don't if you're doing it, don't don't think I'm high and mighty and saying, oh, no, always do this. I'll admit because you can call me out by watching my videos. Hey, Tom, we watch you log in SSH to your lab stuff without passwords and like, that might have happened. I mean, to be fair, they might not know if you have your passphrase cached, which I'll talk about in a moment. But I think that's an important thing. Just because we have YouTube channels in our own companies does not make us perfect. We're not like, you know, infallible. We have multiple layers of security to help protect our systems. Sometimes those multiple layers of security protect the systems from ourselves. You know, super sleepy or just, I don't know what it is, but anyway, you know, that's why we do it. We're not perfect and we learn, we're still learning. And then that's great because then we learned something. We teach you guys about it. So it's the way- Please learn from our mistakes of doing this and maybe Tom's current mistake of definitely maybe my project for the next couple of days should be swapping all my lab stuff, starting it up, swapping up with a new key that has a password on it. There we go. And one exception to this is when, on my end at least is if I'm just doing a demo, like a tutorial video and I spin up a Linode instance, for example, which I'll do often just for like a recording session. And then I plan on deleting that instance right after. Yeah, I'm not going to worry so much about that because that instance contains no information whatsoever that's important. And it only exists for the hour it takes for the recording to be done. I'm not gonna go through like that much trouble too. I mean, I have to do some things because I don't want like a crypto miner to appear during that hour and cause trouble for someone else. But reasonably secure is what I'll do. But yeah, you'll see me not use some of those things in my own videos just because, well, this is a temporary server, which is very common. So you mentioned that passphrases are a bit inconvenient and they are. The thing is though, we have SSH agents which can cache your passphrase such that you don't have to keep retyping it over and over and over again. And another trick I do, I'm not sure if this is just Tmux in general, but or my config, I'll start an SSH agent before my Tmux session. So everything in the Tmux session has that cache too. So I don't ever see the passphrase again until I close my terminal window. So that's what an SSH agent is. You load your key into the agent. It asks you for your passphrase for the key then it's unlocked in memory. And until you close that terminal window you could just keep connecting, disconnecting, disconnecting to that server all day long and you'll never be asked for that passphrase again. Now to make things even better, every operating system, but Windows, maybe Windows does this now, I don't know, has an SSH agent built in actually. So your Linux distro, unless you're using a window manager, if you're using a desktop environment like GNOME, then you could basically unlock the key and it'll ask you, do you want it to always unlock when you log in? So you could basically make your session when you log into your computer, unlock your key for you. I'll leave it up to you guys to debate the security of that. That's another story, but you can open it up yourself to make it more convenient. And I think with macOS, for those people that use that at work or something, I thought it was like SSH-K, but don't quote me on that. There's a command you could use that'll do the same thing in macOS. So unless you're using Windows, unless they have a solution for that now, there's a SSH agent built into that. So that'll help you with that passphrase. If you don't run, I believe Windows subsystem for Linux and load that on there because it's fully the Linux subsystem that has the SSH manager in there. So you can do SSH key gen and your standard SSH commands. Be careful because it doesn't store them under your normal, there's a specific spot in storage. So make note of where it stores that key information so you can properly back it up or do what you need to do with it. Because it doesn't, I don't think it's under documents under the normal spot you might expect it to be. So heads up on that. It goes out of scope of this particular video. So make sure when you generate these SSH keys, you load it all up and you lock down password authentication that you also have a proper and secure backup of those SSH keys. This applies to whatever platform you generate it on, but yeah, just make sure you note where those things are. Exactly, yep. And this is where you start to get into the territory of companies that have solved this problem in some kind of way, their own way. I've seen companies utilize LDAP for this. I've seen SSH certificates being a thing, third-party solutions that some companies run which kind of worry me because if the solution itself has a vulnerability then everything leaks but there's all these different technologies for making this easy. I like doing it manually just because I know how it works, but I get it, not everyone at your company or even in your house if you have like other family members that are hackers and getting under systems too have the same level of experience. Now, okay, so we know SSH keys, what those are and we know what the SSH agent does it just helps us not have to enter the past phrase every time and we also know to disable password authentication and absolutely use a key, that's great. Now, then you start to think about where you want to have a different key. Now, if you have a bunch of Raspberry Pi's that are just testing devices that contain nothing important whatsoever there's probably nothing wrong with sharing the key between all 10 of them because I mean, if you don't really care about them then okay, you're just doing it to be in the habit of it. You could make the argument to have the same key for everything in your home lab but if you're connecting to a friend system you might want to have a different key over there or if you're doing it at work you want a different key per client that's my recommendation. But like I mentioned earlier you have this problem where if you do SSH user at domain name or IP address it's going to try every key in your dot SSH folder and by the time you get to a certain number of keys and if the key that matches that server is all the way at the end it's going to lock you out before you even have a chance to get into it and this is a common pitfall I see with newcomers with SSH you're like everything's right the key is correct on both sides and I use SSH and I get locked out. Now, you could specify the key on the command line that you want to use with I believe it's dash I if I remember correctly and you could say I want to use ACME's key or whatever the file name is for that and then you give it that it's not going to try all those SSH keys it's going to use the one that you told it to use but then you run into this issue where you have to LS in your dot SSH directory which one is which now? I got to remember the file name that gets a little clumsy and that's where we talk about the SSH config file which is how I like to simplify everything and that's also why I recommend watching if you're going to watch my videos on this the SSH config file video first which I will be releasing first before the key about this topic and I think that's the way to do it is using the config file. So what is the config file I'm talking about? I'm talking about a client config file not something in the Etsy directory it's literally called config it's in your dot SSH directory it's not there by default you create it yourself you could just look up the syntax online it's pretty easy that you have like a stanza that contains a name whatever you want it to be referred to I think it's host name I'm doing this off the top of my head but you give it a name and what's confusing is for each entry you can name it whatever you want if your server is Acme dot or web.com or web.acme.com or something you could put that in that's fine but you could also call it like potato in the config file it doesn't matter you just name it whatever you want whatever is easy for you to remember but when you actually type the host name in the config file or the IP address that has to be real but you can give it a name to refer back to anything you want which is what I think makes it easy so you could literally come up with a syntax like home hyphen web work hyphen web for example and in that way it's pretty easy for you to remember the syntax you just do SSH work hyphen web home hyphen web or whatever your server name is and if that's in the config file the SSH client will see that and that name you're typing on the command line matches what's in the file then it's gonna use all the parameters underneath that particular entry inside the file. Now a couple of things I wanna add to this I threw in the live chat and in the description a fun little tool called SSHTO and it's a way to read that config file so when you're like me and you have untold numbers of things that maybe you forgot some of the names of them you can then use this as a quick little bash script someone put together that will read the SSH config file all simple easy bash one liners it's really slick how simple I'm not one liner but one file bash that's using the bash menu system and it can then turn your SSH config into a menu the reason this is handy is because it lets you add a couple other things to that config file such as you put like a dump there's a dummy character you add so it'll parse that and then group them all together to like servers, lab stuff and create like a whole sub menu system it's really easy to use but it's one of those things if you're managing a lot of keys, a lot of systems it kind of simplifies I think the management of it that way we can add this file it's actually it's a really fun utility to use there and other notes that I think are kind of funny and I've covered this when I've talked about this topic on SSHTO on my channel is you can actually put some of the emoji characters will fit into the config file so when you set up your jump box maybe you can put a kangaroo on it or maybe your free PBX box has a little phone icon in it I think it makes them kind of cool as long as you don't put the emoji at the beginning because then you have to add the emoji when you type the word SSH for the autocomplete but SSH and the name of the thing you're logging into will autocomplete or as I said you can also in tandem use this little SSHTO utility it's a great little utility I've used it for a little while that's really awesome so I guess now that you can use the emoji if a server is really, really giving you a hard time and it's tedious and you've been fighting it for weeks and it's just driving you nuts then you could just name it the poop emoji and then, you know, anyway, moving on so we have the SSH config file and that's great but is that directly related to keys? Well, yes or no, yes and no because the SSH config file the client config file I'm talking about is for simplifying your SSH connection command so for example, you could have a username on one system of admin on another one it's your first name and then on a third one it's first initial last name or whatever it is there's, you know, different rules for different places you connect to and that could be hard too because you might not remember what username you're supposed to use on which server because then you'll get like a key error even though the key is right the username is wrong because it's a different username on the other end in the config file you could put the username in there so you don't have to remember that if the SSH server on the other end is on a different port you could put the port number there and, you know, sometimes I've seen you know, clients I've worked with I've had all these ridiculous domain names and you've probably run into this where it's like, you know DNS is supposed to simplify things but they have something like server hyphen one U and then like some serial number dot company dot company dot common who can remember that it defeats the purpose of DNS but that's another story anyway you could put that in there and give it a name you could remember it by and that way you can get into it easier and also the SSH key file where it is on your file system is an item in there too so you could also with that config file tell it everything about that connection including where the key is for that particular connection the name of the server to connect to the port number the username all of that and you could just do SSH space name of entry and config file that's it and you're in if any of this confuses you guys I know this is a podcast and this is probably something better shown visually you will see it like I mentioned these two videos which I'm assuming will probably be out next week will totally take you through all of this and will refresh everything that I've said so far. Yeah, and I also left the link to your previous SSH videos are in the description as well. Yep, and maybe I'll have you sneak it into the description of this episode after and retrospect when they come out so that way we try to keep things up to date so if you're watching this in the future you may find those videos that Jay has published because this is future time. Yeah, we're talking to you from the future now but SSH key management is a large topic so is that everything? No, of course it isn't there's like I mentioned there's all kinds of these other ways of doing it SSH certificates, there's companies out there that have solved this in some kind of way which we could talk about in the conversation can be don't use this company's product because they're not doing it in a secure way or definitely use this company's product because they have security figured out but for right now it's just a matter of understanding how it works, how to utilize the tools that are built in before we start getting into the subject of adding another solution or just using something that's protocol that is optional but there's a lot of clever ways to handle this but understanding the basics is what you have to do first and that's what we're doing today. Absolutely, hopefully that was clear. Yeah, I know that was a lot of information but again, either you'll watch the videos to reinforce what I've said or the other way around depending on the order here watching or listening to I think at that point it'll come full circle and you'll totally understand it and then after those videos are out the door I think hopefully early next year maybe I'll start looking at some of those other ways of doing it that'll just build on those videos so there'll be more content about that coming. Yeah, and like I said in the beginning that one of the tools that they mentioned on that digital life, that YouTube channel you can find the teleport thing I've not vetted it personally but it looks really cool. I watched his video on it, I think it looks interesting. I've talked to the people there a little bit so those are coming forthcoming topics. We're just careful. One of the things we're always careful about is before you recommend a product is have we at least gone through some general testing with it? Do we understand it? Do we think there's a potential threat? Everyone gets excited when something new comes out that seems to solve a problem but it's always really important to vet things and things like that and we take it personally so I'm not at all calling, I see they're in the chat right now, the digital life, they do a great job on it and I haven't looked into the vetting of it. I do trust that he did a good job of looking into it, he's got some great videos but we're just very cautious and careful because it's the better way to go when you're talking about something that manages the access to your servers. I take that at a very serious note. I'm very slow to iterate into new products that seem to solve all my problems. Although I did like I said, my conversation with the people over at Teleport follows those where I did the email back and forth to me and it looks good. I think it's pretty cool and his video definitely piqued my interest. That's why I watched it. Yeah and you know the other thing too is, yeah we realize other people have covered some of these things but I don't personally do well and I think you're probably the same way starting where someone else left off. I always start at the very beginning. I make it a point, usually to not watch a YouTube video about something when I can, there are times when I do but most of the time I try not to because I wanna go into it completely blind just like everyone else is that are watching my videos for the first time where when they know nothing until they get to the end of the video, I wanna know nothing at first and then kinda go down the rabbit hole of figuring it out for myself and that seems to kinda make it stick better if I take the easy way and just, oh here's a tutorial that someone else has already done. Oh that's invalid, that's invalid and rearrange it and give credit to them obviously. I don't wanna do that because I just don't learn anything but the same for me when it comes to technologies like Vault and Teleport and there's others and I've seen comments in our live stream, is this gonna be an endorsement for a product? No, there's no product here. This is all stuff that's built in. The only thing that opens for a product is that we mentioned is the Windows subsystem for Linux which is part of that platform but that's not an endorsement either. We'll get to a point when we'll generate an opinion about those technologies but for right now, I am personally doing it manually. I am not using any product for this. It could be that I discover something like Teleport Vault whatever and decide, yes, this is awesome. I love this. I did look into Vault once, probably over a year ago and I believe that's from Hashicorp if I'm not- Yeah, Hashicorp Vault. Okay and I looked at it and I'm like this is more complicated than my manual method so okay, moving on and I just disregarded it but of course that might not be true my first impression of it. So I do plan on giving it a proper look and all these other solutions as well but I think something could be said of doing it the manual way for a while first because that's when you understand it better. You could appreciate a vendor's product if you want to go that direction or you could do it the manual way forever but if nothing else you'll have a greater understanding of the security behind it which I think is the main point here. You wanna understand how this stuff works before you take the easy way out. And we can't enter it enough get hands on with this start poking away at it hopefully you don't break anything hopefully you don't overwrite your SSH keys because you didn't have a password you added a password you overrode your keys you tried to push it and you're like, oh wait I just broke everything but that's part of the learning process back up everything before you start back up your current SSH keys if you decide you're gonna regenerate some new ones because mistakes have been made before and I learned the hard way years ago and I accidentally locked myself out of many things so that was fun. If you're not locking yourself out of your own systems to where you have to go grab a monitor and a keyboard to get yourself in you are not learning hard enough. You're not learning hard enough man. You're not gonna get yourself locked out. That is a learning experience. It's not your company servers though. The other thing I learned on my time servers. For sure. The other thing I will mention if you really wanna learn more about SSH please buy Michael Lucas's book on SSH mastery you need to buy this book. It is not a big book. You could finish it in just one afternoon. And when I was earlier in my career I read that and I already knew SSH fairly well by them but he goes so far over my head with this stuff that I'm always learning something from him. You need that book. It's not a big investment. It's not expensive. It's not an investment on time. Definitely buy it. We get nothing for that. We just like recommending Mike's books because he's got some awesome books. I don't even know if he knows we're even talking about him. Well I usually message him. I was like, you know, I just let you know I endorse your book again and it'll set a smiley face to me. I message him now in that. So if not just follow my Twitter. Yeah, we don't get a cut of it. He gets all the, he self publishes. He has his own money over there. So I just love his book. Yep. All right. Well thank you for joining us. Link's all down below and look forward to those new SSH videos by Jay. I don't know that I have any coming out anytime soon but definitely Jay does. All right. Thanks.