00:00

Welcome to Jeremy's IT Lab. This is a free, complete course for the CCNA. If you like these videos,
please subscribe to follow along with the series. Also please like and leave a comment, and share the
video to help spread this free series of videos. Thanks for your help. In this video we will cover SSH,
secure shell. SSH is a protocol used to connect to devices and configure them via the CLI.

00:28

One option to connect to a device and configure it is via the console port, which I introduced in an
early video of this course. However, SSH allows you to connect to a device remotely without being
directly connected to its console port. SSH is exam topic 4.8, which says you must be able to
configure network devices for remote access using SSH. I won't just cover SSH in this video though, I
will take the opportunity to introduce some other important concepts.

00:59

Here's what we'll cover in this video. First, console port security. In the last video about syslog I
mentioned the console line and the VTY lines, so I want to take the opportunity to explain more
about the console line and how you can make it more secure. Then I'll explain the management IP
address on Layer 2 switches. Layer 2 switches don't route packets and don't build a routing table,
however you can configure a management IP address on them.

01:28

so that you can remotely connect to them via SSH. Then I will introduce Telnet, which is a protocol
similar to SSH, but it's simpler and less secure. Finally, the main topic of the video, SSH. A lot of
topics to cover, but the first few topics shouldn't take too long to go through. As always, watch until
the end for a bonus practice question from Boson Software's

01:57

First, console port security. By default, no password is needed to access the CLI of a Cisco IOS device
via the console port. You can take a new device out of the box, use a console cable to connect your
laptop to it, and then start configuring it in the CLI. However, you can configure a password on the
console line. The console line is where you configure all settings related to console port connections.

02:24
When you do this, a user will have to enter a password to access the CLI via the console port. Let's
get right into the configurations. To configure the console line, use the command LINE CONSOLE 0
from global config mode. There is only a single console line, so the number is always 0. What does it
mean to have only a single console line? It means there can only be a single console connection at
once.

02:49

You can't have multiple people configuring the device at the same time via separate console ports.
Only one user can connect at a time. Then the password is PASSWORD, followed by the password.
But configuring a password isn't enough, you have to use the LOGIN command, which tells the
device to require a user to enter the password to access the CLI via the console port. That's it. Now a
password will be required to access the console port.

03:18

To demonstrate, I used END and EXIT to terminate the console connection. Then I pressed enter to
connect again, and I was asked for a password. I entered the password of CCNA, and I was able to
connect. Note that the password isn't displayed as you type it, so the password can't be seen by
anyone nearby. Alternatively, you can configure the console line to require users to log in using one
of the configured usernames on the device.

03:47

This is different than the previous example, in which we configured a specific password just for the
console line. So, here are the configurations. First I created a username, Jeremy, and gave it a secret
password of CCNP. I once again used LINE CONSOLE 0 to configure the console line. Then I used the
command LOGIN LOCAL. This tells the device to require a user to login using one of the configured
usernames on the device.

04:16

So, instead of logging in using the password configured on the console line, the user will have to use
a username and password. By the way, here's the current configuration of R1's console line. Notice
that the password of CCNA that I configured previously is still there. However, I changed the login
mode from login to login local so the console line's password of CCNA can no longer be used. The
user must log in using an account on the device.

04:45
So, I logged out of the connection, pressed enter, and as you can see I was asked for a username and
password, not just a password. Okay, I want to show you one more command. That is the EXEC
TIMEOUT command. This will cause the device to log the user out after a certain period of inactivity,
3 minutes and 30 seconds in this case. This is a good security practice, in case you leave your desk
but forget to log out of the console connection.

05:15

Okay that's all for console line security. Now let's move on to remote management of devices.
Routers and Layer 3 switches have IP addresses you can use to connect remotely to manage the
devices, but what about Layer 2 switches? Layer 2 switches don't perform packet routing and don't
build a routing table, they aren't IP routing aware. Their purpose is simply to forward frames in the
LAN, as you already know. However, you can actually assign an IP address to an SVI.

05:44

a switch virtual interface, to allow remote connections to the CLI of the switch, for example using
Telnet or SSH. For the rest of this video, I'll use this network topology. The network admin is using
PC2 and needs to be able to connect to all of the devices in the network to configure them, without
having to travel to different offices. To allow this, the Layer 2 switches need an IP address. So here's
how you can configure it.

06:13

