Linking two Machines with SSH

[00:00:00]
>> So now we have a secondary user. So we're gonna connect to our secondary from our primary, right? So the secondary is gonna be the target machine and the primary is gonna Is gonna be the machine that we're going to connect to from primary. So the next thing that we need to do is we need to come over to primary.

[00:00:22]
And we're gonna do it from Ubuntu, and the first thing we're gonna do right now is we're gonna say SSH key Gen-TRSA. So if you have ever done, like SSH keys for GitHub, this is the same process, right? Why would you do this? Well, or why does Get do that is because Get is using SSH underneath the hood to connect.

[00:00:47]
So what is an SSH key then? An SSH key is this like cryptographic key that basically creates a private version and a public version of it. The private version you never reveal to anyone, that's like kinda like your secret, and then you give your public version to people.

[00:01:03]
And then using the private version and public version it allows services to do a handshake with each other. That they never have to reveal their private keys but they can verify that the other party has the private key that they say they have. I'm not gonna get a lot more into the cryptography of it because frankly, I don't understand that much math.

[00:01:22]
But it's very interesting, it's actually worth looking into. Actually left a link there so you can look into the Diffie–Hellman algorithm which is kind of like the first asymmetric cryptographic algorithm that came about in the 70s from two computer scientists. I think they were at Berkeley, most things come out of Berkeley, and Diffie–Hellman, that kind of revolutionized how we do cryptographic handshakes.

[00:01:51]
There's like yes, it's super interesting. So, that's what this is, is we're gonna generate that private and public key, this public key we're gonna give to the secondary and then the private key remains on the primary. Or the private key remains the primary and we never reveal that to anybody.

[00:02:09]
And then RSA is just like the particular flavor of key that we're gonna generate. Okay, so we're gonna generate a public and private key. It's gonna say this in SSH ID RSA. That's exactly what we wanted. So you're just gonna hit Enter. You could put a passphrase here, for our simplicity's sake right now we're not gonna put a passphrase cuz it would require you to enter a passphrase to ever use this key.

[00:02:35]
Typically you should do that. Like for example, if you're on Mac you should generate that and then you could add it to your key chain that automatically goes in afterwards. For now, let's just not put one. Okay, so now, we have this key. So if I go into my .ssh folder and I look in here, I have an RDSA and an RDF SA pub.

[00:03:03]
This one is the private one, the ID_RSA and one with pub with it is the public one. So never reveal the private one to anyone. And this is the pub one is one that you give away to other people. If you accidentally reveal your private one, delete the file, regenerate them because at that point you can just consider it compromised.

[00:03:22]
And it's also really, as it should, it's very easy to regenerate them, so don't worry about that, okay? So let's go back to secondary. If you're not already logged in as your secondary, like Brian's a switch user, Brian or whatever you named your user. I'm already logged in as Brian so, I don't need to do that.

[00:03:46]
And I'm gonna make a directory of .ssh. So now if I look here in my home directory you see have the .ssh directory, so I'm gonna cd into that. And what I'm gonna do now is I'm going to vi, A file called authorized_keys. Okay, I'm gonna come back over to this one, and I'm going to cat out my ID Rsa.pub, and you're gonna copy everything from this, including the Ubuntu a primary part of it.

[00:04:39]
Okay, Now we're gonna go back over to this one where I have it in vi. I'm going to insert and paste that in here. And this is basically going to say, here is a public SSH key that if someone can verify that this is their key that they have with their own private key, allow them to log into this computer.

[00:05:01]
So it's like the username and password for this user. Okay, so I'm gonna write-quit that. I'm going to have to sudo chmod this, to be, And I'm gonna do it for the directory so, And put in the password. Brian's on it, Ccan I just do this without ch or sudo?

[00:05:30]
I can, cool. Cool. So I made that SSH1 rewrite and execution for just the user, and I'm going to ch mod 600, SSH/authorized keys. So now just it's locked down to just this user, it's not anyone can go in and read these keys which is also good to have as well.

[00:06:08]
Okay, so what we've done so far is we generated SSH keys on the primary so that the primary can connect to the secondary, right? And that we took the keys from the primary, the public key, and we move that to the secondary server. So that when this primary and secondary handshake with each other they can verify to each other is like, you have the same key set, right?

[00:06:28]
That's kind of what's going on here. I guess you can kind of think of it as like the private key being like an actual key, and you can think of the public key being like handing someone a lock and saying I have the key to this. You can display this lock on your front door that everyone can see that lock, but only the person with the key can unlock it with that with their key, right?

[00:06:52]
That's, I think mostly analogous. I'm sure someone's sitting there thinking, well, actually, it's not that which is fine. You can tell me in the chat or tweet me or something. Okay, so that's where we're at right now. So we everything is all set up now. Now, we need to get an IP address from the secondary so that the primary can connect to the secondary.

