From the course: Cisco CCNP Enterprise: ENARSI (300-410) Cert Prep

Remote access protocols

From the course: Cisco CCNP Enterprise: ENARSI (300-410) Cert Prep

Start my 1-month free trial Buy for my team

Remote access protocols

“

- [Instructor] As we discussed with VTY line access, the remote access protocols you will use will likely either be Telnet or SSH. And just to reiterate, Telnet is okay in a controlled lab environment, but it is best practice for real world access to only use SSH. In addition to the steps that we looked at for VTY line access troubleshooting, we do want to be aware of some additional considerations that are specific to SSH. First, in general, with either Telnet or SSH, you can perform the VTY line troubleshooting that we already looked at. And that includes verifying reachability to the IP address of the device, making sure credentials are in place and that the line log-in method lists are correct. Also check for any attached access control lists on the VTY lines. And you'll want to verify that IP addresses, protocols and port numbers are not being blocked, as we outlined in the previous video. As for SSH specific issues, you want to check to make sure that the correct version of SSH is specified in your configuration. By default on many devices, SSH versions one and two are both enabled. But if you take a look at the running configuration and see the output IP SSH version followed by a number one or a number two, then that's only going to allow that particular specified version. So if you have a client connecting with SSH version two, and you have only version one allowed on the device, this is obviously a problem. You can check that with the command that we see here at the bottom, the show IP SSH command. If you see SSH version 1.99, that means that versions one and two are both accepted. But if you see SSH version one as your output or SSH version two, again, that means that only a specific version is being allowed. If I perform this show command on my lab device, if I say show IP SSH, you can see that in my case, SSH is enabled and that's enabled for version two. And that means that only SSH version two connections are going to be accepted. I have no backwards compatibility here with SSH version one. Again, let me say that SSH version two is the best practice to implement whenever possible, and that's because it has more advanced security encryption algorithms. Notice this also shows us the authentication parameters so we can see the RSA key that's in use. Let's say we have an existing device that uses SSH version one. And let's say that we recently switched our router configuration to SSH version two. SSH requires an RSA key to be generated so that we can provide secure access to network devices. So if we were using SSH version one on this router, and then we generated an RSA key. And we can do that, let's go under global configuration mode. And the command that we do that with is crypto key generate RSA. And if we do that, it's going to tell me that I already have one in place. That's okay to replace that in my lab environment. And you can see that it prompts us for the number of bits that we want in the modulus. So with our original SSH version one configuration, let's say we just hit enter. Notice the default value is 512. SSH version two requires an RSA key size of 768 or greater. So that's definitely something you'll want to be aware of. If you started with a version one configuration and you switch that to version two, you're going to want to make sure your RSA key is large enough, it has to be 768 or greater. I'll make mine 1024, I'll hit enter, and it will generate that key, and that'll be just fine for SSH version two. So again, if you accidentally created a smaller key by hitting enter, you'll want to change that when you change the version two. You can also run, let me break out of here. We can also run the show SSH command to see any current SSH sections. Now, of course I don't currently have any, that's why we see that here in the output, no SSH version two server connections running. Again, just to make mention of a couple more general issues that we would want to be aware of, you want to make sure you have the correct login command on your VTY lines that will allow SSH input, and you'll also want to check for any access control lists that might be blocking port 22 access for those VTY lines. So that's a look at troubleshooting remote access protocols.

Contents