Environment
Reflection for the Web 2011 (All Editions)
Reflection for the Web 2008 (All Editions)
Situation
Resolution
Configuring Secure Shell Transport
If Secure Shell is required, the client must be validated before an ssh connection can be established. The user is asked to enter a password or provide a key. To configure a session to use Secure Shell transport, follow these steps:
- Use the Session Manager in the Administrative WebStation to create or edit an HP, VT, or FTP session.
- Open an existing session by clicking the session name under the Name column.
If you are creating a new session, click Session Manager, and then click Add. Select the type of session you want to create (HP, VT, or FTP), enter the name of the session, and then click Continue.
- Click Launch to launch the session from the Configure a Web-Based Reflection Session page.
- Follow the Setup steps either for HP or VT sessions, or for FTP sessions.
For HP or VT sessions:
- If you are editing an existing session, click Connection > Disconnect. If you are creating a new session, click Connection > Connection Setup.
- Enter the host name or IP address in the Connection (or Session) Setup dialog box.
- From the Protocol (or Transport) list, select Secure Shell.
- Enter a user name to log onto the host, or leave this field blank to require the user to enter the user name.
- Click Advanced.
- Proceed to step 5.
For FTP sessions:
- Enter the host name or IP address in the Connection Setup dialog box. (If you are editing an existing FTP session, click Connection > Connection Setup to access the Connection Setup dialog box.)
- Enter the host name or IP address.
- Select SFTP as the Protocol (or Connection) type in the Connection Setup dialog box.
- Enter a user name to log onto the host, or leave this field blank to require the user to enter the user name.
- Select Server type.
Note: Port 22 is generally used for Secure Shell. No Transport selection is required.
- Click Advanced (or SFTP settings).
- Proceed to step 5.
- Choose your authentication preferences in the Secure Shell Client Settings dialog box.
Note: Unless there is a change in your security configuration, there is no need to configure Cipher setup.
- Under "Allow unknown hosts," select whether to allow a connection to a host that the client has not previously accessed. You can select
No—never allow such connections.
Ask—prompt the user to verify the connection request.
If you select Yes or Ask, the host's public key is downloaded to the client the first time the host is accessed through Reflection.
If you select No, the hosts must be configured in your Known Hosts list in order to connect to a host. If a known_hosts file is not found on the client, it is automatically downloaded from the Reflection management server if a known_hosts file has been configured on the server.
As the Reflection administrator, you can import host public keys to the Reflection known hosts list on the Secure Shell tab in the Administrative WebStation Security Setup.
If you are installing a pre-configured known_hosts file to each client machine, consult KB 7022221 for the appropriate location. If you configure a global known_hosts file through the Administrative Webstation it will be automatically downloaded to each client.
For more information, in the Administrative WebStation, click Security Setup. On the Secure Shell tab, click Help.
- Under Authentication, select User key, Keyboard interactive (starting in version 9.5), Password, or any combination of the three. For more information, see the sections below: Using a Password, Using a User Key, or Using Multiple Authentication Methods.
- Click OK to close the dialog boxes.
- Click Connection > Connect, to verify that the connection works.
- Click File > Save and Exit, and then click Save/Exit in the Save Settings dialog box.
- If you edited an existing session, you have finished configuring the session.
If you created a new session, the Session Saved page opens. Click "Map session access" and map the session for your users, as appropriate for the access control model you use.
Managing Secure Shell User Authentication
Reflection for the Web supports Secure Shell user authentication using password, user keys, keyboard interactive (starting in version 9.5), or a combination of these methods.
User keys can be deployed globally for all clients (less secure) or per user on each individual client (more secure).
Using a Password
If you selected Password authentication (step 5 above), the session prompts the user for a password to log on to the host. The password is validated by the SSH server and the session continues.
Note: The password sent across the network is encrypted, so this is more secure than Telnet or rlogin.
Using a User Key
If you select User Key, each client that connects to the session must have a public/private key pair, and a copy of the client's public key must be in the user's .ssh directory on the host computer. There are two ways to provide users with keys:
- Globally: In the Administrative WebStation, click Security Setup, and click the Secure Shell tab. To generate a default global key pair, click "Generate user key pair." This action creates a key pair on the Reflection server.
This key pair is downloaded whenever an authorized user requests the session. The key pair is not cached on the client computer.
The public key must be exported in a valid OpenSSH format using the Export User Key to OpenSSH format tool. The resulting public key (*.pub) must be appended to the authorized_keys file in the user’s .ssh directory on the host.
Note that a global key pair grants a user access to any account on the host where the public key has been appended. For more information, click Help on the Secure Shell tab.
- Per user: The more secure option is to generate or import a separate and unique public/private key pair for each user. You can use any method to generate the key pair, including the "Generate User Key" functionality in Windows-based Reflection.
The public key must be appended to the authorized_keys file in the user’s .ssh directory on the host, and the key pair must be stored in the client’s.ssh folder.
Note: If not generated locally on the client machine, the public/private key pair needs to be securely transported to the client's Java store. (Sending them by email is not recommended.)
Creating the .ssh Folder
If you are configuring ssh to use a per user key pair, you need to manually create the .ssh folder (to store the key pair). In Windows, you must use a command prompt because Windows Explorer does not support creating folder names that begin with a dot (.ssh, for example).
Before you create the .ssh folder, check this section to identify the appropriate location for the .ssh folder, which varies with the version of Reflection for the Web, the operating system on the client machine, the client browser, and the client java virtual machine.
In Reflection for the Web 9.01 and higher (Windows only), create the .ssh folder in the \reflectionweb folder, which is in the CSIDL APPDATA directory (usually the user’s localized Application Data directory).
For example, on a Windows XP client running Internet Explorer and either the Microsoft VM or the Sun JVM 1.3 or higher, the keypair is stored in C:\documents and settings\<username>\Application Data\reflectionweb\.ssh.
In Reflection for the Web 8.0 and 9.0 (Windows only) and 9.01 and higher (non-Windows), create the .ssh folder in the \reflectionweb folder, which is within either {user.dir} or {user.home} depending on the operating system, client browser and client java virtual machine.
For example, for Reflection 8.0 or 9.0 on a Windows XP client running Internet Explorer and either the Microsoft VM or the Sun JVM 1.3 or higher, the keypair should be stored in C:\documents and settings\<username>\reflectionweb\.ssh.
For more information about file locations, see KB 7022221.
To create the .ssh folder in Windows:
- Open a command prompt (Start > Programs > Accessories > Command Prompt)
- Enter either of these commands, where <folder_location> is the location specified above for your version of Reflection for the Web and the other variables.
mkdir <folder_location>\.ssh or
md <folder_location>\.sshAppending a Key
Methods for appending a key to the authorized_keys file vary depending on your environment. Two examples of methods you can use to transfer the public key from a Windows system to a UNIX host and then add it to the authorized_keys file are described below:
- Use an FTP client to transfer the file (named, for example, MyKey.pub) in ASCII mode to the users' home directory's .ssh subfolder on the host. Enter the following command to add the key to the end of the authorized_keys file without overwriting any existing keys in the file:
cat MyKey.pub >> authorized_keys- Cut-and-paste from the Windows Clipboard. Make a Telnet or SSH connection to your host using a VT terminal session. Open the authorized_keys file in a UNIX text editor such as vi or emacs. Position the cursor at the end of the file and use insert mode. In Notepad, open the public key file on the PC, copy the contents from Notepad, and then paste the contents into the UNIX editor.
Using Keyboard Interactive Authentication
Beginning in Reflection for the Web 9.5, keyboard interactive allows password authentication, SecurID authentication, or other tokens for authentication. Using Keyboard interactive does not in itself add any extra security.
The advantage of keyboard interactive authentication is that new authentication methods can be added without upgrading the client software, since the client does not need to be aware of the specifics of the authentication method.
Using Multiple Authentication Methods
If you select both Password and User Key check boxes, the user key is verified first. If the user key is valid, the session is allowed. If the user key is not valid, the user must enter a password to be validated.
If all three authentication options are selected (in version 9.5), the connection attempt first uses the User Key, then Keyboard Interactive, and finally the Password option until authentication is successful