|
Configuring Serial Port Consoles with SSH
It is recommended you use SSH for all remote communications with the Opengear console server and for connecting to the serially or network attached device consoles.
If you use generic SSH utilities such as PuTTY or SSHTerm to access the serial console on a device attached to an Opengear 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.
With 2.0.9 firmware (or later) users can use the standard SSH port 22 to establish connections to any of the serial ports on their Opengear console server. With SSH connections that are configured using the standard SSH port 22, the serial port being accessed is identified by appending a descriptor to the username. This syntax supports any of:
[username]:[portXX]
[username]:[port label]
[username]:[ttySX]
[username]:[serial]
So for a user named 'fred' to access serial port 2, when setting up the SSHTerm or the PuTTY SSH client, instead of typing username = fred and ssh port = 3002, the alternate is to type username = fred:port02 or (username = fred:ttyS1) and ssh port = 22. Alternately, by typing username= fred:serial and ssh port = 22, the user is presented with a port selection option:
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 CM41xx, IM42xx or IMG 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.
|
