Original subtitles

>> I want to show you something kind of creepy.

[laughs] How's that for starting a nugget?

So last, last nugget, we kind of went through the base configuration of our switch, right.

I'm back on the console port now.

We set it up with a management IP address.

All right, that's it, I'm changing the password.

I can't talk and type CBT nuggets at the same time.

I'm going in, enable secret, Cisco, there we go.

Something I can brainlessly type.

Oh, there is a fun message.

[laughs] Well it sounds like-- I want to show you something now,

something totally different than what I planned to show you.

It says, the enable secret you've chosen is the same as your enable password,

this is not recommended, please reenter the enable secret.

Remember, we talked about in the last nugget, actually two nuggets ago,

difference between enable password and enable secret.

Now, when I said enable secret is Cisco, what the Cisco device is saying is, "Well,

that's the same thing as your clear text version," or, you know,

the cracker jacks encrypted version right here.

They're like, this is not recommended.

Now, let me ask you this, in that message anywhere, does it say, I didn't take that?

No it didn't.

It actually will take it just fine.

The enable secret is indeed, Cisco, Cisco just wants to try and sway you as much

as they possibly plan not to do that or at least, to go in here

and do a no enable password, which I think I did in the last couple of nuggets,

but I obviously didn't save my configuration so I'll do that now.

So anyway, back to what I wanted to show you, we assign an IP address to this switch right here

so that I can manage it remotely.

And then, as kind of the culmination of that configuration piece, I said, well let's do this.

I've got my computer, let me grab my pen.

I've got my computer plugged into that switch at 10.1.1.--

I think I gave it 100, and here's the switch, it is assigned 10.1.1.10 and that's--

by the way, the only thing this IP address is used for is management purposes.

So I was like, "Hey, well let's Telnet in."

This is what I wanna show you.

Remember early on in the series, I opened our good friend WIRESHARK.

And I know early on, you're probably like, "Okay, that was intense."

WIRESHARK is intense for most people that are just getting started in the Cisco world.

So I'm going to get you familiar with it, 'cause it is a huge troubleshooting tool

to where you can see information at every layer of the OSI model.

And here's what I want to show you, I'm going to open a capture.

All right here, and I have the-- a network adapter, that I have connected to the switch,

is actually this little USB 2.0 Fast Ethernet Adapter.

And now you can see, there's not much going on in my network.

I had some stuff, maybe some, I don't know, something going on there.

But not much going on because I'm not really doing anything.

So I will say, "This is the one I want to capture, let's do a start."

So WIRESHARK is now monitoring the app where it's seeing some, you know,

occasional spanning three messages which we're going to discuss that a little bit later.

But I'm going to open up a Telnet session.

Wait a second, not like that.

I'm going to do a-- there we go, Telnet 10.1.1.10 behind the scenes.

And I should see, there we go, you know, I've got to change that login message.

Behind the scenes, notice WIRESHARK is like, "Oh, I see Telnet data, Telnet data."

Now down here, it's like, okay that's all just kind of gobbledygook.

So, just kind of ignore that for now.

So I'm going to login and I'm going to say, "Okay, my password is Cisco," because, you know,

that's my Telnet password [phonetic].

Again, behind the scenes, WIRESHARK is like, "Munchy, Telnet data."

I'm going to go, "Okay.

Well, let's get into publish mode."

Cisco, type that in and hit the enter key, and okay, I think that's enough.

Let's go in and stop that capture.

Now, in here, WIRESHARK is like, "Okay, I've captured all these data."

Now, if I really want to say, "Well, what was that data that you captured?"

Now, this is layer 2 of the OSI style model.

It's saying, "Okay.

Well, it was from this source MAC address,"

my little Apple USB adapter going to this destination MAC address.

I'm using these IP addresses, you can see the source IP and then there was a lot more stuff

in the header than source and destination IP, but source is 10.1.1.100, destination, I mean--

so all of that-- we saw this previously, I can go through every layer.

But really, at the application layer of the OSI style model, it's saying,

"I captured SC [phonetic], and then I captured O."

Oh wait a second, that sounds a little familiar.

I captured I, let's see, where did that come in?

I captured slash R-- oh, what is this?

Well, there's a little feature in WIRESHARK

where you can actually analyze and follow the TCP stream.