First, configure the IP address on the SVI in the same way as on a multilayer switch. INTERFACE
VLAN, followed by the VLAN ID. Then configure the IP address. Finally, enable the interface if it's
shut down by default. So, the SVI is configured. However, there's one more step you need to
configure to allow a Layer2 switch to communicate with devices outside of its local LAN.

06:43

configure the default gateway of the switch. PC2 isn't in the same LAN, so SW1 can't send network
traffic directly to PC2. It has to send the traffic to a router, which will then route the packets to their
destination. It's like configuring a default route, however Layer 2 switches don't have a routing table,
so you have to use this command to specify the default gateway instead. Okay, that's all the
configuration needed for a Layer 2 switch's management IP.

07:13

To demonstrate Telnet and SSH, I'll continue configuring SW1.

First up, Telnet. It's not commonly used today due to a lack of security, but it's good to know before
looking at SSH. Telnet, teletype network, is a protocol used to remotely access the CLI of a remote
host. So instead of plugging your PC directly into the device with a console cable, you can connect to
the device on a remote network. Telnet was developed in 1969, so it's a very old protocol.

07:48

almost entirely replaced by SSH, which is more secure. However, SSH was developed in 1995, so
Telnet had many years of use. Telnet sends data in plain text, no encryption. So, if someone uses a
tool like Wireshark to capture the traffic, they can read exactly what was sent. Let me demonstrate.
Up top is a Telnet packet sent from R1, inside it says PASSWORD.

08:16

This is the password prompt the CLI displays when trying to log in. I entered the password, and it
was sent in a packet to R1. But the password is displayed in plaintext, CCNP, no encryption. So
anyone in the middle who is able to capture the traffic like I did here will be able to read all of the
traffic between my device and R1, the username, the password, and all of the traffic after that. That
is definitely not secure.

08:45

that's why SSH is used instead of Telnet. Before moving on to Telnet configuration, I want to point
out one more thing. The Telnet server, that's the device being connected to, R1 in this case, listens
for Telnet traffic on TCP port 23. So, when my device sent the password to R1, the destination port
was TCP port 23. As always, make sure you remember that port number.

09:12

And by the way, the Telnet client is the device that is connecting. And as I just said, the Telnet server
is the device that is being connected to. Here's how to configure a device so that you can use Telnet
to connect to it. First you should always configure an enable secret, but if you haven't make sure you
do. You won't be able to access privileged exec mode when connecting via Telnet if an enable secret
isn't configured.

09:40
I also configured a username and password, since I will later configure login local mode. This isn't
necessary, but you can configure an ACL to limit which devices can connect to the VTY lines of the
device. And then use the command LINE VTY 015. Telnet and SSH access is configured on the VTY
lines. There are 16 lines available, so up to 16 users can be connected at once.

10:08

LINE VTY 015 means you are configuring all lines, from 0 through 15. This is recommended, so all of
the VTY lines have the same configuration. By the way, VTY stands for virtual teletype. Okay, first I
configured LOGIN LOCAL as well as EXEC TIMEOUT. I think the default EXEC TIMEOUT depends on
the device. In this case it was 10 minutes, but I shortened it to 5 minutes.

10:39

Okay, next I use the command TRANSPORT INPUT TELNET. This is how you configure what kind of
connections to the VTY lines are allowed. TRANSPORT INPUT TELNET allows only TELNET
connections. You could also configure TRANSPORT INPUT SSH to allow only SSH connections, or
TRANSPORT INPUT TELNET SSH to allow both. TRANSPORT INPUT ALL allows all connections. There
are some other protocols aside from TELNET and SSH.

11:09

Or you can configure transport input none to allow no connections to the VTY lines. The device I'm
using for this demo defaults to transport input none, but I think many devices default to transport
input all. Finally, I applied the ACL to the VTY lines. This means that only PC2 will be able to connect
to SW1 using Telnet. Note that this applies only to VTY line connections.

11:36

other devices will still be able to communicate with SW1, send it pings, etc. As a reminder, although
the command to apply the ACL to the VTY lines is ACCESS CLASS, the command to apply an ACL to an
interface is IP ACCESS GROUP. And the command to actually create the ACL is ACCESS LIST, or IP
ACCESS LIST. Try not to confuse those commands.

12:05

