Cascaded Ports enables you to cluster distributed console servers. A large number of serial ports (up to 1000) can be configured and accessed through one IP address and managed through one Management Console. One console server, the Master, controls other console servers as Slave units and all the serial ports on the Slave units appear as if they are part of the Master.
Black Box’s clustering connects each Slave to the Master with an SSH connection. This uses public key authentication so the Master can access each Slave using the SSH key pair (rather than using passwords). This ensures secure
Remote Console Manager
authenticated communications between Master and Slaves, enabling the Slave console server units to be distributed locally on a LAN or remotely around the world.
4.6.1 Automatically generate and upload SSH keys
To set up public key authentication, you must first generate an RSA or DSA key pair and upload them into the Master and Slave console servers. This can all be done automatically from the Master.
Select System: Administration on Master’s Management Console. Check Generate SSH keys automatically and click Apply.
Next, you must select whether to generate keys using RSA and/or DSA (if unsure, select only RSA). Generating each set of keys will require approximately two minutes, and the new keys will destroy any old keys of that type that may previously been uploaded.
Also, while the new generation is underway on the master, functions relying on SSH keys (for example, cascading) may stop functioning until they are updated with the new set of keys.
To generate keys:
Select RSA Keys and/or DSA Keys. Click Apply.
Once the new keys have been successfully generated, Click here to return and the keys will automatically be uploaded to the Master and connected Slaves.
4.6.2 Manually generate and upload SSH keys
44
724-746-5500 l www.blackbox.com
Note If you already have an RSA or DSA key pair that you do not want to use, you will need to create a key pair using ssh-keygen, PuTTYgen or a similar tool as detailed in Chapter 15.6.
To manually upload the public and private key pair to the Master console server: Select System: Administration on Master’s Management Console.
Browse to the location where you have stored RSA (or DSA) Public Key and upload it to SSH RSA (DSA) Public
Key.
Browse to the stored RSA (or DSA) Private Key and upload it to SSH RSA (DSA) Private Key. Click Apply.
Next, you must register the Public Key as an Authorized Key on the Slave. In a case that has only one Master with multiple Slaves, you only need to upload the one RSA or DSA public key for each Slave.
Note Using key pairs can be confusing since one file (Public Key) fulfills two roles— Public Key and Authorized Key. For a more detailed explanation, refer to the Authorized Keys section of Chapter 15.6. Also, refer to this chapter if you need to use more than one set of Authorized Keys in the Slave.
Select System: Administration on the Slave’s Management Console.
Browse again to the stored RSA (or DSA) Public Key and upload it to Slave’s SSH Authorized Key. Click Apply.
The next step is to Fingerprint each new Slave-Master connection. This one-time step will validate that you are
establishing an SSH session to who you think you are. On the first connection, the Slave will receive a fingerprint from the Master which will be used on all future connections:
To establish the fingerprint, first log in the Master server as root and establish an SSH connection to the Slave remote host:
Remote Console Manager
# ssh remhost
Once the SSH connection has been established, the system asks you to accept the key. Answer yes and the fingerprint will be added to the list of known hosts. For more details on Fingerprinting, refer to Chapter 15.6.
If the system asks you to supply a password, then there is a problem with uploading keys. The keys should remove any need to supply a password.
4.6.3 Configure the slaves and their serial ports
You can now begin setting up the Slaves and configuring Slave serial ports from the Master console server:
Select Serial & Network: Cascaded Ports on the Master’s Management Console: To add clustering support, select Add Slave.
Note You can’t add any Slaves until you automatically or manually generate SSH keys.
To define and configure a Slave:
Enter the remote IP Address (or DNS Name) for the Slave console server.
Enter a brief Description and a short Label for the Slave (use a convention here that enables you to effectively manage large networks of clustered console servers and the connected devices).
Enter the full number of serial ports on the Slave unit in Number of Ports.
Click Apply. This will establish the SSH tunnel between the Master and the new Slave.
The Serial & Network: Cascaded Ports menu displays all the Slaves and the port numbers that have been allocated on the Master. If the Master console server has 16 ports of its own, then ports 1-16 are pre-allocated to the Master. The first Slave added will be assigned port number 17 and up.
Once you have added all the Slave console servers, you can assign and access the Slave serial ports and the connected devices from the Master’s Management Console menu. You can also access them through the Master’s IP address.
Select the appropriate Serial & Network: Serial Port and Edit to configure the serial ports on the Slave.
Select the appropriate Serial & Network: Users & Groups to add new users with access privileges to the Slave serial ports (or to extend existing users’ access privileges).
46
724-746-5500 l www.blackbox.com
Select the appropriate Serial & Network: Trusted Networks to specify network addresses that can access
nominated Slave serial ports.
Select the appropriate Alerts & Logging: Alerts to configure Slave port Connection, State Change, or Pattern Match alerts.
The configuration changes made on the Master are propagated out to all the Slaves when you click Apply.
4.6.4 Managing the Slaves
The Master is in control of the Slave serial ports. For example, if you change User access privileges or edit any serial port setting on the Master, the updated configuration files will be sent out to each Slave in parallel. Each Slave will then automatically make changes to its local configuration (and only make those changes that relate to its particular serial ports).
You can still use the local Slave Management Console to change the settings on any Slave serial port (such as alter the baud rates). These changes will be overwritten next time the Master sends out a configuration file update.
Also, while the Master is in control of all Slave serial port related functions, it is not master over the Slave network host connections or over the Slave console server system itself.
You must access each Slave directly to manage Slave functions such as IP, SMTP & SNMP Settings, Date &Time, and DHCP server. These functions are not overwritten when configuration changes are propagated from the Master. Similarly, you have to configure the Slaves Network Host and IPMI settings at each Slave.
The Master’s Management Console provides a consolidated view of the settings for its own and all the Slave’s serial ports. The Master does not provide a fully consolidated view. For example, if you want to find out who's logged in to cascaded serial ports from the master, you’ll see that Status: Active Users only displays those users active on the Master’s ports, so you may need to write custom scripts to provide this view. This is covered in Chapter 11.