What that does is it tells WIRESHARK, you know what, this is one stream.

I've highlighted one stream of data right here.

How about-- can you just kind of follow that and put that all back together?

Panic. Heart attack, what?

What? What's the deal here?

And then everything that I just typed in.

I Telneted the switch and immediately, it's like,

I saw a logon banner come across, user identification password.

All of a sudden, it's in red, Cisco.

And then all of the sudden, I see this enable, you know, it's kind of like, okay what's this?

And then, it's in red, Cisco.

You know, what's the colors represent?

Can anyone figure that out just by looking at it?

What's the colors represent?

It's the send and receive.

So essentially, the blue is what my computer has received from the other side,

the red is what I've sent to the other side.

Now you know, when I was-- you saw it, when I Telneted into the switch,

I couldn't actually see the password.

And that's because the device did not echo it back to me.

Everything that you typed in Telnet is actually echoed back.

You see, I typed in enable which my computer actually sent, you can the red E N--

well it's hard to highlight just-- you get it, you see the red, right?

That's what I sent.

And the switch actually echoed that back to me.

It's like, "Okay, you sent an e-- let me echo it back."

And that's how my terminal displays it.

And that's really the only difference is when I typed in the passwords,

the switch turned off the echo back.

So it's like, "Okay, you've sent it to me but I'm not echoing it back."

But is there-- did anyone see a problem with this picture?

[laughs] I mean all of my-- what I thought was a secure password is now exposed.

And if somebody in your environment knows what they're doing with WIRESHARK,

it's going to expose the passwords that you're typing as you're logging into the switch.

So I do this little let-me-show-you demonstration to demonstrate

that Telnet, not a good protocol.

Not-- I mean, good, it's functional but not a secure protocol because if anybody has eyes

to see that communication that's going between you and the device,

they will be able to decrypt-- well, decrypt is not even encrypted,

they will be able to see everything that you're typing because Telnet is in clear text.

Now, I don't even know if I should say this but I want to because I want to tell you the truth.

So let's say you are sitting at your desk and you Telnet your device.

Does that mean you're totally doomed?

Like, somebody, you know, somebody just grabbed your password

and they are now going to hack your network?

Or, you know, worse yeah, let's say you're sitting on that beach in Hawaii or at home

and you Telnet across the internet to a firewall that you have over here.

And so, you're actually Telneting, you're sending all

of that in clear text over the internet.

Does that mean that the evil beings out on the internet immediately see that communication

and will now hack your firewall because they have all the passwords necessary?

Chances are good that that won't happen.

First off, and so-- now, I don't want to give you a false sense of confidence

because it is still true, still valid that Telnet is not good to use.

But first off, in your environment, one of the things that switches do,

and let me bring up my drawing a little bit more, one of the things that switches do is--

wait a minute, my brain just shaked out.

Okay, switches separate into separate collision domains.

So let's say that your router is right here, and your computer is plugged

in right here, and I Telnet from here to here.

Well, that communication only goes between your computer and that router.

It's not like a hub.

In the hub days, I would say, there's much more of a chance of you being doomed

because anybody-- if this were a hub, anybody could open WIRESHARK if that wanted to

and see all communication on the network.

But if I'm directly Telneting from my device to that router, that firewall, well,

it's only coming in my port and coming out at this port.

So if somebody over here, you know, here's evil person X that has opened WIRESHARK

and they're sniffing packets, they actually won't see my communication unless they start

sabotaging your switch.

There's a little program that anybody can download, it's free called Can and Able.

It is like a Swiss Army Knife of hacking tools that are kind of like point and click, like,

you click a few buttons and you unleash a hacking attack.

One of the things that they can do is unleash what's called a CAM Table Overflow.

See, CAM stands for Content-Accessible Memory, right?

It's where your switch stores all the MAC addresses that it knows about.

So that if they do this successfully, what will happen is their computer will send thousands,

and thousands, and thousands of packets into the switch sourced from different MAC addresses.

So the switch is like, "Okay, I've learned about this, and this,

and this, and this, and this, and this."

And their goal by doing that is to fill up the CAM table to where there are

so many MAC addresses stored in there that switches like,

"I'm out of memory, I can't store anymore."

And what the switch does at that point is turn itself into a hub.