and ACCESS-LIST or IP ACCESS-LIST. To verify the configuration, I first tried to ping SW1 from R2, the
ping was successful. However, when I tried to telnet to SW1, I got a message saying, connection
refused by remote host. That's because of the ACL I applied to SW1's VTY lines. Only PC2 should be
able to telnet to SW1. So, I did telnet from PC2, and it worked.
12:33

Now one last thing I want to point out is this. Notice how the VTY line configurations are displayed in
the running config of the device. The first 5 lines are displayed above, and the remaining 11 are
below. I believe this is just a result of the fact that old versions of iOS only had 5 VTY lines. So even if
you configure all 16 lines at once, they display separately in the config. That's just a bit of trivia, it
doesn't have any effect on the operation of the lines.

13:03

So, that was a quick look at Telnet. Finally, let's go to the main topic of the video, SSH. SSH, which
stands for secure shell, was developed in 1995 to replace less secure protocols like Telnet. By the
way, if you're wondering what a shell is, here's Wikipedia's definition. A shell is a computer program
which exposes the operating system's services to a human user or other program.

13:30

So anytime you're accessing the CLI of a device, that is a shell. SSH version 2, a major revision of SSH
version 1, was released in 2006. Version 2 is more secure, so it should be used whenever possible. If
a device supports both version 1 and version 2, it is said to run version 1.99. Note that 1.99 isn't
actually a version of SSH.

13:57

just means that the device supports both version 1 and version 2. SSH provides security features
such as data encryption and authentication. You'll learn more about those terms in the security
section of the course. But for example, here's an SSH packet that I captured in Wireshark. Look at
the encrypted packet section. It's just a seemingly random string of characters. Only the SSH server
and client have the keys to decrypt this packet.

14:27

so even though I captured the packet on the way to its destination, I don't know what the contents
are. By the way, SSH uses TCP port 22. So, remember that Telnet uses TCP 23 and SSH uses TCP 22.
Before configuring SSH, you should make sure that the version of iOS on your device supports it. I
used the SHOW VERSION command, and here's the iOS image name.

14:56
Note the K9 at the end that I highlighted. IOS images that support SSH will have K9 in their name.
Cisco exports NPE, no payload encryption, IOS images, to countries that have restrictions on
encryption technologies. And those NPE IOS images do not support cryptographic features like SSH.
Weak forms of encryption might be supported, but I would have to do more research on that to find
out.

15:23

Unfortunately I don't have access to any NPE IOS images. Another command to use is SHOW IP SSH.
If your device doesn't support SSH, it will tell you here. In this case SSH is supported but disabled.
Notice the version is 1.99, meaning it supports both versions 1 and 2. Now here's a hint about the
first step in configuring SSH. Please create RSA keys to enable SSH.

15:53

RSA keys are cryptographic keys that are essential for the various security features of SSH. Okay, so
after ensuring that the iOS image you're using supports SSH, you must generate those RSA keys. The
keys are used for data encryption and decryption, authentication, etc. Here's how to do that. First I
configured the domain name of SW1 with IP domain name [Link].

16:23

is that the FQDN of the device is used to name the RSA keys. By the way, FQDN means Fully Qualified
Domain Name, which is the host name plus the DNS domain name. Then I generated the RSA keys.
The command is CRYPTO-KEY-GENERATE RSA. Here it shows the name of the keys, SWIT which is the
FQDN of SWITCH1.

16:51

Then you have to choose the size of the modulus, the size of the keys. I configured 2048 bits, as I
have highlighted here. Note that you can just use the command CRYP and then specify the length,
without having to specify it separately like this. The effect is the same. Note that the length must be
768 bits or greater to use SSH version 2, so make sure the keys are at least that length.

17:19

Greater key lengths are more secure, but take longer to generate and use. After the keys are
generated, a syslog message is displayed, indicating that SSH has been enabled. I check SHOW IP SSH
again, and indeed SSH has been enabled.
17:38

Now that SSH is enabled, let's configure it. The Telnet configurations on SW1 have been removed, so
let's do a clean configuration of SSH. First, just like before I configured the enable secret, a
username, and an ACL to restrict connections to only allow PC2. Then I used the command IP SSH V2.
This is optional but recommended because SSH V2 is more secure.

18:06

Then once again, use the command LINE VTUY 015 to configure all 16 VTUY lines, just like when
configuring Telnet. Then enable local authentication. Note that you can't use log in for SSH, only log
in local works, a username is needed. You can also authenticate to an authentication server, but
that's a topic for another video. Then, since I removed the Telnet configurations,

