Tip:
Highlight text to annotate it
X
>> Setting up Secure Shell on a Cisco IPv6 router.
Let's begin.
Let's imagine that you and I have been put in charge of this router
and we've been tasked with setting up SSH for it.
Now, I've got some great news regarding IPv6 and SSH.
All of the steps for the basic configuration are identical to IP version 4,
which includes specifying a router name and a domain name, because those are required
for generating the keys used by SSH.
And we're also going to create a user account.
Because with SHH, when we connect, it doesn't just want a password.
It wants to know who we are.
And then it wants the password for that user.
So we're going to create a local user account in what they call the local database.
Now, the local databases is a fancy way of saying the running configuration on this router.
That's all it's talking about.
One of the challenges comes up that -- is that even though we can do all these steps
to enable SSH, it doesn't, by default, disable telnet, whether it's IPv4 or IPv6.
There are these logical VTY lines -- 0, 1, 2, 3 and 4 -- and when individuals connect,
using SSH or telnet, they logically --
their packets goes through the network into this interface on the router.
But logically, they get connected to one of these VTY lines as they come in.
If we want to not allow those incoming connections to be telnet,
we need to go ahead and tell the router.
So we go into the VTY configuration mode.
We can say line VTY is (0 4), which means all of these five lines.
We can tell those lines that the only inbound transport we're going to allow is SSH.
And that's one way of denying telnet access into the boxes,
by saying SSH is the only protocol we're allowing for inbound connections.
The great news is, is that all the steps that I'm highlighting right here,
they each one of those are exactly the same in IPv4 or IPv6, as far as setting up SSH.
But what's a little bit different is controlling the source address.
Let's say, for example, that we only wanted to allow inbound SSH connections
from the source address or R3, for whatever reason.
Let's say his address is ::3.
In IPv6, we would create an access control list that specifies either
that source IP address or a source range.
And then we would go to the VTY line configuration and simply tell it, hey, listen,
only allow access in if the incoming connection is from the range
of this source address inside of the access list.
The actual syntax is slightly different than in IP version 4, but the concept is the same.
Having said that, let's go ahead and implement all the details needed on R1
to make it a full-blown SSH server, so we can have SSH connectivity,
including removing telnet functionality and controlling the source address with an IPv6 ACL.
Let's fir create the ACL that's going to control who is allowed
to go ahead and telnet to this box.
Now, creating an access control list is really quite simple, and it does pretty much nothing
until you apply that access control list somewhere else in the configuration.
So we'll apply this access control list to the VTY lines, as one of our final steps.
But the syntax for this is quite simple.
It says I have an IPv6 access list.
I'm naming it just R3.
And this access list has one access list entry.
And that entry says, permit IPv6 -- which is the similar as IP in the world of IPv4,
which means pretty much the whole all protocol stack.
Permit it if the source address is 2001:db8:23::3/128.
That is effectively the exact IP address of R3's gigabit 2/0 interface.
So, if the source address matches that, it's going to be a permit.
And that's all that access list is saying.
One of the requirements for SSH is that we have to have a router name other
than "router" to generate the crypto keys.
And we also have to have a domain name.
So, next, I'm going to specify a domain name of CBTNuggets.com.
You can make it up.
It doesn't have to be your real domain name.
It just has to be present in order to generate the keys required.
In the final setup, once SSH is enabled, it's going to require a login of a user.
So we're going to create a local user.
I'm going to go ahead and create a user named admin
who has privilege level 15 rights in the system.
And I'm going to set a password of cisco.
This is who we're going to log on with, once SSH is running.
Then we'll create the keys required for SSH to work.
Reads the crypto key.
Generate RSA.
And I'm going to just tell it straight up I want a modulus of 1024.
It takes 768 or bigger to go ahead and use SSH version 2, which is what we want.
And then it popped up this little message that says, Hey,
congratulations, SSH 1.19 -- or 1.99 is enabled.
What the heck is that?
I -- I know there's SSH version 1 and SSH version 2.
What is 1.99?
Well, there came a time, there's an RFC that talks about if you have a device
that can support version 1 and version 2, go ahead and report it as version 1.99.
And that will simply indicate that you can support version 1 or 2.
So, there is no real, like, literal version 1.99 of SSH.
It's version 1 or version 2, and 1.99 is simply an indicator
that this system can support either type of connection.
Next we're going to do three basic things: Inline VTY configuration for zero
through 4, which is five of our VTY lines.
So let's take a look at these last pieces.
Transport input SSH says, you know what, telnet didn't make the list.
So only inbound traffic that's SSH is going to be permitted -- period -- on these VTY lines.
Then we have the access list that we created is now being applied as an access class.
So it's IPv6, access class, the name of the access list or inbound connections.
So two things have to happen.
Inbound connections must be SSH and they can only be sourced from R3's address,
which is the address specified in that access list as a source IP.
And then login local says, you know what?
Passwords aren't just good enough.
We want to have users log in, and we're going to use the local database.
That's what the local keyword means.
So when users connect, they're going to have to provide a username and then a password.
And this router's going to use the local database to verify that username and password.
Now, to verify this, let's make a road trip over to RF3.
And so I don't have to do a whole bunch of typing of IPv6 addresses any more,
let's go ahead and create a host entry on R3 that says, hey, R1, if you ever see that name,
that really means 2001:db8:12::1, which is the IP address of R1's gig 1/0 interface.
And then, just to verify it works, we did a quick ping of that name,
which resolved to this IP address.
And that verifies we have basic conductivity.
Now we have an opportunity to try our SSH connectivity over to R1.
To SSH, you know what we got to do first of all?
Let's try telnet, because that should not work.
We'll telnet to R1.
And that should not be allowed, because we're not allowing inbound telnet sessions, only SSH.
And then let's try an SSH.
There's a built-in client on IOS for SSH connectivity.
So if we say SSH and a question mark, it says, Okay, we're going to go ahead
and use a dash L. I'm going to log in as the user admin.
And I can specify the encryption algorithm -- or the HMAC, the hash message authentication code.
But I think I'm going to take the all the rest of the defaults and just go to R1,
which is going to supply its IP address.
And with that connection, I've already said who I am.
Now it's verifying my password.
My password is cisco, based on the local database of R1.
And now I'm in.
So we do a show SSH, that shows the details for our SSH session.
And if we type in who, it'll identify the details for where we're coming in from.
And I already have some name resolution over on R1.
So R1's saying -- because I'm connected there now --
says, I've got an inbound connection on VTY zero.
The username is admin who's connected.
And he's coming in from a location called R3.
That's because R1 happens to know that my source address
of where I'm coming from is mapped to a name of R3.
In this micro-nugget, we took a look at the requirements
and some options for setting up SSH.
We implemented it and verified it, as well.
I hope this information has been informative for you, and I'd like to thank you for viewing.