It's like, "Well, if can't store anything, if my CAM table is full, then I'm just going

to forward everything everywhere because I don't want communication not to be received."

So as soon as that happens, now this evil person can capture your Telnet session.

But my point is that, it's going to take a little bit of work for them to do that, okay?

So it's not as easy-- I mean like, obviously, it's easy for me because I'm actually

on the computer that's doing the Telneting, you know?

And if I'm on that computer then, you know, for sure I can capture that.

Or if somehow this computer is compromised, as in there's a worm

or some creepy thing that's installed on it, a keystroke logger.

I mean there's all kinds of way to hack a computer.

But that's-- it's not just as easy as opening WIRESHARK anywhere

in the network and capturing passwords.

And the same thing on the internet.

If I Telnet across the internet, that's really not a good practice,

but does that mean we are destroyed immediately?

Well, I would say no simple because there is so much data going around the internet

that you're almost secure in obfuscation towards-- it's just like, by the sheer quantity,

you know, terabytes and terabytes of data every minute are being transferred all

around the internet, you know, who's to say that somebody is going to grab your Telnet session

in there and it would also mean that someone in the middle of your communication is going

to be doing the grabbing, as in you, you know, maybe came in through your Cox or Quest,

you know, what-- or some kind

of service provider that's giving you your internet connection.

So there would be an evil person sitting there that could capture it, or, you know,

they pass it to, you know, level three or Time Warner, you know, these big service providers.

You know, and so there somebody evil, they're so-- so for those things to happen,

for somebody capture your Telnet session, there would have to be a shady person existing at one

of the service writers that you're going through and they would have

to find your conversation among trillions of conversations

that are happening across the internet.

So what I'm saying is, there's different levels of paranoia, right?

There are some people that are like, you know, I type my credit into a website and it's gone,

I know, somebody is going to sell that, and steal it, and I'm defrauded.

I mean, there's people they're like agent [inaudible] is standing outside my door

or waiting for me to use my computer because then they will know everything that I'm trying

to do, so there's different level.

And then there's people that, you know, that are kind of like, hey, you know what,

the world is happy place, there are no hackers, you know, it's all-- you know, it's--

there are totally different levels of paranoia.

The best thing to be, I would say, it's probably better to be over paranoid than less

because it's less chance of something bad happening.

But just to put into a reality, the world isn't waiting to hack your Telnet session,

there are certain people that wish they could,

but it's going to be very difficult for them to get that.

All of that is a precursor to managing your Cisco the right way, using SSH.

Now I know some of you might be thinking-- well, that was kind of a long precursor, right?

Well, yeah, but there is so much meet in there, you know, I have seen how to use WIRESHARK

to follow a TCP stream and reassemble data, you can do that with anything, outlook e-mails,

Excel spreadsheets, anything that are being sent.

At the time, you can capture and reassemble and put it back together.

We saw how clear text to Telnet was by design, that's just how the protocol what was written

and that-- but at the same time, how using it, doesn't mean that big brother suddenly comes

down and says, I have the keys to your network.

But it-- you know, as point number four, why risk it?

I mean what's the chance that somebody is going to grab your data and hack you, one and ten,

one and a hundred, one and a million, it depends on where you are in the world and what kind

of malicious person would want your data.

But the point is, why take that chance,

why add that to one more thing that you have to worry about.

Instead, go with Cisco's recommendation, use Secure Shell, or SSH to manage your network.

Now before I show you how to set it up, I want to show you how it works

because when you understand this, you understand how--

almost all major security algorithms worked across the public internet,

you'll be able to explain how VPNs work, how secure web surfing works

because they all use the same method as SSH.

Essentially, you have a client that wants to have some kind of secure session

with his server, or, you know, a router, or a switch, or whatever you want to do

over some untrusted network and, you know, just about any network unless, you know,

I can own every single piece of cable in there

and know exactly what's on it, is an untrust medium.

So, let's just say we've got the internet.

I'm going to show you how it works for, you know,

secure web surfing and then, I'll apply it to SSH.

Now let's say we go to HTTPS, you know bank.com, whatever online bank we decide to use.

Now the big question is, how do I know that this is secure, I mean, HTTPS by the way uses, SSL,

Secure Socket Layer or it's the same concept as SSH.