18:33

I configured the EXEC timeout again. This is optional because there will most likely be a default EXEC
timeout, but you can use this command to specify the timeout you want. Then I used TRANSPORT
INPUT SSH. Best practice is to limit VTY line connections to SSH only, disabling Telnet because it's
less secure. Then finally I applied the ACL. Just like for Telnet, this is optional, but it is recommended
because it adds further

19:05

Okay, let me summarize the SSH configuration process. First, configure the device hostname. I didn't
mention this previously because I had already configured the hostname, but the device cannot
generate its RSA keys without a non-default hostname. Let me show you. So, on a router with a
default hostname, I tried the cryp command. I get a message saying, please define a hostname other
than router. So, I did that.

19:35

Then I tried to generate the RSA key pair again. However, I haven't defined a domain name yet, so I
get a message telling me to do so. And that's the next step in SSH configuration, configure a DNS
domain name. So that's what I did, IP domain name [Link]. Then I tried to generate the
RSA key pair, and the command works. So remember that. To generate the RSA key pair.

20:02
need to configure the hostname and the domain name first. Actually, you can manually specify a
name for the key pair, but for the CCNA you just have to know this method. So, that's the next step,
generate the key pair. Then the next step is to configure an enable password and local username
and password combination. The order of this step doesn't matter, and it's not an SSH-specific
configuration step, but make sure they are configured.

20:32

Then, enable SSH version 2 only. This isn't necessary, but it is best practice, so I decided to include it
in this summary. Then configure the VTY lines. The most important one is to make sure transport
input SSH is enabled, and then you can do any other VTY line configurations you want, like exec
timeout, applying an ACL, etc. And that's it, SSH should be working. From a PC,

21:01

can connect using the command SSH hyphen L followed by the username and IP address. Or SSH
username at IP address. You can try that out in the practice lab. And make sure you do the practice
lab. You can make your own lab, or use my lab file. But you need to know how to configure SSH, so
make sure you practice it.

21:26

Here's a summary of the new commands in this video. Like I said, you'll definitely want to do some
labbing in packet tracer to get used to SSH configuration. Unlike syslog and SNMP, SSH configuration
is a CCNA exam topic. If you don't remember the purpose of any of these commands, go back in the
video to review. Before the quiz, here's a review of what we covered. First, console port security.

21:55

By default, anyone who has physical access to the console port can access the CLI of the device. So,
it's a good idea to configure some security on it. Then I introduced the concept of a Layer 2 switch
management IP. Layer 2 switches can't route packets, but they can still send traffic from, and receive
traffic on, an SVI, allowing them to respond to pings, receive connections via SSH, etc. Then I
introduced Telnet.

22:25

a protocol that allows you to connect to the CLI of a device. However, Telnet is old and not secure,
so in modern days we typically use SSH, secure shell instead, when we remotely configure devices.
Be sure to watch until the end of the quiz for a bonus practice question from Boson Software's
ExSim, the best practice exams for the CCNA. Okay, let's go to question 1.

22:51

You issue the cryp command on a Cisco router, but the command is rejected. Which of the following
might be the cause? Select two. Pause the video now to think about the answers.

23:08

The answers are A, a hostname hasn't been configured, and E, a DNS domain name hasn't been
configured. The FQDN, fully qualified domain name, of the device is used to name the RSA key pair.
The FQDN consists of the device's hostname and its domain name. Also, the default hostname of
router cannot be used, a hostname must be manually configured. Okay, let's go to question 2.

23:38

Which of the following commands would allow both TELNET and SSH to be used to connect to the
VTY lines of a device? Select 2. Each answer is a complete solution. Pause the video now to think
about your answers.

23:55

The answers are C, transport input telnet SSH, and D, transport input ALL. C will allow telnet and
SSH, whereas D will allow some other protocols. As you can see, there are protocols outside of telnet
and SSH that are supported. A, transport input default isn't a real command, and B, transport input
NONE would allow no protocols.

24:24

Okay let's go to question 3.

24:28

want to allow only [Link] to connect to R1 via SSH. Which of the following configurations
fulfills that requirement? Pause the video now to think about the answer.

24:44
The answer is B. SSH uses TCP port 22. You must configure the VTY lines, and you must use the
ACCESS CLASS command to apply it to the VTY lines. Only B fulfills all of those requirements, so it is
the correct answer. Okay, let's go to question 4.

