All language subtitles for 13 - Switching - Configuring SSH, User Accounts, and Password Encryption-eng

>> 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.