How do I know that this is secure, I mean, if you think about it in order for security

to happen, the server or the client has to send an encryption key

which is essentially a mathematical formula that says, here's how I'm going to encrypt my data,

that's kind of like a secret key that only those two can have.

Well the problem is if there's eyes on this network, if this is untrusted network,

then that's the problem, because if I send the key,

then anybody can grab the key and we're doomed.

Well, that's the same problem that a fellow named Martin Hellman

and Whitfield Diffie faced decades and decades ago.

It's how do you have security over a public network when you can't send security keys

in clear text that anybody can grab?

And they came up with a method of public-key cryptography.

So here's how it works.

Essentially, the bank will have what's called a certificate.

And that certificate will have an encryption algorithm on it, it's known as the public-key.

Now, the public-key is half of an encryption formula.

So essentially, anything that is encrypted with the public-key can only be decrypted

by something called the private-key which is kept

on the server never, ever, ever given out to anybody.

Because if I give out that private-key to anybody then this whole algorithm fails,

because now anything can be decrypted.

Now, have you ever going to a website and it comes up and you get that message

in Internet Explorer, or Chrome, or Firefox, whatever, and it comes up and says,

warning this website not trustable, you know,

this website has a certificate that is not trustworthy.

Well, you know, and most of us, if you're like me and like, yeah, whatever, you know,

and continue, I want to get to the website.

Well, that message hid-- it gives you a warning because what it saying is,

this server may have just made up their own certificate.

As in nobody has gone out and really said that this website is secure and this website is

who they say they are, that's why we have this concept of certificate authorities.

Places like VeriSign and all of that kind of stuff.

I'll just throw VeriSign out there is one of them.

So if I was a real company, I would take and apply for a real certificate from VeriSign.

VeriSign would say, okay, let me verify that you are, who you are,

what's your federal tax ID number, what--

you know, they would make sure that you are the real deal,

and then they would issue a certificate and an encryption or essentially public private-key set

that is trusted by all the browsers of the world.

So Chrome, you know, Internet Explorer, they've all agreed that they will trust the VeriSign

as a authority to give out these certificates and approve the servers on the internet

to really be a valid server, now is that proof, no, no it's not.

But it's definitely a good layer on top of it to make sure

that we don't have these false identities out there.

Now, so this guy gets a certificate, whether it was, they made it up themselves

or see I gave it, and this certificate has half of an encryption algorithm on them.

So the very first time, when you got to bank.com,

they will send over this public-key, half of an encryption algorithm.

And your browser, your Internet explorer, your Chrome, your, whatever you're using will say,

great, I am now going to generate what is called a session key.

Now that session key is only good for this one time use only.

Session key is, you know, once I'm done talking to this website, I'm going to flash it.

It is an encryption algorithm, it is called a single key or I guess the technical word

that you would use for it is asymmetrical encryption algorithm.

One key to rule them all, one key to encrypt one key to decrypt, it's fast, it's efficient,

it's what we want to use because we want to have our communication goes

as fast as possible, but also one key.

So I can't just send that one key to the server across the internet

because someone would get my one key and be able to decrypt it.

So you see where this is going?

So I send half of an encryption formula to the client, that's this piece right here.

And this is also by the way called asymmetric encryption.

Multiple keys are two keys to be specific to rule them all.

But veri-- process are heavy to handle this kind of encryption.

So, he sends me half of an encryption algorithm.

This guy says, I'm going to take that public key and encrypt my session key, gone.

It is now scrambled, it's encrypted, and the only one they can decrypt it is bank.com

because they're the only one that has this private-key behind the scenes.

So, now obviously, I knew what it was before I encrypted it, right?

So I now send an encrypted, encryption key.

You think that one through right.

An encrypted-- encryption key over to bank.com who now decrypts it using their private-key,

and now, it's going to be a new color.

We have the session key successfully transmitted and used on both sides for that session.

A fresh encryption algorithm used for that session.

Once that session is done, I tear it down

and the session key is destroyed, never to be used again.

Now, that is how public-key encryption works which is really amazing, it's really powerful

to have that kind of algorithm on the internet as you surf the websites, it's the same thing

that used for SSH, it's the same thing when I have a VPN tunnel, like I want to connect

to my private network using a tunnel over that.

They all used the same kind of algorithm, this public-key.

