Many network administrators are configuring switches and routers from a remote location. In this video, you’ll learn about SSH, API integration, consoles, jump boxes, and in-band and out-of-band management.
If you’ve done anything in networking relating to switches, routers, firewalls, or other devices, then you’ve probably connected over the network to a terminal or console. To do this over an encrypted channel, you use a protocol known as SSH. This is Secure Shell. This allows you to use this terminal screen to a remote device. But all of the traffic sent over the network is encrypted. This means you can put in your username, your password, and all other information. And no one else will be able to capture that traffic and see any of that important data.
Secure Shell operates using TCP port 22. And it’s designed to replace a protocol known as Telnet, which uses TCP port 23. Telnet is very similar in operation to SSH. It provides this console-based view of a remote device. But it provides no encryption. And that’s why the best practice is to always use SSH and to not use Telnet.
Working at a command line is useful, especially on devices that support it. But occasionally, you need to be able to provide remote access to a graphical front end. You can do that by using some type of remote sharing software so that you can be at a remote location yet still see and operate the same desktop as someone who’s sitting directly in front of that computer.
If this is a Windows computer, then you’re using RDP, which is the Microsoft Remote Desktop Protocol. That allows you to connect to a windows machine and be able to access and use the front end as if you were in front of the actual monitor and keyboard. If this is a Windows computer that you’re connecting to, you’re probably using RDP or Microsoft Remote Desktop Protocol. This allows you to remotely control a Windows machine, either from another Windows machine across the network or by using Remote Desktop Protocol clients that are available for nearly any other operating system.
Another option for remote control of a device would be to use VNC, or Virtual Network Computing. This uses a protocol known as RFB, or Remote Frame Buffer. This is very similar in function to Microsoft’s RDP, but the VNC functionality can be run on many different operating systems. If you’re part of a help desk or support team and you need a way to remotely connect and control any of these remote desktops, you’re probably going to be using RDP or VNC.
Sometimes you need to be able to make changes to hundreds or even thousands of different devices. You could automate this at the command line using scripts and batch files. But because this operates at the command line, you don’t have a lot of control over the process if you happen to run into problems. For that reason, you might want to use a more automated method of controlling that device, using an API, or Application Programming Interface. Using an API, you can connect and control a device using the language that that device would expect. This also allows us to automate the process and set up additional tasks if we need to do any type of error handling.
If you happen to be in the same physical location as the device, you may be able to plug in a cable and directly connect to the device. With switches, routers, and other infrastructure devices, you might even have a separate port on the front, labeled console. That console allows you to connect through a serial connection so that you can plug in your RJ45 serial, a DB9 serial connection, or a more modern USB connection to be able to gain access to that system.
The console is also a perfect solution if you lose network connectivity to the device. If you’re not able to ping or SSH into the device, you can always connect your console cable and directly communicate with that system. These consoles are commonly text-based interfaces. So you need to know the command line interface for that particular device. These console connections are commonly serial connections. So we will need a laptop or desktop computer with a serial port. Or we will need an adapter that can convert between USB to a serial connection.
Instead of individually connecting to devices, some organizations will create a jump server that allows you to connect to one device. From there, you can jump to the other devices within that particular organization. This means from your external device, you would use some type of VPN tunnel or SSH connection to initially connect to the jump server.
Because this jump server is often an externally facing device where anyone on the internet could potentially connect to that system, this needs to be very hardened. We need to be sure that we’re using authentication with multiple factors to be able to prevent anyone from brute forcing their way into that jump server. From our external client, we would use some type of third-party software, VPN, SSH, or some other secure mechanism to gain access to the jump server.
Once we’re on the jump server, we can then connect to all of the other devices within that organization without having to set up separate connections for each individual device. We obviously need to be sure that this jump server is always kept up to date with security patches and that we provide a high level of authentication to prevent any third parties from gaining access to the inside of this private network.
The console connection on a switch, router, or other device allows us to directly connect. But very often, we’re located in a different network, at a different facility, and we still need some way to gain access to those systems. Fortunately, most devices support in-band management, where you can assign an IP address to that device and then connect to it using SSH or a web-based front end.
Sometimes this in-band management is a separate interface on the device. Other times it’s built into other interfaces that already exist on that device. When configuring that switch, router, or other device, you would provide it with a management IP address, subnet mask, and other important networking details. And from that point forward, you can connect to this device across the network. Usually, this device has a web server running internally to the device. Or it may be using an SSH server so that we can connect from our SSH client.
Here’s an example of a switch that not only has a serial console connection that you can directly connect to, but it also has a separate 10/100/1000 management interface. This is the interface that you would assign an IP address. And then you would connect your network directly to that interface. From that point, you can simply reference the IP address and be able to connect to the device across the network.
If in-band management is using an IP address that we connect to through our existing network, then out-of-band management is using a serial interface that does not use our existing network. Commonly, this would be something like a separate management or console interface that we’d plug into using that serial connection. On more modern devices, you might find this to be a USB connection.
This separate console or COM port on the device also allows us to connect a modem. So we might use a standard phone line, connect a modem to that phone line, and be able to dial into that device even when the network happens to be down. In some organizations, you can even install a COM server. So you can dial into one server. And from that server, you can jump to other devices through that COM server connection. You would need to look at your switch, router, or other device to see if there is a serial connection or console connection that you can either directly connect to or use a modem to dial into from a remote site.