Project Hydra: the USB Multiheaded Monster
The first colon-separated field is the assigned ttyUSB device number, and the USB path is the bit after the path: part. In this example, the first line indicates that ttyUSB0 is the USB-serial device connected to path usb-00:07.2-2.3.4, which working backward, translates to port 4 of a hub plugged in to port 3 of a hub, plugged in to port 2 of the root hub 00:07.2.
The 00:07 part is a bit of a bonus. This field uniquely describes the USB controller, so we also have a way of determining the controller to which the device is assigned.
To make this actually work, it is necessary to store a mapping of server names to USB paths. That is, after building a tree of USB-serial devices and connecting them to the server consoles, create a text file that maps the server names to the USB paths from /proc/tty/driver/usb-serial. Then it is a simple matter to write a script that accepts a server name, parses this file to determine the USB path and then parses /proc/tty/driver/usb-serial to determine the ttyUSB device number. Once the ttyUSB device number is known, the script can establish a connection to the port using minicom as an example. I went a step further and wrote a script that probes each ttyUSB device, tries to determine the host from the login banner and then records the USB path and server name. This isn't foolproof though, as some OSes don't provide the hostname in the banner. Even worse, if the console is left logged on, the banner won't be available. Still, this option makes creating the mapping file a little easier.
Once a console port is connected to a USB-serial adapter, the console can be accessed by using minicom, screen or your favorite terminal program to connect to the assigned ttyUSB port number. This will work immediately if the server supports a serial console natively, as do most Sun, HP-UX and IBM machines. Less commonly, some PCs include a console redirection feature in the BIOS that allows full redirection of video and keyboard to a serial port. If hardware redirection is not available, software redirection can be used by setting up a tty entry in /etc/inittab, similar to one of the following:
tty0:234:respawn:/usr/lib/saf/ttymon -g -h -p ↪"'uname -n' console login: "-T vt100 -d ↪/dev/ttya -l console
t1:23:respawn:/sbin/suattr -C ↪CAP_FOWNER,CAP_DEVICE_MGT,CAP_DAC_WRITE+ip ↪-c "exec /sbin/getty ttyd1 console"
A good starting point for working with remote serial consoles is the Remote-Serial-Console-HOWTO (see Resources). The disadvantage of using a software-redirected port is you are unable to access the console if the machine fails to boot. You also are unable to access any portions of the system that occur before the OS starts. As an example, with a PC you are unable to access the PC BIOS or any controller BIOS. If this level of access is critical, you may be interested in a product called PC Weasel (www.realweasel.com), which creates a fully accessible, hardware-redirected console and also provides the ability to reset the PC remotely.
Because of the inability to hard-reset or access the console before the OS boots without a hardware console port, this console-access solution does not replace being there. However, this access solution is easy to extend and costs almost the same as a traditional serial console switch. In addition, ports can be added as needed and can be added hot.
What really separates a USB console server from a manual switch is the ability to access the consoles remotely and in parallel. That is, as many users as desired can connect remotely to the USB console server and then connect each shell to a separate, albeit unique, console. Moreover, the only limit to accessing the connected consoles is the limit of accessing the USB console server; you could use a local keyboard and monitor, SSH, dial-up modem, a custom Web interface, e-mail and so on. Of course, because the USB-serial adapters provide a standard serial port, other applications may be possible as well. Currently, we are considering using this system to monitor our UPS devices and manage shutdown events.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Server Hardening
- May 2016 Issue of Linux Journal
- EnterpriseDB's EDB Postgres Advanced Server and EDB Postgres Enterprise Manager
- The Humble Hacker?
- The US Government and Open-Source Software
- BitTorrent Inc.'s Sync
- The Death of RoboVM
- Open-Source Project Secretly Funded by CIA
- New Container Image Standard Promises More Portable Apps
- ACI Worldwide's UP Retail Payments
In modern computer systems, privacy and security are mandatory. However, connections from the outside over public networks automatically imply risks. One easily available solution to avoid eavesdroppers’ attempts is SSH. But, its wide adoption during the past 21 years has made it a target for attackers, so hardening your system properly is a must.
Additionally, in highly regulated markets, you must comply with specific operational requirements, proving that you conform to standards and even that you have included new mandatory authentication methods, such as two-factor authentication. In this ebook, I discuss SSH and how to configure and manage it to guarantee that your network is safe, your data is secure and that you comply with relevant regulations.Get the Guide