25:05

Which of the following statements about SSH are true? Select 2. Pause the video now to think about
the answers.

25:16

The answers are B, K9 IOS images support SSH, and F, a key length of at least 768 bits is required for
SSH version 2. RSA keys are required to enable SSH, so A is incorrect. SSH version 1.99 isn't an actual
SSH version, it is used to refer to a device that supports both versions 1 and 2, so C is incorrect.

25:44

SSH does not send data in plaintext, it encrypts the data, so D is incorrect. And NPE IOS images do
not support cryptographic features like SSH, so E is incorrect. Okay, let's go to question 5.

26:02

A network admin using PC1 is remotely configuring SW1 by connecting to the CLI of SW1 via SSH.
What is the role of SW1 in this situation? Pause the video now to think about the answer.

26:20

The answer is B, SSH server. SSH and Telnet use a client-server model, in which the device being
connected to, SW1 in this case, is the server, and the device using SSH or Telnet to connect, PC1 in
this case, is the client. Okay, that's all for the quiz. Now let's do a bonus practice question from
Boson Software's ExSim for CCNA.

26:46

Okay, here's today's Boson ExSim practice question. You want to configure SSH for incoming VTY
connections on a router with the host name Router1. Router1 is running a K9 iOS image but has not
yet been configured with a domain name or an RSA key pair. In addition, the VTY lines are not yet
configured to accept incoming SSH connections. You issue the cryptokey generate RSA command
from global configuration mode.
27:14

Which of the following messages will you most likely receive? Select the best answer. Okay, so there
are five options. Please pause the video now, check out the options, and think about the correct
answer.

27:31

Okay, let's check. So, the important information here is that it has a hostname, the hostname is
Router1. It does have a K9 IOS image, so that supports SSH. But it has not yet been configured with a
domain name or an RSA key pair, so no domain name yet. So, which message will you most likely
receive? The name for the keys will be, and then the name. Probably not this one.

27:59

Because, as I said, the name for the key pair is created using the fully qualified domain name, which
requires a hostname and a domain name, and the domain name has not yet been configured. B,
please define a domain name first. I think that is the correct answer, because as I just said you need
a hostname and a domain name. It has a hostname, a non-default hostname, Router1, but no
domain name yet.

28:28

C, please create RSA keys to enable SSH. Well that's what you're trying to do there, so I don't think
that message will be displayed. Please define a host name other than router. It already has a non-
default host name. And please enable SSH version 2. You do not need SSH version 2 to create the
RSA key pair. So, I believe B is the correct answer. And yes it is. So here is

28:55

I recommend pausing the video now to read it.

29:01

here's the rest. There are some references to the official cert guide by Wendell Odom, as well as
some Cisco documentation about configuring SSH on Cisco devices.

29:16
Okay, so that's Boson ExSim for CCNA. These are without a doubt the best practice exams for the
CCNA, as well as CCNP and many other exams. If you want to get Boson ExSim, please follow the link
in the video description.

29:32

There are supplementary materials for this video. There is a flashcard deck to use with the software
Anki. There will also be a packet tracer practice lab so you can get some hands-on practice. That will
be in the next video. Sign up for my mailing list via the link in the description, and I'll send you all of
the flashcards and packet tracer lab files for the course.

29:56

Before finishing today's video I want to thank my JCNP-level channel members. To join, please click
the JOIN button under the video. Thank you to Raj, Kenneth, Seamus, HW, Brandon, Samil, Aaron,
Marcel, Kony, Donald, Simod, Gustavo, Anthony, Baraj, Junhong, Benjamin, Tsepiso, Justin, Prakash,
Nasir, Erlison, Marco, Daeming, Jilmar, Ed, Value, John, Funnydart, Veljaykum, Mark, Yousif, Boson
Software,

30:27

Sorry if I pronounced your name incorrectly, but thank you so much for your support. This is the list
of JCNP-level members at the time of recording, by the way. February 21st, 2021. If you signed up
recently and your name isn't on here, don't worry, you'll be in future videos. Thank you for watching.
Please subscribe to the channel, like the video, leave a comment, and share the video with anyone
else studying for the CCNA.

30:54

If you want to leave a tip, check the links in the description. I'm also a Brave verified publisher and
accept BAT, or Basic Attention Token, tips via the Brave browser. That's all for now.