|
|
Accessing multiple serial ports using SSH
It is recommended you use SSH for all remote communications with the Opengear console server - and for connecting to the serially connected device consoles (refer faq237).
If you use generic SSH utilities such as PuTTY or SSHTerm to access the serial console on a device attached to a console server, an SSH tunnel is set up connecting to the port using standard port addresses IP Address _ Port (3000 + serial port #) i.e. 3001 - 3048. If you run the SSH utility again to access a second port then a second SSH tunnel will be set up.
Alternately (as described in faq237) the user can SSH connect to console server (using the syntax: [username]:[portXX] or [username]:[serial] etc)
and be presented with a serial port selection menu.
Can a user access more than one serial port through the one SSH tunnel?
- One alternative is to use SDT Connector to access the console server and its serial ports. SDTConnector will establish only the one secure SSH tunnel to the console server, and connections to multiple serial ports (and hosts) can then be set up through that one SSH port. So you can securely Telnet to all the serial port consoles through the one secure SSH tunnel provided by SDT Connector.
Also by using SDT Connector, users can set up secure SSH tunneled connections to all serial ports with only a single IP port (22) having to be opened in their firewall/gateway. Further when using SDT the user can set up any number of VNC, RDP, telnet and HTTP network connections to be forwarded over the LAN through the same open SSH port 22.
- Another alternative is to use the ControlMaster/ControlPath feature of OpenSSH which allows for persistent connections and multiplexing of interactive connections in one session. When the ControlMaster connection is established with the console server it goes through the normal login sequence, including asking for passwords and exchanging keys. However subsequent SSH sessions you initiate to the same console server may connect to the ControlMaster via the UNIX domain socket. The master SSH session then creates another interactive connection within the existing session, which your second SSH uses. Because the existing session is re-used, the connection setup is very much faster. There is no need to pull up a new TCP/IP connection, no need for key exchange, and no need for authentication. Also once the connection master is established, it is trivial to start and stop a large number of connections very quickly. For details refer faq303
SSH resource constraints
It is recommended that users always use SSH as the security protocol when connecting to the console server over the Internet or any other public network. And how you configure these SSH connections can be important as there are resource limits to be considered:
- Firstly there is a limit on the number of concurrent SSH sessions (SDT tunnels) that can be open at the one time (50 for ACM5000, CM4100, IM4200 or IMG4200 console servers and 10 for CM/SD4001/8 console severs).
- Then there's a limit on how many SSH sessions can be established simultaneously. Just as it is easy to catch 10 tennis balls one after another, it is another matter to catch 10 thrown at once. Similarly the CPU load of establishing a number of secured connections is better spread out over time, not performed all at once.
|
