Filter
Top Products
1101 and 1102 Secure Device Servers
724-746-5500 | blackbox.com
154
Each client will then need its own set of keys uploaded through the same page. Take care to ensure that the correct type of keys (DSA or RSA) go in
the correct spots, and that the public and private keys are in the correct spot.
(*"+"- !
SDT Connector can authenticate against a console servers using your SSH key pair, rather than requiring you to enter your password (i.e. public key
authentication).
To use public key authentication with SDT Connector, you must first create an RSA or DSA key pair (using ssh-keygen, PuTTYgen or a similar tool)
and add the public part of your SSH key pair to the Black Box gateway—as described in the earlier section.
Next, add the private part of your SSH key pair (this file is typically named id_rsa or id_dsa) to SDT Connector client. Click Edit -> Preferences ->
Private Keys -> Add, locate the private key file, and click OK. You do not have to add the public part of your SSH key pair, it is calculated using the
private key.
SDT Connector will now use public key authentication when SSH connecting through the console server. You may have to restart SDT Connector
to shut down any existing tunnels that were established using password authentication.
If you have a host behind the console server that you connect to by clicking the SSH button in SDT Connector, you can also configure it for public
key authentication. Essentially what you are using is SSH over SSH, and the two SSH connections are entirely separate, and the host configuration is
entirely independent of SDT Connector and the console server. You must configure the SSH client that SDT Connector launches (e.g. Putty,
OpenSSH) and the host’s SSH server for public key authentication.
(*", !$%
Secure Sockets Layer (SSL) is a protocol developed by Netscape for transmitting private documents via the Internet. SSL works by using a private key
to encrypt data that's transferred over the SSL connection.
The console server includes OpenSSL. The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured, and Open
Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general
purpose cryptography library. The project is managed by a worldwide community of volunteers that use the Internet to communicate, plan, and
develop the OpenSSL toolkit and its related documentation.
OpenSSL is based on the excellent SSLeay library developed by Eric A. Young and Tim J. Hudson. The OpenSSL toolkit is licensed under an Apache-
style license, which basically means that you are free to get and use it for commercial and non-commercial purposes subject to some simple license
conditions. In the console server, OpenSSL is used primarily in conjunction with ‘http’ to have secure browser access to the GUI management
console across insecure networks.
More documentation on OpenSSL is available from:
http://www.openssl.org/docs/apps/openssl.html
http://www.openssl.org/docs/HOWTO/certificates.txt
(*"-
The Management Console can be served using HTTPS by running the webserver via sslwrap. The server can be launched on request using inetd.
The HTTP server provided is a slightly modified version of the fnord-httpd from
The SSL implementation is provided by the sslwrap application compiled with OpenSSL support. You can find more detailed documentation at
If your default network address is changed or the unit is to be accessed via a known Domain Name, you can use the following steps to replace the
default SSL Certificate and Private Key with ones tailored for your new address.
(*"-"(!!
To create a 1024 bit RSA key with a password, issue the following command on the command line of a linux host with the openssl utility installed:
openssl genrsa -des3 -out ssl_key.pem 1024
(*"-")#
This example shows how to use OpenSSL to create a self-signed certificate. OpenSSL is available for most Linux distributions via the default package
management mechanism. (Windows users can check
)