[00:07:13]
So if I say I IF Config here, IF Config, I actually end up using this command a lot. This actually will just show you a bunch of information about the computers placed on the network. So you can see here, it prints out a bunch of numbers and broadcasts and netmask and that kind of stuff.

[00:07:30]
I don't know what half of these means. But the one that we're looking for is actually this one, 192168643. So this is my network address on this network that I'm on at the moment. And the network in this particular case is just, it's a fabricated virtual network on my computer that multipass has created.

[00:07:50]
It's not even multipass, I can actually access this from Mac OS, right so it's actually the the network on my computer. This one down here you can see this i-net here, this 127.0.0.1. That's a special address that's called the loopback, so it's how a computer refers to itself.

[00:08:08]
So you've probably seen those mugs, there's no place like 127.0.0.1, that would be like your home, right? So you can even see it says right here, Local Loopback. So it's how a computer can refer to itself as an address. This one here you can see this says Ethernet.

[00:08:26]
This is actually like the real network address. So suffice to say, the one that we're looking for here is 192.168.64.3. Makes sense? This one's interesting as well, the netmask is 255255255, means that these first three numbers are locked in, like they actually can't change for this particular network.

[00:08:48]
And you can see the broadcast is 192.168.64. That means that's going to be those numbers that are locked in that won't vary for this network, and a .255 here means that this is the number that varies. So if we look at the various different numbers, it's only varying on that last number.

[00:09:04]
And then I think this i-net is the ipv6 of it. I never used those so I actually, really not totally sure. Anyway, here we go. So, grab this i-net, this 192.168.64, yours might be different than mine. It might be the same, I'm not sure, but this is the number that you're looking for right here.

[00:09:25]
Okay? And now, let's see, What should work now? So that's this was on secondary so I got the IP off of secondary. I'm gonna come back to my primary and I'm gonna say ssh brian@ that number, It's gonna ask you is Are you sure? The reason why it does this is if the computer like the actual physical server changes underneath you, you'll know.

[00:10:06]
So this key is actually exchanges like hey, I'm this server, do you know that you trust this server? And if you say yes, it's going to store that on your computer and say in the future it's gonna check that every single time to make sure you're connecting to the same server.

[00:10:18]
And if that server changes, it's like, hey, something changed. This is not the same computer I was connecting to before and it won't let you until you resolve that situation. And you can see here, by doing that, I have now SSH. So I have my primary computer that's going over the network and connected to the secondary.

[00:10:38]
And now we have set it up SSH. So again, I can just say Exit, and that will drop me back to Ubuntu, and I can reconnect as much as I want. Pretty cool, right? So that's how you set up SSH. It's actually quite easy for the most part.

[00:10:58]
Our Ubuntu is already running the SSH agent, so there has to be something running in the background that accepts these requests. And by default, I think Ubuntu in general just runs that by default. But sometimes in some distributions, you have to go and install the correct SSH agent stuff and get that started running.

[00:11:15]
I'm gonna show you how to do that, you could very easily Google how to do that. But it's cool because we don't have to know the password or anything like that, just by virtue of having those keys we can set it up and it's really easy. So like I do this stuff all the time whenever I need to connect to a VM.

[00:11:31]
So here in secondary, if I go into my .ssh folder, you can see I created this authorized keys file, right? And if i vi this Authorized Keys file, this is the public key from the primary, right? So I pasted that in there from the primary, like I generated that key on the primary.

[00:11:49]
I copied it, and then I pasted that into the Authorized Keys on the secondary. So now, this key, whoever has the private version of this key can log in as this user using SSH. So the reason why this is Authorized Keys is cuz you can have multiple different users being able to connect to it so I could create a tertiary, right, VM and also paste its keys in here.

[00:12:14]
And it could also log into this as long as its public key was in here, if that makes any sense. And that's really as complicated as it is, there's nothing more to it.
>> Can you set up a third computer to also SSH into secondary? Would you just add another public key and authorize?

[00:12:36]
>> Yes. Cool.
>> Is the process the same if I want to connect to a VM running on VirtualBox while I'm running Linux natively?
>> The process will be the same. If you're doing this through VirtualBox, you would stand up a second VM, so like a second window that's running a separate VM.

[00:13:01]
The only thing I'm not positive about and I haven't tried, I think it should work is you have to make sure that those two VMs end up on the same network, right? They need to be connected to each other in some capacity. I think VirtualBox does that by default but I'd really have to check.

[00:13:21]
Yeah, you can also do this with Docker, right? And in some capacity, Docker kinda does some of this stuff for you. But you need to make sure that they ended up on the same virtual network. So yeah, that's the only thing to double check, if you wanna do this using VirtualBox, just make sure that everything is on the same network.