All right, so let's dive into the security now and we will not finish our entire security discussion today.
It will roll over into our next session.
Let's begin with device access, authentication, configuration, and verification, which is all about what?
Two exam objectives. It's about configuring and verifying device access controls like line and password protection,
authentication, authorization using things like AAA.
So, we'll have another discussion on AAA. I've separated it out here in this case,
so that way there we can focus a little bit more on AAA all by itself.
So, the best way to have this discussion is just to jump into our live environment.
There are slides that you can go back and review and read if you want to.
That's part of my class slides, but it's a lot better for us just to hang out in the live environment
and look at everything we need to look at from this perspective.
So, the first thing I'm going to do here is show you that we're connected to R1 right now,
and I'm connected to the console port at this particular point in time.
So, as soon as I hit return to get started, you'll see that I'm immediately in user exec mode.
That is bad. That is really bad. Why?
Because that means anybody who can gain access to this console port, physically connect to it,
will immediately get access to user exec mode.
Now, remember that user exec mode, there's not really a whole lot of things you can do,
but if you get yourself into user exec mode, you're one step closer to elevating your privileges
and getting more privileged access to the device.
In addition, there may be a few things in user exec mode that a criminal could access,
which could give them an opportunity to potentially do something malicious anyways.
So, it's better that they don't even have access to user exec mode.
So, we're going to have to protect the movement or the connection, I should say, to the console port.
Now, the command enable allows you to elevate your privileges, and when you type in enable,
it gives you the highest level privileges possible on the device, and that is privilege level 15.
So, I've gone from user exec mode, me having privilege level 1 access,
so the minimum level of privileges I could possibly have, to going to privilege exec mode,
having privilege level 15, the highest possible privileges I could have,
without being questioned once about my authentication or requiring to provide any identity whatsoever.
So, let's go ahead here and talk about how we can configure and verify access control parameters on our device.
So, first, we'll start off with the basic, basic, basic local options on our device,
and we'll move our way up to AAA in our discussion.
So, first and foremost, let's take a look at show, run, pipe to section, line.
So, if you forgot from your CCNA days, what is line? What is a line?
Okay, always remember that a line is a method that we have available on our device, so we can manage our device.
So, for example, with the console port, we have the opportunity to physically connect to this device
through the console port using a serial cable and a terminal program on our device,
our PC, laptop, I should say, and manage the actual device.
Something like the aux port allows us to set up a modem,
so that way I can dial into the device over a telephone line and manage it.
We also have our VTY lines, which give us the opportunity to remotely manage our device
using things like Telnet or SSH protocols in order to accomplish that.
So, three different options that I want you to be aware of for the exam,
any other options you don't have to worry about, the basics, line console zero, aux port, and your VTY lines.
So, in this case, I have a total of 16 VTY lines that we could use for remote management connections
with the default VTY lines being zero through four, so five default VTY lines on my device.
All right, let's go back to the console port here.
If we type in configure terminal and we type in line console zero,
I have the opportunity to put a password on the console port by using, what, the password command.
So, let's just use a password of Cisco today in order to make sure I don't forget my passwords that I'm using.
So, now that I've done this on the console port, if we log out and we log back in,
what we're going to see is that I am not asked for a password.
Uh-oh.
All right, so that's a problem.
Why is that a problem?
Because even though I applied a password, that password is not in effect.
How do we enable that password?
How do we enforce that password, folks?
How do we tell the router, make sure you ask the user to supply the line password?
How do we do that?
Because right now, it's not doing it.
How do we force that to happen?
Does anybody know?
It's going to be important for your exam success that you know this.
So, if I want to force that line password to be utilized,
what command do we need here on the console port in order to force that to be used?
All right, it's going to be the login command.
Login, L-O-G-I-N.
So, we type in do show run, pipe the section line.
We'll now see that we have line console zero, password, and login specified.
So, now, if we turn around and exit back out and log back in,
you'll see it's now asking me for a password.
So, I'm going to put in the line password in this case.
So, it's imperative that you recognize for the exam that when you see the login keyword,
it means enforce this line password.
Ask the user to supply the line password.
That is what it's enforcing in this particular case.
So, if you had a situation like this on the exam that you were looking at,
then is the user required to provide a password?
What's the answer to that question?
Is the user required to provide a password on the console port, yes or no?
Good answer.
Yeah, no, right, because it doesn't say login.
These are the things you need to be able to recognize.
This is the type of stuff that Cisco is going to be testing you on.
And so, remember, 20% of your exam is on security.
Don't be surprised if you get four or five or six or even seven questions on this type of stuff
that I'm covering here in this discussion.
So, can you really understand how everything works and put it all together for a question?
Let's go down to the VTY lines right now.
So, if we go down to the VTY lines, the VTY lines are for what again?
Remote management connections.
So, telnet connections, SSH connections.
And when you look at transport input all, that means all,
all remote access connections that this device supports are allowed.
So, if we go to line VTY 0 through 4, and we say transport input,
you'll see here that it states that all means all protocols.
So, what protocols?
So, any ones that are listed here.
Now, for this exam, you really only have to worry about telnet.
You really only have to worry about SSH.
So, in this case, if I want to ensure that only telnet is allowed or only SSH is allowed,
then you would type in which one you want to allow.
So, that one's only telnet.
This one would be only SSH.
If I want to allow both, I can type in, for example, telnet SSH.
Or we could type in SSH telnet.
The order doesn't matter.
The order does not matter whatsoever.
So, this is how you control what type of remote management protocols are allowed to connect to the VTY lines.
Now, if you don't want to allow remote connections at all, then just type in none.
And that essentially disables that VTY line.
So, if you ever see none as an option in your output or you need to deny all protocols from being used,
the simplest way to do that is transport input none on the VTY line.
So, we're going to put in transport input telnet SSH, SSH telnet.
It doesn't matter the order.
Do, show, run, pipe the section line.
And we'll see here that we're now only allowing telnet and SSH.
Let's go over to DSW-1 right now.
And on DSW-1, I'm going to type in telnet.
And we're going to telnet to 10.40.12.1.
That is R1.
I believe it is.
Let me just double check.
No, it's not.
It's not R1.
What am I doing?
What is R1?
That's not the right address.
10.40.23.1.
All right.
Let's go back to DSW-1 and put in the right IP address.
Because right now, we are trying this, and it is not going to work.
Why?
Because 10.40.12.1 is actually the IP address on this device, interface VLAN 421.
That's what that is.
All right.
So, let's do this instead, telnet.
There we go.
And you'll see that I have successfully connected to this device.
Now, why did I successfully connect this device right now?
Well, if we go back to R1, you notice how it says no login?
What does no login mean?
No login means do not ask the user to provide a password.
So, no login does not mean do not allow them to connect.
That's not what it means.
So, on the exam, if you saw that, and you had to pick out of a lineup what that means,
do not pick the one that says you are denied from VTY access.
No, you're not.
You are 100% allowed without providing a password.
That's what it means.
Now, that's not the default on your VTY lines, okay?
The default on your VTY lines is actually going to be login.
That is actually going to be your default.
So, let me show you what the default actually looks like.
So, the default is line VTY 0-4 and then login.
So, by default, what you should get is an error message when somebody tries to telnet to your device.
And that error message would be password required but none set.
That's typically what you would see by default.
And what does that mean?
It means the login command is there, but no password has been specified.
So, if we provide a password, for example, of like Cisco, now we look at our output,
and we'll see that we have a password, we have login, we're allowing telnet.
So, if we go back to DSW-1, we should see that now that works,
and it's going to ask us for the what?
The line password in this particular case.
So, if you are on the exam and you see something like this, what does this mean?
Well, like we talked about the console part, if it says no login,
then that means you do not have to provide a password, even though the password is there.
So, right now, folks, question is, what password is needed to log into the VTY lines?
Your answer would be no password needed.
So, let's go back to DSW-1, and we'll see that.
There you go.
Go back to R1.
Let's change that.
Login.
What password is needed to log into the VTY lines?
Cisco.
Let's go back to DSW-1.
Let's try telnet.
Cisco.
All right?
So, this is important.
It may seem so simple, right?
It may seem so simple.
You're like, oh, my gosh, I can't believe we're doing this.
Okay, but here's the deal, right?
If I gave you all of this in an exam question, and then I asked you questions about that,
can you answer them based on just what you see?
Like, what would happen if somebody tried to log in under this condition or that condition
or so on and so forth?
For example, what if I just showed you this?
Let's go back up here.
And what if I showed you this?
And I say to you, and the question is, what is going to happen if somebody tries to connect
via telnet?
That's it.
That's the question.
And there's four options in a multiple choice question.
What's going to happen if somebody tries to connect via telnet?
Well, you look at all this output here, and you're like, okay, so telnet would be my VTY
lines.
So, VTY lines zero through four.
And it says here, log in, but there's no password.
So, the result would be what?
Password required, but none set.
Remember that?
Password required, but none set.
So, that would be the option that you would have to pick, password required, but none
set.
That's why I'm spending so much time on this, to make sure that you have every, possibly
every possible scenario shown to you here as we talk about it, so that way you're not
blindsided on a certification exam with some of this stuff.
Okay.
Now, what I've just shown you is what we call line password authentication.
Line password authentication.
What is the primary concern we have with line password authentication, folks?
Meaning, why should we not use it?
What's the risk that's involved with using line passwords?
Okay.
Conrad says scalability.
Scalability.
Okay.
What does scalability mean?
It means that, well, it's going to be tough for us to grow.
What?
Grow potentially the number of users, but wait a second.
Let's look at what Casey said.
Accountability.
There is no accountability.
Meaning that every administrator who uses this device via the console port or the line,
V2I lines, is going to have to what?
Use that same password.
So, if I use the password, Casey uses the password, Conrad uses the password,
Andrew uses the same password, we don't know who's logged in when.
We don't know who's doing what when.
There is no accountability.
So, if I log in and I make a whole bunch of changes that are really dangerous for the device
and it causes a security breach down the road, well, any one of us could be blamed,
and I'll point the finger immediately at Andrew.
Sorry, Andrew.
But that's what I'm going to do to you.
So, yes, password required but none set.
Let's go back to that.
Password required but none set would result in not connecting.
Yes, that's right.
So, if you get that error message, you can't connect because there is no password,
yet the device requires a password because of how we have it configured.
All right.
So, accountability is a big deal here.
All right.
So, this is not all that great.
But it is an option, and therefore you could be tested on it.
What is a better option we have locally so that way there we do have accountability
when it's all said and done?
We have what is called a local username and password database.
That's what we have.
So, for example, I can type in username Raymond, and then I can type in password,
and let's give Raymond a password.
Let's also, for example, do username Conrad and give Conrad a password of Cisco.
Again, why?
I don't want to forget.
So, now if we look at the able to do show run pipe to section line, we'll see here,
pardon me, pipe to section username.
You'll see here that I have some passwords stored in the local username
and password database.
But if you think about the lines right now, the line says what?
Password Cisco.
Login, meaning use the line password.
Login means use the line password.
So, what I want to do now is I want to change this so that way there we use the
username and password database.
So, I'm going to type in line console zero.
I'm going to type in login.
Now you type in local.
That's right.
Login local.
Thank you for that.
So, now if we type in do show run pipe to section line,
we'll see that we're now using the local username and password database.
So, question is, which password is going to be used to log into the console port?
What if that same question was presented now?
Well, it's not going to be the line password anymore.
It's not password Cisco.
The answer you would have to pick would be a username and password from the local
username and password database.
Any one of them.
Any one of them would apply.
So, if I type in do show run pipe to section username now, right,
any one of these would work.
Any one of these.
So, the answer is what are you going to use to log into the console port?
You're going to use any local username and password from the local username
and password database.
So, let's test this now.
If I type in exit and I hit enter, it's asking for a username now.
So, I'm going to type in Raymond.
I'm going to type in my password, and away we go.
So, it's important that you recognize that even though this password is here,
it's null, it's void, it doesn't matter.
Why?
Because it says log in local.
That's why.
So, password Cisco is just sitting there doing nothing in this circumstance.
All right, let's go to our VTY lines.
If we go to our VTY lines, let's modify those.
We'll type in log in local as well.
And we'll see here that log in local is now specified.
So, if we go back to DSW1 and we try to telnet,
you'll see now it's asking for a username where before it didn't.
So, I'm going to use Conrad, type in Cisco, and there you go.
So, the password of Cisco is not the one on the line I'm using.
That's not the one I'm using, right?
We're using the usernames and passwords that are in the database.
Remember, I'm only using the password of Cisco here,
so I don't forget what the password is and lock myself out
or mess up all my demonstrations.
So, don't use Cisco in the real world, ever.
All right.
Now, I want to talk about the different options we have
for the username and password command.
So, the username and password command right here is username in plain text
and password in plain text.
The problem with that is that if anybody gets a hold of my running configuration
or my startup configuration, whether it's by grabbing it out of the device
or sniffing information out of the wire as I'm connected to it via like a telnet session,
which I shouldn't be, by the way.
We should be using SSH.
But the idea is we want to store these passwords in our local username
and password database in a more safe and secure format.
We want to hash our passwords in our database.
So, when we're using the username and password database,
this is the non-recommended way of doing it.
You can see up here that this is hashed.
This is the recommended way of doing it.
So, the easiest way to do that is when you're creating your usernames,
you type in secret instead, and then you type in your password.
Let's spell username properly.
And now when we look at the output of that, we'll see that because we used the word secret,
this password is no longer stored as Cisco.
It's stored like this.
So, what we have here is a hash.
This is the actual hash, and this is what we call a salted hash.
So, what the device does is it took the password of Cisco
and 5 is referring to what we call level 5 encryption on our device,
but we're not actually encrypting.
We're actually hashing using the MD5 hashing algorithm.
So, the MD5 hashing algorithm combined with a salt, combined with the word Cisco,
has given me this result of this.
So, now if anybody steals my database, they're going to have to figure out what this hash is.
And if you don't know anything about hashes, let me give you a little rundown.
A hash is something that is non-reversible.
That's right.
Where encryption is reversible.
If I encrypt, then that can be decrypted.
But with hashing, it's not something that's reversible.
So, when you generate a hash of something, there's no way for me to take this value
and use hashing algorithms and, like, reverse engineer it.
So, what do we typically do with it?
We would have to have something like a database of words and all the respective hashes,
because when you take something and you hash it, if you take that thing again and hash it,
it's going to produce the same result.
Take it again later on, a month later, hash it, produces the same result,
as long as it's the exact same thing.
So, no matter what, every time I take the word Cisco and hash it, I'm going to get the same result.
If you take the word Cisco and hash it, you're going to get the same result as me.
We're all going to get the same result.
And so, that's why we have salting as well.
So, salting adds randomization to that, making it a little bit more stronger, safer, secure.
So, that way, if a cyber criminal does get their hands on this,
then they have to use the same hashing algorithm, the same salt,
and they would have to know the word in order to figure it out.
Or, to try and reverse that, it's impossible because you can't.
But having even a table now becomes difficult because now you need to have every word
with every single possible salt in existence, called a rainbow table, in order to get the job done.
So, it makes it really hard for cyber criminals to get the job done.
So, we definitely want to use secret in order to hash our passwords in our local user and password database.
By default, when you use secret, remember this, by default, when you use secret, it uses MD5.
But we have the opportunity to use other hashing algorithms today.
So, let's go ahead and create an account for Andrew.
And you'll see that I'm going to type an algorithm type now.
And you'll see MD5 is the first one listed.
That's the default.
So, just by typing in secret, it automatically uses MD5.
I'm going to use one of the other ones here, like if we want to use SHA-256, using a PBKDF2 hashing algorithm.
Then I type in secret now.
And then I type in Cisco.
We'll see that Andrew has a much, much, much, much stronger hash of the word Cisco than Casey does.
So, notice how the MD5 hashing algorithm produces a hash this big, where SHA-256 produces a hash this big instead.
And it also uses a much larger salt that you can see between the dollar signs.
So, the salt ends there.
That dollar sign, the salt all the way over.
That's significantly larger than just four characters that we have for MD5.
So, by using a stronger algorithm type, if somebody did capture the information about the hash, it would be nearly impossible for them to ever figure it out.
Unless they try every single possible combination by hashing plain text words and trying to ultimately figure out, is it the exact same one?
But now they would also have to use what?
They would have to use the same salt as well to get the job done.
And to figure that salt out might be very difficult for them.
Now, if they get the hash plus the salt, it makes it a little bit easier for them because they know the salt in that case.
But if they just get the hash, it's pretty much impossible now for them to ever figure out your password if they've captured your hash.
That's why it's important to always store your passwords in a database using a hashing algorithm.
So, store the hash, not the plain text.
Because if the hash is what is stored and not the plain text, if anybody compromises your database and steals all your usernames and passwords, then what do they have?
They have all the usernames and all the hash passwords.
The thing about that is that now they're going to have to try every single possible combination and figure out what all those hashes are.
So, if people are using strong passwords and you are using strong hashing algorithms for your database storage, then in the end it's going to be impossible for them to figure out the passwords.
The weak passwords, they'll figure out.
The strong passwords, they won't.
So, a compromised database is not as severe if you do hashing.
That's why it's important that we do this.
The other option you'll see here was what?
The other algorithm type.
So, let's go ahead and type in username, algorithm type, and it was script.
We'll type in secret, and we'll also put in Cisco.
So, you'll see the difference between all of them here.
So, script is called level 9 encryption, but it still hashes.
SHA-256 is called level 8 encryption, but it hashes.
And MD-5 is level 5 encryption, and it hashes.
And then we have our plain text.
Now, we don't want plain text passwords to be plain text in our operating system.
It doesn't make sense to do so.
So, number one is if you have plain text passwords, but there is the ability to hash,
then you should be doing the hashing like you see here.
But if you don't have the ability to hash, then you need to actually encrypt those passwords at a minimum.
You can't leave them as plain text.
So, we have an example of that.
If you type in do, show, run, pipe to section, line, what are we going to see here?
We're going to see that this is in plain text.
This is in plain text.
But there is no hashing option for those ones.
So, I cannot hash.
So, since there's no hashing option for them, we have to do encryption.
So, how do we encrypt all plain text passwords that exist in our configuration, folks?
And any future passwords we create, how can we do that?
The command is service, password, encryption.
Exactly.
Service, password, encryption.
So, by typing this in now, if we look at the output, you'll see that password is now encrypted with level seven encryption.
And notice that encryption produces different results.
You see that?
Whereas hashing always produces the same result if you're not using salting.
So, hashing would always produce the same result if you're not using salting.
But encryption produces a different result every single time.
And that's important, because don't forget, with encryption, we can also decrypt.
We can encrypt and decrypt.
So, the end result here is that we are actually really encrypting here.
We are not just what?
We are not just...
We're not hashing.
We are actually encrypting.
So, this, though, is not all that valuable of a solution anymore.
Why is that?
The reason why is because these passwords can easily be compromised using web-based tools.
Legit web-based tools.
So, let's just show this.
I'm going to go ahead and take this encryption.
I'm going to copy it.
I'm going to get it off this device here.
So, I'm going to go here.
I'm going to go here.
Then I should be able to grab it now.
And let's paste it in.
And let's click reverse.
And boom!
There you go.
That quick.
A website was able to...
Now you might say, okay, come on, Ryan.
Use the word Cisco.
Give me something with more substance.
That's a very bad demonstration.
Okay, fine.
I'll give you something with more substance.
So, let's do this instead.
Let's go to line VTY 0 through 4.
And let's put in a password of what?
Let's just totally randomize it.
Just totally random.
Garbage nonsense.
Let's do that.
All right.
So, hit enter.
Oops, show run pipe to section line.
Wow, it's a lot longer.
Now, I'm pretty sure it's not going to get this one.
It's going to get close, but I don't think it's going to get this one.
Because there's dashes in there and other things.
So, I'm pretty confident that it's not going to get this one.
Right, and it didn't.
Okay, but look.
It was close.
So, think about this.
How many more characters?
1, 2, 3, 4, 5, 6, 7.
Okay, and this was only what?
This is a website.
Imagine if I had a tool locally installed on my supercomputer.
I would figure it out then.
I would figure it out.
So, this is just to show you that although this is encryption, it is
not all that great.
But it's better than not doing it.
It's better than not doing it.
So, Cisco says you're better off to do this than leave those passwords in plain text.
So, at least they are not easily readable.
Now, back in the day, awesome.
Awesome solution.
Service password encryption, awesome solution.
Why?
Because if you were looking over my shoulder and you saw something like this, there's no way you can memorize that.
Everybody agree with that?
There's no way you can memorize that if you were looking over my shoulder or you saw my screen or anything like that.
Or even captured it.
The odds of you being able to decrypt that back in the day when service password encryption was invented was next to none.
But today, you've already seen how easy it can be.
And also, could I just do this?
Snap picture behind you or pretend I'm on the phone as I'm walking behind you.
So, it just goes to show that we as administrators, from a security standpoint, we need to apply the Jedi principle.
That's right, the Jedi principle.
What's the Jedi principle, folks?
Does anybody know it?
What's the Jedi principle?
One of them anyways.
Be mindful of your surroundings, young Padawan.
That's what you want to apply in your security career.
Use that as one of your security rules.
Be mindful of your surroundings.
So, never, ever display configs or anything like that where people can see them from behind you.
And it might be nice to have that corner office.
But if you're responsible for highly mission critical sensitive information and you are in a corner office and your monitor faces out the windows,
meaning people outside could see, even if you're on the 50th floor of a building, if there's other buildings around you,
could people look in from those buildings into your building and see what's?
Yes.
And you might think, no, the odds of that happening are next to none.
All it takes is once.
And you're compromised.
That's all it's going to take.
And if somebody is really after your company, after your business for whatever reason,
they'll spend the time to set up shop next door and have a telescope, binoculars, and see what's going on
and use that information against you.
I know it's the stuff that's in movies, but it actually happens in real life.
So, be mindful of your surroundings.
And this is better than nothing today.
I'm going to protect you from, though, the eavesdropper over your shoulders.
It's been another building because they'll just use a tool and crack it after the fact.
All right.
But you know all about that.
Now, I've got to teach you about the reverse of this.
So, if I type in no service password encryption, what does that do?
I want you to remember this.
If I type in no service password encryption, what does it do?
It ensures that going forward, no plain text passwords will be encrypted.
That's it.
It will ensure going forward, no plain text passwords will be encrypted.
But does it decrypt?
Does it decrypt?
And the answer to that is no, it doesn't.
You see that?
It does not decrypt.
They're still encrypted.
So, service password encryption encrypts all plain text passwords and any future plain text password you create.
But if you shut off the feature, then all it does is stop encrypting passwords going forward.
So, now if I go to, for example, line VTY zero through four, and I type in password Cisco,
you're going to see that now the password's in plain text.
Why?
Because I shut off service password encryption.
And then I created a new password, so it's not going to encrypt that password.
Because I told it, do not encrypt any more passwords going forward.
There's a lot of little things you've got to remember here for the certification exam.
Any one of these can show up.
All right.
So, now let's back out of here.
Let's remind ourselves.
Hit return to get started.
Type in my username.
Type in my password.
We are in user exec mode right now.
So, I have to type in enable to go from user exec mode to privilege exec mode.
So, I just elevated my privileges without having to what?
Verify that I'm allowed to use privilege level 15.
So, we need to protect this command, the enable command.
How do we protect the enable command?
We can apply a password to the enable command.
So, let's type in configure terminal.
We'll type in enable password.
And we'll type in a password of Cisco, just so I don't forget.
Do show run pipe to section enable.
And you'll see here that we have an enable password of Cisco.
So, if we log out of here now.
And we type in enable.
You'll see that it asks me for a password now as well.
To go into privilege exec mode.
However, this is in plain text.
So, what is one of the ways that we can protect this?
Well, we could use service password encryption.
That's one way.
What's another way?
Well, we do have the enable secret option.
So, enable secret allows us to hash that particular password.
Notice that it says, hey, hey, hey, hey.
The password you chose here, Raymond, for hashing is the same as the one that's in plain text.
We recommend that you do not do this.
We'll let you do it, but we recommend you don't do it.
Why?
Well, if we type in do show run.
You'll see that the plain text password is still there.
So, when you use enable secret, it doesn't replace your enable password.
Now, is the enable password being used?
The answer is no.
The enable secret is being used now.
But the problem in this case is that if my enable password is Cisco and somebody captures it and they try it, it's going to work.
So, you never want to have these two passwords the exact same.
In reality, if you're going to use enable secret, don't even use enable password because it doesn't matter.
Get rid of it.
Delete it.
Make sure it's out of here.
So, this is using MD5.
Remember that.
MD5.
That's what five means.
Right?
But what about maybe changing a different algorithm?
So, algorithm type.
In this case, let's go with SHA-256.
Let's then type in secret.
Let's then type in our password.
And if you look, it actually replaces.
It replaces enable secret.
So, you can only have one enable secret.
And now that I'm using algorithm with SHA-256, you'll see it says eight.
And we have a much bigger hash for that.
Now, the problem with the enable password is that everybody's going to have to share it.
So, right now, how many users do I have?
Do, show, run, type a section, user name.
So, Raymond, Conrad, Casey, Andrew, Alan.
If we're all going to be administering this device, then we all need to know the enable password, which is not good.
Which is not good.
Because if we all need to know the enable password, then that is one password that we're sharing amongst ourselves.
So, is there a greater chance that Raymond, Conrad, Casey, Andrew, or Alan could accidentally leak the enable password?
Possibly.
What is the typical rule of thumb when it comes to passwords?
Well, one, you don't want to share them.
And two, if there's some type of shared password, we want to limit access to it.
Or ensure that nobody can use it if there's a way to get around that.
So, for example, Raymond, Conrad, Casey, Andrew, and Alan all need to know the enable password.
If that's what we're going to choose to do, that's what we're going to have to do.
But, we can force, with our usernames and passwords, the ability to automatically be put into privilege exec mode.
So that way, for example, when Raymond logs in, Raymond will automatically end up in privilege exec mode and not have to know the enable password.
So, we can do that by typing in username Raymond, then you type in privilege level, and say privilege level 15.
Then you can type in the password that you want, or secret or algorithm type and all that fun stuff.
Now, if we look at Raymond, we're going to see here that Raymond says privilege level 15.
So, if we exit out of here, when Raymond logs in now, watch what happens.
Pay attention to the prompts.
You'll see Raymond's already in privilege exec mode now.
Raymond does not have to provide the enable password.
What does that mean for you now?
It means that you could, let's say I was the ultimate administrator.
I'm the enterprise level of min.
I could create the enable password, and we could store it in a safe somewhere.
Let's say in a safe that finance has access to only.
They're the only ones who know it.
If anybody wants access to that enable password, they're going to have to ask a specific person in finance,
or two people in finance to get it.
We'll have to sign off on it, and let's say it's in a sealed envelope.
In that way there, it's not something that anybody knows, except for one person, and it's in the safe.
So, if anybody ever compromises the enable password, well, then they're going to have to sign off on it.
If it's the password, well, then there's only one person that's accountable for it, and that would be me in that case.
Nobody else is.
So, if it ever gets out, how did it get out?
So, if we turn around now, and we give everybody, Conrad, Casey, Andrew, Alan, privilege level 15,
then none of them need to know the enable password,
and the enable password would be essentially protecting us from what?
Let's say a cyber criminal somehow gets themselves into user exec mode,
either through the VTY lines, or through the console port, or maybe through the aux port.
If they do happen to get themselves into user exec mode, then now they need to know the enable password,
and the only person who knew it was Raymond,
and Raymond created a really strong, ridiculous enable password,
wrote it down, put it in an envelope, put it in the finance safe.
Well, I didn't, finance did, and we actually have a process for signing it out if we ever need it,
and then maybe our rule is if we ever use it, then we're going to have to change it.
So, it's like a one-time use kind of thing.
Every time you use it, you got to change it to something else,
and then put it in the envelope, and put it away in the safe.
So, just things to keep in mind.
You're not going to be really tested on like that aspect,
but you'll see here that by using Privilege Level 15, you can bypass the enable password,
and that might actually be a good thing for your security requirements,
so not everybody has to share that enable password.
Now, let's go ahead and talk about Telnet versus SSH.
So, right now, we have Telnet access to our device.
We don't have SSH access.
So, if I type in SSH, well, actually, do I?
I probably do because SSH would be on by default on that device because of previous configs I've done before.
So, yeah.
So, SSH would be allowed automatically here right now.
So, let me type in Raymond.
Let's put in the IP.
It should be anyways.
Let's check this out.
Yeah, it is.
All right.
So, let's just talk about how we can set this up because right now, it is working.
It is functioning, but we need to know for the certification exam how we would actually set up an SSH connection on our device so that it can work.
So, basically, turn R1 into an SSH server when it's all said and done,
and the reason why it's already working right now is because of previous configs I've done in the past that are still installed on this particular device.
But first and foremost, what's the difference between Telnet and SSH?
Can anybody tell me what's the difference between Telnet and SSH besides port numbers?
Telnet is port 23.
SSH is port 22.
Telnet is port 22.
On-red says Telnet is clear text.
Telnet is plain text versus SSH, which is encrypted, encrypted communications.
And so, you can kind of see that here, right?
When I did my Telnet session, it was pretty snappy, wasn't it?
It was pretty snappy.
Boom, we're in.
No, I don't want to log in.
Leave me alone.
Ah, typed in the wrong password.
All right, good.
All right, but if you do SSH, you see it's taking a little bit longer.
It's taking a little bit longer in order to have.
I know it's, like, minuscule, but there is a slight bit of a delay.
Why?
Because of encryption, because of establishing that SSH connection.
Encryption, because of establishing that SSH session with encryption.
So, what are the things we need to be aware of for the certification exam?
So, first of all, when we're setting up SSH for the certification exam,
we are doing it with local cryptographic keys that are locally generated on our device.
So, we're not using any type of keys that were generated outside of the device,
like on a hardware security module and imported onto our device,
and we're not setting it up so that way there.
If we want to use security keys, you know, we're using certificates or anything like that.
We are straight up using local cryptographic keys for SSH.
So, that's what our coverage is going to be today.
So, when it comes to somebody like R1, how do we accomplish that?
Well, first and foremost, you need a hostname.
And we have a hostname by default on our device.
Our hostname by default is router.
It always is.
And so, whatever you change your hostname to is going to be used as part of the cryptographic key generation.
So, something to keep in mind, that on the certification exam,
if they're telling you you want your cryptographic keys to be named a certain way,
well then, that is based on your hostname.
So, your hostname would have to match what you want your cryptographic keys to be named.
So, if you ever need to change the hostname, it would be hostname, and then you put in the hostname.
So, let's do Han Solo today.
So, Han Solo now is our hostname.
What we also need to generate our own local cryptographic keys is a domain name.
Now, when we talk about domain name here, it could be a registered domain name,
but it doesn't have to be because we're generating local cryptographic keys.
So, that domain name is not something that needs to be reachable, accessible, registered, or anything like that.
So, it's about coming up with a domain name that is going to be used for just this particular process,
and whether it's just for this device or a multitude of devices, it's up to you.
So, you would type an IP domain name, and then you would specify your domain name.
So, let's say the falcon.local.
So, not something that is registered.
It's just something we came up with in our organization that we are going to use
for locally generating cryptographic keys for Han Solo.
So, now we've got a combination of a hostname and a domain name.
Now, what we can do is we can generate our cryptographic keys.
So, the command for that is crypto key generate, and we're going to use RSA keys.
There's other types of keys you can use, but in this case, we're going to use RSA.
That's what you've got to know for this certification exam.
And then you've got to specify the modulus.
The modulus just means the size of the key.
So, what's the size of our key?
So, the recommendation nowadays is nothing lower than 2048,
but if they tell you on the certification exam, whatever they tell you, that's what they want you to do.
So, if they say 1,000, then put 1,000 in.
Just do what they say.
So, my hostname, my domain name, and then generating my keys.
And these are going to be non-exportable keys, meaning that they're only for this particular device.
So, I'm going to hit enter here, and you'll see that they're naming the key HanSolo.theFalcon.local.
So, if, for example, like on the exam, they say you want your cryptographic keys to be named da-da-da-da-da-da-da-da,
well, then just think about it.
Whatever comes in before the first dot is going to be the hostname.
Whatever comes after that is the domain name.
So, that's all you want to configure.
Just configure the hostname based on this first parameter,
and then configure the rest of it as what?
As the domain name.
That's how you're going to accomplish that.
And then generate your keys.
And you'll see that we've got some non-exportable cryptographic keys that are 2048 bits.
Now, what I want you to realize is that once you have one cryptographic key on your device, SSH is automatically enabled.
That means you don't have to turn on SSH.
SSH automatically gets turned on.
Now, SSH was already turned on on my device because I had a cryptographic key from the last time I did a demonstration on this device.
But if you did not have any cryptographic keys on your device and you generated this key,
as soon as this was done, it would say SSH enabled.
It would actually show a syslog message that says SSH is enabled.
Because SSH would have been turned on automatically on your device.
So, as soon as you have one cryptographic key on your device, SSH automatically gets turned on for you.
Take off your cryptographic keys, SSH would be shut off on you.
So, if I type in do show ip ssh, you'll see that SSH is now enabled with version 1.99.
So, version 1.99 means version 1 and version 2.0.
It's actually something like version 1.5 and version 2.0.
So, that's what 1.99 means.
Now, this particular device, if I type in ip ssh, you'll see there's a version option down at the bottom.
This one only lets me do both or version 2 by itself.
I cannot revert down to version number 1 on this particular device.
But if you could, it would say ip ssh version 1 or version 2 or both when it's all said and done.
So, now that I'm using ip ssh version 2, you'll see that it actually says version number 2.
Let's say on the exam you look at this output and it said version 1.5.
Version 1.5 would mean version 1.
Version 1.99 is version 1 and 2 support.
Version 2 means just version 2.
I don't make up the numbering scheme.
That's what it is.
All right.
So, with that in mind, now that we have it set up, we have our cryptographic keys generated.
What else must be done?
So, we have our host name, our domain name, our cryptographic keys.
I turned on SSH version number 2.
What else?
Well, our VTY lines because that's how we use SSH, through the VTY lines.
Do, show, run, pipe to section line.
We're going to see here that we have log in local, which is what we need.
So, you cannot use the line password.
You need at a minimum a password stored in the local username and password database.
The other option is a username and password stored on a RADIUS server or a TACACS plus server,
which would require AAA to be set up on your device.
But right now, we're just using our local username and password database.
So, log in local.
That's what it means.
That's perfect for this scenario.
And then let's not forget about transport input and SSH being specified.
Because we have to have SSH in that list or SSH would not be allowed as a connection method.
All right.
So, now that we have that done, let's go back to DSW1.
Let's try our SSH connection.
And I put in my name, Raymond, and now I can go ahead and put in my password.
And I'm now connected to Han Solo using SSH.
So, now I have an encrypted connection between the two devices.
Now, something I want you to consider as well is securing your VTY lines with an access control list.
So, let's go ahead and do this.
Let's go ahead and create an access list.
Let's go ahead and create a standard access list.
So, access list, let's say number five.
We'll say deny.
Let's specifically deny who?
Let's deny DSW2.
So, if we go to DSW1 right now, this is the command we've been using.
Let's go over to DSW2 and enter that command to show you that we do have the ability to SSH in.
Okay.
So, that worked for us.
But let's go ahead and deny this device based on its IP address.
So, let's type in do show IP interface brief.
And let's go ahead and deny, for example, connections from this, not this IP address, pardon me.
We'll go with this IP address right here.
So, back over to R1, deny host, ma'am.
Access list, five, permit, any.
Then let's go back to our VTY lines.
And the command is access class.
Then you specify the access control list you created.
And then you specify the direction.
So, when we're making inbound connections to the VTY lines, I want to deny this host but allow everybody else.
So, let's give this a try.
Let's go over to DSW2 now and try that SSH command again.
And you'll see it says connection refused by remote host.
But if we go over to DSW1, you'll see that everything still works perfectly fine because of the permission.
They're permitted based on that access control list, whereas DSW2 is denied.
So, keep that in mind for the exam, that if you look at the output of show run pipe to section line,
and you're looking at that VTY line and you see something like this,
it means there's an access control list applied to those VTY lines that are going to control either inbound
or outbound Telnet or SSH connections, so remote access connections.
So, do show run or do show access hyphen list five, and you'll see that there you go.
So, little things to keep in mind at this CCNP level.
All right.
Let me just take a quick peek at my notes really quickly here to see.
Okay.
We covered that.
It's all good.
We've covered all of that.
We've taken care of all of that.
Okay.
A few little things here that I've got to do on the side for you.
Commands like logging synchronous and exec timeout.
So, right now, you'll see that there is no timeout value listed here for the console port or the VTY lines.
But is that true?
No, that's not true.
There is a default timeout of 10 minutes.
So, if I type in show line console zero, you'll see there's a default timeout of 10 minutes.
Did I say 10 seconds?
I meant 10 minutes if I said 10 seconds.
So, 10 minutes is your default timeout.
Same thing with your VTY lines.
So, if we look at VTY line zero specifically, you'll see there's a default timeout of 10 seconds.
What about one?
Default timeout of 10 seconds and so on and so forth.
So, how do we change that?
Configure terminal.
Type in line console zero or the VTY lines, whichever one you want to do.
And the command is exec timeout.
Exec timeout.
And then it's minutes that you specify.
So, for example, just put zero minutes right now.
And then the number of seconds for it to timeout.
So, we'll go with five seconds.
Five, four, three, two, one.
There you go.
That's all it does.
So, any inactivity now, you'll be timed out after five seconds.
So, what are you going to choose for your own environment?
You're going to choose whatever makes the most sense for your environment.
So, whatever your policies are that you have set up for timeouts,
then you're going to want to make sure you apply those timeouts on your device.
So, 00 is not something you're going to do in a production environment.
00 is for what?
It's for environments where you never want it to timeout.
So, 00 means never timeout.
So, half decent for a lab environment if it's something that you're allowed to do.
But keep in mind that that would be a no-no in a production environment.
But I'm going to leave it at 00 here so I don't get timed out.
And lastly here, while I'm still in this discussion, let's go ahead and hit end.
And I'm going to start typing.
How many of you have this problem right now?
I always ask this question because it amazes me how many people don't know this little feature exists.
So, how many of you have this problem where when you type,
and all of a sudden you have a syslog message that appears, you end up continuing to type here?
Anybody have that issue right now on your device?
Nobody this time around?
Nobody?
Excellent.
Okay.
So, two ways to overcome this.
Method number one is just hit the tab key.
Just hit the tab key.
That's it.
I'm going to hit the tab key, and you'll see what it does is it builds a new prompt
and retypes everything out for me.
So, any time you hit the tab key, that's what it does.
Build a new prompt, retype everything.
That's just hitting the tab key, T-A-B, tab.
But there is a feature that you can turn on in your device.
If I type in configure terminal, line console zero.
This is true for the VTY lines as well.
It's called logging synchronous.
Logging synchronous.
You turn this on, and it does it automatically for you.
So, let me show you this now.
I'm going to start typing, and you'll see it automatically, when the syslog message arrived,
gave me a new prompt, rewrote everything I already had, and allowed me to continue typing.
You never know when that shows up on an Encore exam.
It could.
I am not kidding.
But I'm basically asking you, how do you resolve something like this situation here?
I said tab key or logging synchronous.
Keep that in mind.
So, we've covered that, got that, got that out of the way.
Looking good, folks.
This is all notes I have to make sure we're ready.
There's another command I want you to remember for the username.
So, if you build a username, look at auto command.
Read that.
What does it say?
Automatically issues a command after the user logs in.
So, here's the thing.
Any type of situation or scenario in the real world on the certification exam that says,
you need to create a user account that, once logged in,
it automatically executes a command and then logs that user out.
Meaning that's all it can do.
It can't do anything else.
Then you create the username with the auto command option.
And therefore, if you connect with that username, you type in the username,
if you connect with that username, you type in the username,
you type in the password, then that command gets executed,
then you get kicked out, and you get just the results,
and you can't do anything else.
Just in case you need to know that.
That's why I'm bringing it up.
All right.
As you can see, there's a lot of other things that we're not going to cover
that go along with usernames as well.
But I'm just trying to stick to things that are possibly on the exam.
All right.
Notes are good.
We covered Enable Secrets, No Service Password Encryption,
Service Password Encryption.
We nailed that stuff.
Telnet versus SSH.
We've got that covered.
Let's see here.
Access Class for SSH or just your VTY lines.
That is, we've got you covered there too.
And there we go, folks.
That is the end of this discussion.
So, so far, I've covered everything I wanted to cover in that particular
section of the course to get you ready for the certification exam.
As you can see, there was a lot that we covered there.
But it was all about what?
Device access and authentication from what perspective?
Using the lines, using the local username and password database.
We didn't do anything AAA in that discussion.
So, what does that mean?
It means that our next discussion is going to be about AAA
and how we can use that for our authentication and device access.