Now I know some of you are watching this whole thing and be like, "Okay, okay, come on."

If somebody gets the public-key which is, you know, half of an encryption formula,

can't they figure it out the private-key?

I mean, I grew up, I went into some heavy math, you know, X plus 1 equals 3.

If I get, you know, half that formula and I'm like, okay, I don't have a piece of that,

can't they, you know, you see, what I mean?

Can't it be like, well, okay, X is really 2 because I can kind

of reverse engineer this, no, theoretically, no.

But that theory has been proved for decades and decades.

Now I will tell you, if somebody came-- by the way, this is called Diffie-Hellman Encryption

because those two guys, well, actually, there's three guy,

but you got cut out of the loop, no royalties for him.

But they are the ones who pioneered this public-key encryption algorithm.

Now it's since then it's been translated into many different forms, you'll hear things

like RSA, there's all kinds of different methods

of doing public-key cryptography, but the concept is all the same.

Now if somebody ever came out and said, hey, I figured out how to reverse this,

I figured out how, you know, if I get a public-key on the internet, how to fix,

you know, to generate the private-key from it.

You would see worldwide chaos, and panic, and freaking out because people would--

soon they'll realize that the under pending security of everything is now gone,

it cannot be done, I don't know, maybe, I can't do it.

No one is been able to do it so far, the government, well,

as far as we know, Agent Scully can do it.

But the government can't do it, so far it's been proved true, but it's a theory.

The theory is nobody can figure it out how

to generate the private-key if you have a public-key.

But, all that being said I dive into my conspiracy theory side of things.

Now let's talk about how to setup SSH.

I'll clear all of this stuff off.

So that's how it worked.

So instead, you know, instead of having computer A and website B, you know,

we have computer A going to switch A or router A or whatever kind of device,

it's all the same concept, it's just using, you know, different devices.

So the way to configure SSH on a Cisco device is as follows.

First of, we have to have a host name and the reason why is this switch

or this router is going to generate it's own certificate.

Now, it's okay, we don't need a certificate authority because we pay for those.

And as long as we trust our own devices, you know,

we're not going to have a rogue device come in into the play,

it's okay to generate our own little public-key certificate which says who we are.

But we have to have on that certificate the name of our device as well as the domain name like,

you know, jeremy.com or cbtnuggets.com, that's the domain name,

those are two requirements for the certificate.

So not only on that certificate is the key, but also, you know,

your name, who are you, host name.

Also on there is your domain name.

Also on there is the certificate authority that approved the certificate.

And think of this is as like the stamp of approval.

Now in this case, this is called a self-generated certificate that we're creating.

So when it's says, well, who approved me?

I approved me.

And who were you to tell me that I can't do that?

Yeah, that's what the device would say, is, you know, I am on my own certificate authority,

but that means the very first time you connect to this device,

you're going to get a warning say, hey, I'll show you that one, okay?

So here's what we're going to do.

And now, I've already configure the host name for this device, it's CBT Switch.

Now I need to configure a domain name, global config mode

and the command is IP domain name followed by what we want the domain name--

hey I don't have a-- domain, yeah, sorry, it's IP domain name, that's what it is.

IP domain name or it looks like, we can do a space, either one of those, sometimes Cisco,

Cisco is inconsistent, you'll have two ways of doing the same thing.

So IP domain name, we've got cbtswitch., let's do nuggetlab.com,

will be our domain name that we're going to use, okay?

Now we're going to generate encryption keys, we're going to say, I need to generate,

essentially, the public private-key set for this certificate, the private-key,

I will never give out, the public-key, anybody can have because it's only half of the formula.

So the way I do that is I do crypto key generate RSA.

RSA by the way is the encryption algorithm of choice on Cisco devices, I think,

it stands for Rivest, Shamir, and Adleman, it's three guys that developed--

it's, you know, think of it as Diffie-Hellman, but just the next flavor,

a little more efficient than Diffie-Hellman's original algorithm.

So now we come to the big question, what is the size of the modulus?

What is this-- how strong do you want this key to be?

Now let me give you just a flyby view.

Symmetric keys that we use normally for--

remember I said, this is the session key

that our computer generates to communicate without website.

Symmetric keys common strengths are, you know, on the low and 64 bit.

