LANtronix --------------------------- Secure Console Server --------------------------- Software Revision Notes --------------------------- Version 2.0/1 July 23, 2002 Copyright 2002, Lantronix Release notes are also available via the Lantronix web site (www.lantronix.com) and via anonymous FTP from ftp.lantronix.com. Contact Lantronix or your reseller for more information. This document describes the Lantronix Secure Console Server V2.0/1 software release. Release Summary =============== These release notes will document new features added and problems corrected since the V1.0/2 software release. Supported Platforms ------------------- V2.0/1 provides secure console functionality on the SCS100, SCS200, SCS400, SCS1600 and SCS3200 hardware platforms. New Features ============ The following is a list of new features in V2.0/1. SSHv2 support ------------- Support has been added for SSHv2. To configure the type of SSH connections allowed, use the command: SET/DEFINE PROTOCOL SSH MODE [ V1ONLY | V1PREFER | V2PREFER | V2ONLY ] The default value for this option is V2PREFER. As the parameters imply, this command will control what type of SSH connections will be allowed to and from the SCS. When negotiating which SSH protocol to use the server offers the protocol versions it supports, then the client chooses which version to use. For incoming (host to SCS) SSH connections the following rules apply: V1ONLY -- SCS will only offer SSHv1 connections V2ONLY -- SCS will only offer SSHv2 connections V1PREFER -- SCS will offer both v1 and v2 and the client will choose V2PREFER -- SCS will offer both v1 and v2 and the client will choose For outgoing (SCS to host) SSH connections the following rules apply: V1ONLY -- The SCS will only connect using SSHv1 V2ONLY -- The SCS will only connect using SSHv2 V1PREFER -- If both SSHv1 and SSHv2 are available, choose SSHv1 V2PREFER -- If both SSHv1 and SSHv2 are available, choose SSHv2 If a compatible protocol version is not agreed upon, i.e. one node wants SSHv1 and the other wants SSHv2, the connection will not occur. Key Generation -------------- Note that key generation, especially host keys, can take a significant amount of time. When the SCS boots for the first time it must generate all the keys. It will generate them in the following order: Ephemeral server key -- required for all incoming connections -- 25 seconds on the SCS100/200/400 -- 15 seconds on the SCS1600/3200 RSA host key -- required for all SSHv1 incoming connections -- 80 seconds on the SCS100/200/400 -- 40 seconds on the SCS1600/3200 DSA host key -- required for all SSHv2 incoming connections -- 400 seconds on the SCS100/200/400 -- 300 seconds on the SCS1600/3200 RSA identity key -- required only for passwordless authentication for outgoing SSHv1 connections -- 30 seconds on the SCS100/200/400 -- 15 seconds on the SCS1600/3200 DSA identity key -- required only for passwordless authentication for outgoing SSHv2 connections -- 140 seconds on the SCS100/200/400 -- 90 seconds on the SCS1600/3200 -- **NOTE** DSA Public-key authentication is not supported in this release. Until the appropriate keys are generated the appropriate type of SSH connections will not function correctly. After about 55 seconds (on a SCS1600 or SCS3200) there is a ephemeral server key and a RSA host key. At this point, even if configured for dual-protocol operation, the SCS will call itself a SSHv1-only server, and will accept incoming connections using SSH protocol version 1. After about 300 seconds when generation of the DSA host key is completed, the SCS will convert itself to dual-procotol version operation, and accept incoming connections for either SSHv1 or SSHv2. Using this approach allows a functioning SSH server in less than a minute after first bootup after factory NVR flush, yet still be dual-protocol version without user intervention as soon as is feasible. Note that the Ephemeral server key must be regenerated each time the SCS is rebooted. However, the RSA and DSA keys are stored on the SCS flash file system in the ./flash/ssh directory. They will only be regenerated if the SCS is flashed back to factory defaults or if the files in the ssh directory are tampered with. Authentication types -------------------- The SCS supports the following authentication methods: SSHv1 -- Username/password -- RSA SSHv2 -- Username/Password -- Public Key Username/password authentication simply consists of prompting for username and password and then verification against the standard SCS authentication methods. In RSA and public-key authentication the server maintains a list of keys (public half only) that are allowed to log in. When a client forms a SSH connection the following steps occur: 1) The client sends the server the public half of its identity key. 2) The server verifies that the client's key is in its list of keys approved for login. 3) The client then signs some known data with the private half of its identity key and sends the signature to the server. 4) The server verifies the signature with the public half of the key. This ensures that the client is the legitimate holder of that identity key and not an impostor. Only the holder of the private half of the identity key can generate a signature that verifies correctly with the public half. If this verification succeeds, access is granted. The following steps are necessary to setup each of the host based authentication styles. Note that these steps only need to be performed if the appropriate keys are not in their respective locations, i.e. normally when initially configuring the server or connections. The steps involved in forming an incoming SSHv1 connection (connection from a host client to the SCS) are: 1) Create an RSA identity key for yourself on the client you'll be forming the SSH connection from. See the client's documentation for directions on how to create the identity key. Some clients may offer the choice of three different key types: DSA, RSA, and RSA1. Choose the RSA1 key. If the client offers only RSA or DSA, choose RSA. If the client offers no choice, use the file generated; it might just work. The key the client generates will usually be saved to a pair of files called identity and identity.pub. 2) FTP the identity.pub file from your newly created identity key to the SCS. Append it to the file /flash/ssh/authorized_keys, creating that file if it doesn't already exist. 3) Enable "RSA Authentication" in your SSHv1 client, and if necessary, tell it where to find your identity key. 4) Form a SSHv1 connection to the SCS. The steps involved in forming an incoming SSHv2 connection (connection from a host client to the SCS) are: 1) Create a DSA identity key for yourself on the client you'll be forming the SSH connection from. See the client's documentation for directions on how to create the identity key. Some clients may offer the choice of key types. Select a DSA key. The key will usually be saved to a pair of files called identity2 and identity2.pub or id_dsa and id_dsa.pub. 2) Copy the identity2.pub or id_dsa.pub file from your newly created identity key to the SCS. Append it to the file /flash/ssh/authorized_keys2, creating that file if it doesn't already exist. 3) Enable "PubkeyAuthentication" in your SSHv2 client and if necessary tell it where to find your identity key. 4) Form a SSHv2 connection to the SCS. The steps involved in forming an outgoing SSHv1 connection (connection from the SCS to a host) are: 1) Log into the SCS. Verify that it has created an RSA identity key for itself by verifing the existence of the two files /flash/ssh/identity and /flash/ssh/identity.pub. If these files do not exist, issue a SET PROTOCOL SSH MODE command to anything other than V2ONLY. This will force the SCS to create a new identity key. Wait until the key has been created. 2) Copy the file /flash/ssh/identity.pub from the SCS to the SSH host you wish to access. Append it to the file authorized_keys in the account you wish to access, creating that file if it doesn't already exist. On Unix systems, this file is typically found at ~/.ssh/authorized_keys. 3) Ensure the SSH server you are trying to access is configured to allow "RSAAuthentication". 4) Use the CONNECT SSH command from the SCS to connect out to your server. Note that the first connection to your server should be done from an interactive priviledged login on the SCS, so that the SCS can write your server's host key to its known_hosts file. Future connections need not be priviledged or interactive. The steps involved in forming an outgoing SSHv2 connection (connection from the SCS to a host) are: Note: Public-key authentication for this case does not work in this release. When it does work, the procedure will be: 1) Log into the SCS. Verify that it has created an DSA identity key for itself by verifying by the existence of the two files /flash/ssh/identity2 and /flash/ssh/identity2.pub. If these files do not exist, issue a SET PROTOCOL SSH MODE command to anything other than V1ONLY. This will force the SCS to create a new identity key. Wait until the key has been created. 2) Copy the file /flash/ssh/identity2.pub from the SCS to the SSH host you wish to access. Append it to the file authorized_keys2 in the account you wish to access, creating that file if it doesn't already exist. On Unix systems, this file is typically found at ~/.ssh/authorized_keys2. 3) Ensure the SSH server you are trying to access is configured to allow "PubkeyAuthentication". 4) Use the CONNECT SSH command from the SCS to connect out to your server. Note that the first connection to your server should be done from an interactive priviledged login on the SCS, so that the SCS can write your server's host key to its known_hosts file. Future connections need not be priviledged or interactive. Banner Pages ------------ The ability to display two login banner pages has been added. The pages can be displayed both before and after user authentication has occured. The actual information to be displayed must be saved as files on the SCS file system. The files may be saved on the /ram disk or the /flash disk. Note that files on the /ram disk will not be saved if the SCS is rebooted. Before a user starts authentication, the file "prelogin.txt" will be displayed. After the user is authenticated the file "postlogin.txt" will be displayed. If neither file is found the standard "company/product/ version" banner will be displayed. behavior -------------------- The default behavior of the key has been modified. In previous versions the key, i.e. , would return the cursor to the beginning of the command line. This behavior has been changed to be the same as the delete key, i.e. remove the character to the left of the cursor. Use the command: DEFINE PORT BACKSPACE [ENABLED | DISABLED] to change the behavior. If disabled (default value) will delete the character to the left of the cursor. If enabled, will return the cursor to the begenning of the command line. FTP Reload ---------- The ability to load a new version of operational software into a SCS using the FTP protocol has been added. To update firmware, simply FTP the appropriate software file (i.e. SCS100.SYS, SCS200.SYS, ...) to the server using the login "root" and the appropriate password. (note the default password is "system") If the ftp'd file name matches the software load file name from the show server boot screen, the SCS will automatically program the new code into flash and reboot the unit. Serial Break Handling --------------------- The ability to specify an alternate break (AltBreak) character has been added. This is for configurations with terminals that cannot generate a break condition, telnet clients that cannot generate a break IAC sequence and SSH connections. To specify the alternate break character use the command syntax: SET/DEF PORT BREAK CHARACTER [ | NONE] where is a single character enclosed in quotes. Non-printable characters can be specified by using the notation \xx where "xx" is the hexadecimal representation of the character. The "SHOW PORT" command displays the current setting. The default port break character is for incoming network connections. There is no default port break character for serial ports. There are two configuration options that work together to control breaks. The alternate break character defines which keystroke acts like a break and the SET/DEF PORT BREAK [local | remote | none] controls where the break condition is processed. In addition, for incoming telnet and SSH sessions the port configuration is based on the settings of port 0, the template port. There are several scenarios of how break handling works. Each will be described individually. User on a SCS serial port telnets to a network host. o If the port is set Break=Local, typing the AltBreak character will return them to the Local> prompt just like receiving a break condition on the serial port. o If Break=Remote, the SCS will transmit a Telnet Break IAC sequence to the host. User on a SCS serial port SSH's to a network host. o If the port is set Break=Local, typing the AltBreak character will return them to the Local> prompt just like receiving a break condition on the serial port. o If Break=Remote, nothing will happen, as there is no way to propogate a break across a SSH connection. User on a SCS serial port issues a "CONNECT LOCAL" command to serial port 7. Note that port 7's break settings are not applicable. o If port 1 is set Break=Local, typing the AltBreak character will return them to the Local> prompt. o If port 1 is set Break=Remote, typing the AltBreak character will cause a break condition to be generated on port 7. User telnets into the SCS, has a default AltBreak character from template port 0 and is sitting at the Local> prompt. o If the user presses the AltBreak character, nothing happens. Breaks are ignored at the Local> prompt. User telnets or SSH's into the SCS, has a default AltBreak character from port 0 and has issued a "connect local" command to connect to port 7. Note that port 7's break settings are not applicable. o If the user presses the AltBreak character and the template port (port 0) settings are Break=Local, the user will be returned to the Local> prompt. o If the user presses the AltBreak character and the template port settings are Break=Remote, a break condition will be generated on port 7. User forms a TCP connection from a host to port 7 on the SCS using socket 2007 and the AltBreak character has been defined on port 7. (Note that the 20xx range of sockets performs Telnet IAC interpretation.) o If the AltBreak character is detected in the datastream from the host and if port 7 has Break=Remote, a serial break condition will be generated on the port. o If the AltBreak character is detected in the datastream from the host, if port 7 has Break=Local, nothing happens. o If a break condition is detected on the serial port and port 7 has Break=Remote, a Telnet Break IAC will be sent on the network connection. o If a break condition is detected on the serial port and port 7 has Break=Local, nothing happens User forms a TCP connection from a host to port 7 on the SCS using socket 3007 and the AltBreak character has been defined on port 7. (Note that the 30xx range of sockets is 8-bit clean.) o If the AltBreak character is detected in the datastream from the host, if port 7 has Break=Remote, a serial break condition will be generated on the port. o If the AltBreak character is detected in the datastream from the host, if port 7 has Break=Local, nothing happens. o If a break condition is detected on the serial port, nothing will happen as there is no way to propogate a break across an 8-bit clean connection. Incoming Security ----------------- The ability to individually enable/disable the FTP and web server has been added. Use the commands: DEFINE PROTO HTTP [ENABLED | DISABLED] DEFINE PROTO FTP [ENABLED | DISABLED] By default, both the HTTP server and the FTP server functionality is enabled and the "SHOW PROTOCOL" command will show their current state. The ability to completely disable all non-encrypted connections to the SCS has been added. Use the command: DEFINE SERVER INCOMING SECURE If this characteristic is enabled, incoming telnet connections, incoming rlogin connections, connections to the remote console port (port 7000) and connections directly to the serial ports using either telnet (20xx sockets) or TCP (30xx sockets) are disabled. In addtion, connections to the Finger, Discard, Chargen and Echo listeners are disabled. Note that if the "incoming secure" characteristic is enabled, EZWebCon will not be able to extract or restore server configuration information. The ability to abort a connection attempt if any authentication method failed has been added. Use the command: DEFINE AUTHENTICATION STRICTFAIL By default authentication attempts will continue until either the user is successfully authenticated or all methods fail. Enabling STRICTFAIL will cause the SCS to abort the login attempt on the first failure in the authentication method list. Note that this option is SCS wide, not per port or per user. Miscellaneous ------------- Default RADIUS socket numbers have been updated to conform with RFC 2138. The ability to have multiple line titles in menu mode has been added. Up to five lines of "Menu title" information can be specified in the menu control file. The command "SHOW IP COUNTERS" has been added and the IP counters have been removed from the show IP page. The ability to manually force DTR to be deasserted for a specific period of time has been added. Use the command: TEST PORT DTR DELAY