part three of our custom VPC creation lap.
In our last video, we launched too easy. Two instances
when our public sub net
and one in our private submit
in this video we will connect to both instances
by first connecting to our public instance
and then using it as a jump box to connect to our private instance.
So let's love back into the AWS console.
Let's type easy to To get back into the East Sea to dashboard.
We have to E. C. Two instances currently running
when in our public sub net and one in our private sub net.
So now let's go to the VPC dashboard.
We will filter on our custom vpc
Next. Let's click sub nets
again. I will filter on the sub disassociated with our custom. VPC.
If you recall, we placed our private sub net in the default VPC.
We will need to edit the default VPC security group to pret communication with our public sub net security group.
So click security group
filter on just our custom vpc security group
selected the False Security Group and then click inbound rules,
so we will add a rule that says that the Custom VPC security group is permitted to access
our private easy to instance.
And for the purpose of this demo, we will permit all traffic from the custom VPC security group.
Now let's go back to the easy to dashboard and grab the I p address of our public. Easy to instance,
Copy it to the clipboard.
Now we will log into the easy to instance from my linens. Veum,
I'm already in the directory that contains my private key.
I showed you how to log in tow are easy to instance by SS H and using the identity file flag.
Well, that works okay to a point.
what happens when we have to log into multiple servers
or like, an hour design where we have placed our second server in the private subnet
in this case, the cyber Harry underscore d m z dot pin foul is actually stored
It's extremely insecure to store the private key on the jump box
or our internal private server.
Visualize the public key as a bank vault
the private key is the combination to the bank vault.
So is probably a really bad idea
both in the same place from a security standpoint.
So how do we solve this problem?
Well, there are a few ways that we could accomplish this, but the easiest way would be for us to use.
Sssh. Agent forwarding.
Sssh. Agent in Lenox distributions will permit us to place our private key and memory
and then forward it to the instance that we wish to access without having to attach the identity file.
So from a command line, we just type s s h dash, add
then paste in our private key.
This place is the key and memory
to see which key is in memory. Just type
This will list the key that is in memory.
Then we could just type sshh
and then the user name and I p address of our public in distance.
dash capital, a parameter
archives, the key and memory,
and we'll pass it on to our instance for authentication.
How cool is the head?
now we have successfully authenticated to our public instance.
Next, let's attempt to log in to our private instance,
we log into our private servers from our public servers.
This concept is referred to as using a bastion hosts,
and it's a security best practice since we're only permitting access to our private instance from our bashing, host or jump box.
So I'll connect back to the AWS Council to get the I. P. Address of our private server.
Now back to our Lennox Veum.
Let's attempt to log into our private instance using the SS age dash agent again.
we have successfully connected to our private server from our Bastian hosts.
I will type P W d to show our president working directory,
then try Yum update.
Well, first, I would need to make myself route.
Okay, so we're now route.
Let's try that yem update again
and we see that nothing happens.
Why do you think that is?
our private instance resides in sub net be
which does not have a public i p address. So therefore it's not rideable across the Internet.
How do you think we can overcome this obstacle?
You guessed it. We need to create a gnat gateway to translate our private I p to a public I p
We will create our net gateway in the next lesson. See you there.