 Tom here from Orange Systems, and we're going to talk about generating FIDO U2F ED25519 SSH keys. This is not proprietary to the UB key. This demo I'm using a UB key NFC5 because it's what I have. This process should work with any other key that supports FIDO U2F. That includes like the nitro keys and the solo keys. I don't have one, should work with them. I don't have one to test. Now this setup does not require any special server side SSH setup, but it does require that both your host and server be running SSH version 8.2 or higher. Some of the other configurations, and Jay from LearnLinux TV has done a video that I'll leave linked down below, do require some server side setup and API key from UB key, and it's because they're using different authentication methods. This is all done without talking to external servers. This is done with this hardware key to derive part of your key. The other key will reside on your computer and we're going to show you how to set that up. Now I have another video that dives deeper into SSH key management, and I'll leave that linked down below if you just want to know how to generate regular keys. It's actually mostly the same process, but it's a little bit of twist on it to get this key implemented on there and as an extra factor of security, which is why we're doing it. Let's start with the accompanying right up in my forum on this. All right. Our demo host is running Ubuntu 2110. The next thing we need to check is that SSH and this is the most important part that SSH tack capital V is 8.2 or higher. So our host here is definitely running 8.2 or higher. Next we're going to SSH into our demo server because we want to make sure it's capable of accepting these keys. SSH root at demo server. We don't have keys installed, so it still prompts us for the password. Feel free to flame me in the comments for doing things as root, not a problem there. And we can see we can log into it dash capital V here and we're running open SSH 8.7. So no problem that they're mismatched versions, not a big deal as long as they're greater than 8.2 where this implementation is supported. Now let's reference the right up here because it's another important factor in case you have an older UB key. The SSH key pair can be either ECDSA SK or ED 25 519, which is one we're going to use. The SK extension stands for security key. Note that the ED 25 19 key pair is only supported with new UB keys, firmware 5.23 or higher, which supports the 502. And we're specifically testing because I have a UB key, we're going to make sure it has the right firmware in it. So LS USB dash V, you can just copy and paste the command rather than me spelling it out. So we're going to copy it. We'll switch over here and we've already run the command and we see that we're running a UB key version 5.43. So that's important to make sure we have that and we can go through and the next important part, sudo apt-get install lib 502 dash dev. This is the middleware that must be present host provide functionality to communicate with a phyto device over USB. As I said, this is not proprietary to UB key, it's just a phyto device and verify the attetation and assertion signatures. That's hard to say. This is where we attest that we have it by touching it. It's really not any more complicated than that as far as go. That's all that really means. So we're going to go ahead and make sure that's installed with that command. So we'll just copy that one in. All right. And that's already installed. Next comes the part where we get to actually generate the keys. This is really simple. We're just going to go ahead and paste in the command I have right here, SSH key gen, the type of key. Now, this is the same I did in my other demo if you don't have the dash SK there. That's just a security key version of this. That means part of the key is going to be here and the other part is derived, not just copied from, but derived from a challenge response with the phyto U2F. That's what this is going to do. And then we're just going to name this one UB key. These at the end here is going to set the host name, the date and UB key. If you didn't have a UB key or you just wanted to call it your key, you could type in your key right here. It's really up to you. I like putting UB key in there. Now if you had more than one UB key, maybe you want to put UB key two, UB key three, UB key four, whichever works for you. And maybe you want to spell UB key right when you're generating keys. Probably pretty important for your sanity sake. Not necessary from a technical. You can put whatever you want here. We're just going to call it UB key. You may need to touch your authenticator to authorized key generation. Yes, we do. It's blinking. Enter a file in which you want to save the key. The fault location is perfectly fine. Passphrase. Do you want a passphrase? That question comes up because the passphrase is yet another level of authentication. So in order to make this SSK work, we're going to leave the passphrase blank and we're seeing passphrase again. But by doing this, now all someone needs is to get this key and we'll actually go to cd.ssh. There's that key right there. There's the private key right here and then the public key right next to it. They would need my private key and my UB key in order to get into the servers that this key has been set to authenticate with and not need a password. If we generate this and use a password, they need the keys and a password. So it really comes down to how you want these things secured and do you need that level of security? It's really an optional thing. It's nice to have SSH keys that also have passwords on them. But just think about your risk model and how often your risk level is so much that you need both of these keys where you have a hardware token. But you know, hey, why not? Three-factor authentication, we say multi-factor. We don't just mean two. So why not? And it's just a matter of typing a patch range and write the key. Now we need to get the keys onto the other server. Pretty easy to do, ssh-copy, root at demo server. We have the password already for that server and now it copied the keys over. So now we can ssh in again, confirm present of ed2519-sk and it's got the partial here for the challenge response. I reach over touch the key and now we're logged in. It's as simple as that. Now the process with these keys is really simple, but very effective. If someone were to compromise a system where my ssh keys are and they were to copy them off, they need this, physically need this, not just a copy of this. They need this key that I set the key on because it's not just static information. This is a challenge response. That's how FIDO U2F works. So every time the key is prompted for, it sends a challenge to the hardware token. The response is then put together to finish the ssh login. Also makes this key start blinking. So someone promoting my computer, even if this was plugged in because I forgot it didn't take it out and it was leaving things plugged in, they don't have the ability without someone touching this to finish the ssh. Now can this be cloned? I'm not aware of any way to extract a FIDO U2F key out of these. There's not even any way that I'm aware of to clone it to another one. These keys are all unique and that kind of leaves you with a challenge. If you put these together, you have to make sure one never lose or never break these. Okay, that's just not reasonable. Back up your ssh key. You can't because you only have half of it. So you have a hardware token over here that always has to go with that particular key. And if this key is lost, we're back to, we can't log in. The solution is either A, use two keys or B, use some other authentication method. Maybe a standard ED2519 key that has a outrageously long password of some sort. Some very high security, high entropy password that would allow you to feel confident that if someone had the keys, they would not be able to guess that password. And then you'll have to for each server that you administer, install the keys that you generated with this and any other keys that you generated. Or maybe your plan B is just the fact that you have physical access where you can log in as root and just re-enable it and re-put a new set of keys in that you generated if you lost 20 years. Those are just a few considerations, something you really should think about. I will leave a link to my video where I talk more about ssh key generation, specifically with this particular ED2519. But this is a great way to feel confident and secure. And as I said when I was generating these, if you wanted to go with sending us up where it's ssh key and a password and someone has to touch this with the hardware token. Now I think you can feel at least a little bit better that that's not the methodology that is going to be used to get into some of your servers if you have, you know, ssh turned on and people are poking away at it. All right. And thanks. Thank you for making it all the way to the end of this video. If you've enjoyed the content, please give us a thumbs up. If you would like to see more content from this channel, hit the subscribe button and the bell icon. If you'd like to hire a short project, head over to laurancesystems.com and click the hires button right at the top. To help this channel out in other ways, there's a join button here for YouTube and a Patreon page where your support is greatly appreciated. For deals, discounts, and offers, check out our affiliate links in the description of all of our videos, including a link to our shirt store where we have a wide variety of shirts that we sell and 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 covered on this channel. Thanks again for watching and look forward to hearing from you.