Normally, nowadays is 128 bit or if you're beefy,

nowadays you'll use 256 bit encryption for your symmetric keys.

And that's just how strong the key is, how complex is that mathematical formula

in that shell, that's really what it means.

So those are common methods to communicate, now look at this, this is coming off

and starting off with a modulus of 500 and twelve bits.

These are much stronger than our normal day-to-day communications,

it's much more complex because the device knows it's not going to use them for long.

The only thing it's going to use this for is to encrypt that session key for the communication.

So they're like, you know, we can take the processor,

just to do a tiny amount of encryption.

If we were to actually use these keys for all communication, our devices would die,

there's no way they can keep up because with the strength of keys, every bit that you add

to it effectively doubles the strength.

It's not like 128 bit is twice as strong as 64 bit,

no it's 65 bit is twice as strong as 64 bit.

Sixty-six bit is four times as strong as 64 bit.

But also four times as complex to process, so do you see what I mean.

So when you're talking 128 bit versus 64 bit is like you can't even compare that,

it's out of the part and same thing when you come down here,

you're infinite at least stronger.

The-- so as our processors get bigger and bigger and bigger,

we're able to create this more improved algorithms because as the processor get bigger

and bigger, it's easier to brute force attack this 64 bit keys, you know, we can generate,

you know, millions of passwords every seconds and try

and see if that's the secret key that's being used.

So that's-- when we come to this question, the modulus, what do you want to use?

A common strength is 1024 bit, 512 is considered,

I would say weak for an asymmetric key set, 1024 or if you're feeling really beefy, you know,

I can go with the 2048 bit, go to the maximum

that at least this device support some device or sport more.

But it's actually generating it, it's going to take a little bit

because my little processor is going, trying to generate the super strong encryption key

that is going to be used for communication from here and out.

Just so, you know, I paused the nugget, I'm still waiting,

this was 30 seconds ago, okay, I'm pausing again.

Okay, about 15 seconds later.

So it took about, I would say, a total of 60 seconds

to generate those keys just because they're so beefy.

So now I've got the encryption keys, I've generated this certificate,

I've generated the public-key, I've generated the private-key.

Now we need to enable it, so I'm going to, oops, I'm going to go on my device

and do IP SSH, we're going to say version 2.

Version 1 is old and I would say, nowadays considered, you know, bad form,

it's not like somebody can hack it, it's just they've come out with improvements since the.

So version 2 is the one that we want to use.

Think of that is like a light switch behind the scenes, I just turned on SSH version 2.

Now we create our local user accounts, what's this?

Well, SSH unlike Telnet relies on a user name and a password.

Now you remember so far when we've been managing our device, I Telnet in, I hit Telnet,

it just says, what's your password, I type in Cisco and I'm in, I'm able to access the device.

Well, SSH requires a user name and a password or at least in the Cisco world does.

So what I need to do is in global configuration mode create a user account

that I can use for SSH.

So what I'll do is I'll type in, username and whatever username I want to use.

Now bad usernames are things like admin, route, administrator because if you're a hacker,

those were always the accounts you're going to try it first, you're going to say,

I'm going to brute force something name [phonetic], I mean,

try and come up with something unique, it doesn't have to be your name, it could be,

you know, company admin or it maybe the name of your company ADM, or such--

just something that wouldn't be so normal for people to use as the administrator.

Jeremy would definitely classify as a non-normal administrator username or maybe, you know,

if I want to be even more secure, I could do jeremeny$,

there's nothing to keep you from doing that.

So I'll do Jeremy-- host name Jeremy.

And then from there, I can type in either password

to specify the password or secret to specify the secret.

Now just like the enable password or enable secret,

it's much better if your device supports it to use the secret because now the username

and password will not be stored as clear text in the running config.

So I'll say username Jeremy secret Cisco, just so I don't forget the password.

So now I've got this user account I created and if I do a show running config, by the way,

this do command, again, we saw this in the last nugget,

it allows you to execute the show command from any mode.

The only drawback of it is, the question mark doesn't work, so if I'm, you know, testing it,

it's like, you know, I don't know.

So the context sensitive help doesn't work, it just says line, as well as the tab key.

So I can do show run, it's going to say--

I'm not complaining because I don't know what command you're trying to type,

this is kind of a shortcut if you will.

