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. 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. 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 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 ExSim, the best practice exams for the CCNA. 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. 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. 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 command 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. 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 login using one of the configured usernames on the device. 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. 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 login using an account on the device. 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. 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, 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. 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 its shutdown by default. So, the SVI is configured. However there’s one more step you need to configure to allow a Layer 2 switch to communicate with devices outside of its local LAN. Use the IP DEFAULT-GATEWAY command to 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. 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. It has been largely, 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’. This is the password prompt the CLI displays when trying to login. I entered the password, and it was sent in a packet to R1. But the password is displayed in plain text, 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, and 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. 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. 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 0 15. 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. LINE VTY 0 15 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. Okay, next I used 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. 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 only applies to VTY line connections, 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, ACCESS-CLASS, IP ACCESS-GROUP, 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. 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. 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. So, any time you’re accessing the CLI of a device, that is a shell. SSHv2, a major revision of SSHv1, 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, it 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, 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. 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, 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. 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 jeremysitlab.com. The reason for this 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 the keys, SW1.jeremysitlab.com, which is the FQDN of SW1. 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 CRYPTO KEY GENERATE RSA MODULUS, 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 SSHv2, so make sure the keys are at least that length. 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. 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 VERSION 2. This is optional, but recommended because SSH version 2 is more secure. Then once again, use the command LINE VTY 0 15 to configure all 16 VTY lines, just like when configuring Telnet. Then enable local authentication. Note that you can’t use LOGIN for SSH, only LOGIN 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, 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 security. Okay, let me summarize the SSH configuration process. First, configure the device host name. I didn’t mention this previously because I had already configured the host name, but the device cannot generate its RSA keys without a non-default hostname. Let me show you. So, on a router with the default host name I tried the CRYPTO KEY GENERATE RSA command. I get a message saying, please define a hostname other than router. So I did that. 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 jeremysitlab.com. Then I try to generate the RSA key pair, and the command works. So, remember that. To generate the RSA key pair you need to configure the host name 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. 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 you can connect using the command SSH -L, followed by the username and IP address, or SSH username@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. 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. SLIDE15 Before the quiz, here’s a review of what we covered. First, console port security. 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, received connections via SSH, etc. Then I introduced Telnet, 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. Make 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. You issue the crypto key generate rsa 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. The answers are A, a host name 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 host name and its domain name. Also, the default host name of Router cannot be used, a host name must be manually configured. Okay, let’s go to question 2. Which of the following commands would allow both Telnet and SSH to be used to connect to the VTY lines of a device? (select two, each answer is a complete solution). Pause the video now to think about your answers. 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. Okay, let’s go to question 3. You want to allow only 192.168.1.1 to connect to R1 via SSH. Which of the following configurations fulfills that requirement? Pause the video now to think about the answer. 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. Which of the following statements about SSH are true? (select two). Pause the video now to think about the answers. The answers are B, K9 IOS images support SSH, and F, a key length of at least 768 bits is required for SSHv2. 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. SSH does not send data in plain text, 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. 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. 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. 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 CRYPTO KEY GENERATE RSA command from global config mode. 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. Okay, let's check. So the important information here is that it has a host name, the host name 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. So, which message will you most likely receive? The name for the keys will be, and then the name. Probably not this one because, as I said, the name for the key pair is created using the fully qualified domain name, which requires a host name 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 host name and a domain name. It has a host name, a non-default host name, Router1, but no domain name yet. 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 Boson's explanation. I recommend pausing the video now to read it. And 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. 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. 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. 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, H W, Brandon, Samil, Aaron, Marcel, Kone, Donald, C Mohd, Gustavo, Anthony, Biraj, Junhong, Benjamin, Tshepiso, Justin, Prakaash, Nasir, Erlison, Marko, Daming, Jhilmar, Ed, Value, John, Funnydart, Velvijaykum, Mark, Yousif, Boson Software, Devin, Lito, Yonatan, and Vance. 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. 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.