So do show run, I hit the space bar or right there, I see username Jeremy secret--

you know, it's just like my enable secret, it's this nice gobbledygook

that is encrypted there or hashed up on the screen.

So now, I've created the local user accounts, now I need to chose

to allow Telnet and I should put or SSH.

Now, from the last nugget, what ports are Telnet ports?

As in where do I go to configure a Telnet password, do you remember?

Line VTY and then whatever line numbers I want to configure.

Well, in my case, I want to configure all of them, all of them will support this.

Now there's a command under it.

Now notice that we've got under this VTY line, we have a password,

we did that in the last nugget, that's what allowed me to Telnet in right here as I typed

in the password of Cisco on the device.

So there is a password under there, but I'm going to change the story a little bit by typing

in the command, transport input as in the kinds of protocols that are allowed

in that the transports, the ways that you can communicate with this VTY lines are going to be

and now I can specify, SSH or Telnet, and you can say none,

and that totally disables all remote access, I don't want to do that.

Or we'd do both of them or you could type in for instance, if I wanted to still allow both Telnet

and SSH, I could type in Telnet and SSH, and that says, I will allow both of them,

so watch this, I'll go back here to my-- my command prompt.

Let's put this up over here, has the up URL.

And I see I can still Telnet into the device, right?

Now if I go here and I do transport input and I just do SSH, now I've disabled Telnet

and I come back here, and hit the up URL, it's like, oh, I'm sorry, no soup for you,

I cannot connect to the host on port 23 connection failed

because I'm no longer allowing the Telnet protocol.

Now let me get back to when I first said this, I said, why do you take the risk of using Telnet,

why do that, and I said, if SSH is just as easy to use, and I said, asteric [phonetic], codes,

and [inaudible], just as easy is not-- again, so that's probably why Telnet is still around,

is Microsoft never included a command line SSH client.

Shame on you Microsoft for not doing that, they've always allowed Telnet, Unix, Linux,

they've always supported SSH from a command line but not Microsoft.

So in order to use SSH, we have to download a different program like PuTTY,

like TeraTerm, like-- does this support it?

TCP, no, no.

So TeraTerm by itself does not support SSH, it does Telnet only.

However, you can download SSH version of TeraTerm.

So let's actually go with the PuTTY, that one is nice and easy.

TeraTerm I have to install.

Now watch this, I'm going to do PuTTY just on Google, here's my download page.

Notice right here, legal warning.

There are countries out there that don't allow you to encrypt your data beyond a certain level.

Essentially, there's government entities out there that say,

we want to be able to know what you're doing.

Now, the United States is not one of those, Canada is not one of those, Mexico is not one--

I mean, but I would definitely make sure that you know before you do this,

what your country supports because a lot of these countries will monitor.

And they'll see what algorithms your using for encryption.

And if it's something that is beyond to what they can decrypt, you're going to get a knock

on a door or I'm in United States, I don't know what other countries do,

I don't know of doors being kicked down, you know, the explosions,

I don't know, it's a weird world out there.

So the point is, be careful with what kind of encryption you used in your country.

Here we can use whatever we want, I'm going to go download PuTTY which this is, you know,

just-- actually, looks like I've download it before

because it's saying I'm downloading PuTTY one.

So I open PuTTY and it says, okay, what do you want to do

and you've got Telnet, Rlogin, SSH, Serial port.

So I'm going to ask SSH and we type in 10.1.1.10

which is the IP address of my switch, click on open.

Now check this out, it's says, this server's host key is not cached in the registry.

You have no guarantee that this server is the computer you think it is.

What's that mean, that kind of creeps me out.

What it means is PuTTY just recognized this switch is using a certificate,

it's using encryption keys that it just made up itself.

So it's saying, you know what, this is your first time connecting here,

it's saying that I approved my own certificate, you have no guarantee

that this server really is the device that you think it is.

If you're okay with that, go and hit yes.

Now I will say almost always we're okay with that, we-- you know, in our organizations, well,

typically generate our own server certificates.

Now PuTTY memorizes that certificate, it says okay, then from here on out, this device,

this MAC addresses, this IP addresses, you know, everything is now bound to that key,

it's not going to ask you that again, it said, you said, I trusted--

and the only way, it will plug that message again if maybe another device gives you

that same certificate, you know, some other device out there, says, oh,

I've got the same encryption keys, the other guys can be like, whoa, sabotage.

So now it's asking me,, who do you want to login as?

Jeremy, this is the user account that I created, what is Jeremy's password, Cisco.

Not what I expected, it was Cisco, right, Cisco.

Okay, troubleshooting, actually, I think I know what it is.

There's a command I forgot to show you.

So a show run I'm going to begin with, oh, it's saying, oops, "Sorry, you timed out."

So let's begin with at lines.

We'll just zoom into those VTY lines, yeah, there's the problem.

So one more command under those VTY lines, let's go into global config mode,

I'm going to do line VTY 0 space 15, get back under there.

See right here that it says, login, right, login, I know, it seems like okay, well,

that's simple enough, right, isn't that-- oh there's to it.

Login says, okay, log people into these ports, but use the password that's under here.

Now that's the problem because we already trying to use username and password.

And under the ports, there's only a password.

So essentially, login is used for Telnet to say, you know,

Telnet in and you can use this password, they link together.

But and this sound little funny to do this, but instead we actually go

to the VTY lines and type in login local.

What that says to the device is use the local user database for your logins.

Don't just try and login people and only require the password

because frankly SSH doesn't even support that, it needs a username and a password.

Instead, login using the local database on here.

Now this is as an alternative to login using the TACACS server, what's over that?

So when we get big enough, we can setup our switches to where, you know,

I don't want the user accounts on the switches because I have hundreds of them

and routers and all these kind of stuff.

And I don't want to have to have usernames and passwords that I change on a regular basis

where I Telnet into or SSH into 50 or hundred different devices on a monthly basis

and change everybody's password because that's a good security practice.

Instead, what you can use is something called a TACACS server, Cisco makes them.

And all the devices say, well, I get my user accounts from TACACS.

So when I say on the port login space TACACS, that says, when somebody tries to login

to this VTY lines, check their credentials against the TACACS server and that's

where you create your user accounts.

So then, I change my password in one place and all the devices say, oops,

looks like there's a password change, you know, because, you know, they all just report

to that centralize server, so that's the piece.

So we can either login using TACACS which is a server, login using a local

which is the local user database on that device it's going to be what we do here

or we can just type and login which says, use the password.

So I'll type it again just for grants, login local.

And now, I'll go back to PuTTY, give me my error.

Let's go to restart session.

There we go, login as Jeremy and this time password of Cisco.

There we go, that's what I want to see.

So it was the login local.

Men, I can't believe I forgot that.

So create the user, so choose to allow Telnet and SSH, that was the transport input.

And then also seven, enable local login.

I guess I could just group under that one statement.

So transport input, Telnet/SSH, if you want to do that.

And then, enable the local login so that it uses the local user database.

All right.

So there is SSH and all it's glory.

And I know some of you are like, wait, summary, there's two more bullets on there.

Well, yes, but those are really focused on what we did while we enabled SSH.

Even though, the goal of this was to enable SSH, we also learned how

to manage existing user accounts or it manage user accounts on Cisco devices.

That was what we did when I went to global configuration mode and created username Jeremy,

password or secret Cisco to create user accounts.

So that's-- you can do that not only for SSH, but also for all kinds of other stuff.

A matter of fact, let me show this to you.

I know we disabled Telnet by using transport input SSH,

but if I do transport input Telnet and SSH now, watch what happens.

I open my command prompt and type in Telnet 10.1.1.10 and notice,

now Telnet even is prompting me for a username, Jeremy and the password of Cisco,

it's just not secured to do it that way because that's all transmitted in clear text.

So this login local and these user accounts that we create, impact both SSH and Telnet not

when we do it, but also as you go down the road when you set a VPN connections,

if you want to use web management, there's all kinds of things these user accounts to use for,

you now know how to create them on Cisco devices.

And then finally, encrypting passwords through using secret.

So we create our user accounts using username, you know, jer secret cisco,

instead of username jer password Cisco because password stores in clear text.

And so passwords store in clear text which is not secure, you can encrypt it using

that service password encryption we saw in the last nugget which uses

that crackerjack encryption but noting bits that secret encryption level.

All right.

Good. I hope this been informative for you and I like to thank you for viewing.