Tripp Lite 0 Idades Manual

							231
Chapter 15: Advanced Configuration
15.6.2  Generating Public Keys (Linux)
To generate new SSH key pairs use the Linux ssh-keygen command. This will produce an RSA or DSA public/private key pair 
and you will be prompted for a path to store the two key files e.g. id_dsa.pub (the public key) and id_dsa (the private key). For 
example: 
$ ssh-keygen -t [rsa|dsa]
Generating public/private [rsa|dsa] key pair.
Enter file in which to save the key (/home/user/.ssh/id_[rsa|dsa]):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_[rsa|dsa]. 
Your public key has been saved in /home/user/.ssh/id_[rsa|dsa].pub.
The key fingerprint is:
28:aa:29:38:ba:40:f4:11:5e:3f:d4:fa:e5:36:14:d6 user@server
$
It is advisable to create a new directory to store your generated keys. \
It is also possible to name the files after the device they 
will be used for.  For example:
$ mkdir keys
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):  /home/user/keys/control_room
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/keys/control_room
Your public key has been saved in /home/user/keys/control_room.pub.
The key fingerprint is:
28:aa:29:38:ba:40:f4:11:5e:3f:d4:fa:e5:36:14:d6 user@server
$
You must ensure there is no password associated with the keys.  If there \
is a password, then the Console Server devices will 
have no way to supply it as runtime.
Full documentation for the ssh-keygen command can be found at http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-keygen
15.6.3  Installing the SSH Public/Private Keys (Clustering)
For Console Servers the keys can be simply uploaded through the web inter\
face, on the System: Administration page. This 
enables you to upload stored RSA or DSA Public Key pairs to the Master and apply the Authorized key to the slave and is \
described in Chapter 4. Once complete you then proceed to Fingerprinting\
 as described below.   
						

							232
Chapter 15: Advanced Configuration
15.6.4  Installing SSH Public Key Authentication (Linux)
Alternately the public key can be installed on the unit remotely from th\
e linux host with the scp utility as follows. 
Assuming the user on the Management Console is called "fred"; the IP add\
ress of the Console Server is 192.168.0.1 
(default); and the public key is on the linux/unix computer in ~/.ssh/id_dsa.pub. Execute the following command on the linux/
unix computer:
scp ~/.ssh/id_dsa.pub \
[email protected]:/etc/config/users/fred/.ssh/authorized_keys
The authorized_keys file on the Console Server needs to be owned by "f\
red", so login to the Management Console as root and 
type:
chown fred /etc/config/users/fred/.ssh/authorized_keys
Master
Slave
Slave
-----BEGIN RSA 
PRIVATE KEY-----
MIIEogIBAAKCAQEA
yIPGsNf5+a0LnPUMc
nujXXPGiQGyD3b79
KZg3UZ4MjZI525sCy
opv4TJTvTK6e8QIYt
GYTByUdI
id_rsa
id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2Efg4+tGHlAAA== name@client1
authorized_key
ssh-rsa 
AAAAB3NzaC1yc2Efg4+t
GHlAAA==name@client1ssh-rsa 
AAAAB3NzaC1yc2Efg4+t
GHlAAA==name@client1
authorized_key  
						

							233
Chapter 15: Advanced Configuration
If the Console Server device selected to be the server will only have on\
e client device, then the authorized_keys file is simply 
a copy of the public key for that device. If one or more devices will be\
 clients of the server, then the authorized_keys file will 
contain a copy of all of the public keys. RSA and DSA keys may be freely\
 mixed in the authorized_keys file. For example, 
assume we already have one server, called bridge_server, and two sets of keys, for the control_room and the plant_entrance: 
$ ls /home/user/keys control_room control_room.pub plant_entrance plant_\
entrance.pub $ cat /home/user/keys/control_room.
pub /home/user/keys/plant_entrance.pub > /home/user/keys/authorized_keys\
_bridge_server
Master
Slave
-----BEGIN RSA 
PRIVATE KEY-----
MIIEogIBAAKCAQEA
yIPGsNf5+a0LnPUMc
nujXXPGiQGyD3b79
KZg3UZ4MjZI525sCy
opv4TJTvTK6e8QIYt
GYTByUdI
id_rsa
id_rsa.pub
ssh-rsa 
AAAAB3NzaC1yc2Efg4+tG
HlAAA== name@client1
authorized_keys
ssh-rsa AAAAB3NzaC1yc2Efg4+tGHl
AAA== name@client1
ssh-dss AAAAB3NzaZr+OV01C8gdgz
XDg== name@client2
Master
-----BEGIN DSA 
PRIVATE KEY-----
MIIBugIBAAKBgQCR
kixjJ0SKuiREXTM
x0PFp9HqBvEg7Ww9
oynY4QNiXj1YU7T 87ITLQiAhn3yp7ZWy 7Z5C3sLF8o46Go
id_dsa
id_dsa.pub
ssh-dss 
AAAAB3NzaZr+OV01C8gdgz
XDg== name@client2
 
More documentation on OpenSSH can be found at: 
http://openssh.org/portable.html
http://www.openbsd.org/cgi-bin/man.cgi?query=ssh&sektion=1
http://www openbsd.org/cgi-bin/man.cgi?query=sshd.
15.6.5  Generating public/private keys for SSH (Windows)
This section describes how to generate and configure SSH keys using Windows. 
First create a new user from the Console Server Management Console (the\
 following example uses a user called "testuser") 
making sure it is a member of the "users" group.
If you do not already have a public/private key pair you can generate th\
em now using ssh-keygen, PuTTYgen or a similar tool: 
PuTTYgen: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
OpenSSH: http://www.openssh.org/
OpenSSH (Windows): http://sshwindows.sourceforge.net/download/
For example using PuTTYgen, make sure you have a recent version of the puttygen.exe (available from http://www.chiark.
greenend.org.uk/~sgtatham/putty/download.html) Make sure you have a recent version of WinSCP 
(available from http://winscp.net/eng/download.php)
To generate a SSH key using PuTTY http://sourceforge.net/docs/F02/#clients:
• Execute the PUTTYGEN.EXE program
• Select the desired key type SSH2 DSA (you may use RSA or DSA) within the Parameters section
• It is important that you leave the passphrase field blank  
						

							234
Chapter 15: Advanced Configuration
• Click on the Generate button
• Follow the instruction to move the mouse over the blank area of the progr\
am in order to create random data used by 
PUTTYGEN to generate secure keys. Key generation will occur once PUTTYGEN has collected sufficient random data
• Create a new file " authorized_keys " (with notepad) and copy your p\
ublic key data from the "Public key for pasting into 
OpenSSH authorized_keys file" section of the PuTTY Key Generator, and paste the key data to the "authorized_keys" file. 
Make sure there is only one line of text in this file
• Use WinSCP to copy this "authorized_keys" file into the user’s home dire\
ctory: eg. /etc/config/users/testuser/.ssh/
authorized_keys of the Console Server which will be the SSH server. You will need to make sure this file is in the correct 
format with the correct permissions with the following commands: 
 # dos2unix  \
 /etc/config/users/testuser/.ssh/authorized_keys && chown testuser \
 /etc/config/users/testuser/.ssh/authorized_keys
• Using WinSCP copy the attached sshd_config over /etc/config/sshd_config on the server (Makes sure public key 
authentication is enabled)
• Test the Public Key by logging in as "testuser" Test the Public Key by logging in as "testuser" to the client Console Server 
device and typing (you should not need to enter anything): # ssh -o St\
rictHostKeyChecking=no 
To automate connection of the SSH tunnel from the client on every power-up you need to make the clients /etc/config/rc.local 
look like the following:
#!/bin/sh
ssh -L9001:127.0.0.1:4001 -N -o StrictHostKeyChecking=no testuser@ & 
This will run the tunnel redirecting local port 9001 to the server port \
4001.
15.6.6   Fingerprinting
Fingerprints are used to ensure you are establishing an SSH session to who you think you are.  On the first connection to a 
remote server you will receive a fingerprint which you can use on futu\
re connections.   
						

							235
Chapter 15: Advanced Configuration
This fingerprint is related to the host key of the remote server. Fingerprints are stored in ~/.ssh/known_hosts.
To receive the fingerprint from the remote server, log in to the client as the required user (usually root) and establi\
sh a 
connection to the remote host:
# ssh remhost
The authenticity of host 'remhost (192.168.0.1)' can't be established.\
RSA key fingerprint is 8d:11:e0:7e:8a:6f:ad:f1:94:0f:93:fc:7c:e6:ef:56.
Are you sure you want to continue connecting (yes/no)?
At this stage, answer yes to accept the key.  You should get the following message:
Warning: Permanently added 'remhost,192.168.0.1' (RSA) to the list of known hosts.
You may be prompted for a password, but there is no need to log in - you \
have received the fingerprint and can press Ctrl-C 
to cancel the connection. If the host key changes you will receive the f\
ollowing warning, and not be allowed to connect to the 
remote host:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@     WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!        @
@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!       @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Someone could be eavesdropping on you right now (man-in-the-middle atta\
ck)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
ab:7e:33:bd:85:50:5a:43:0b:e0:bd:43:3f:1c:a5:f8.
Please contact your system administrator.
Add correct host key in /.ssh/known_hosts to get rid of this message.
Offending key in /.ssh/known_hosts:1
RSA host key for remhost has changed and you have requested strict checking.
Host key verification failed.
If the host key has been legitimately changed, it can be removed from th\
e ~/.ssh/known_hosts file and the new fingerprint 
added.  If it has not changed, this indicates a serious problem that sho\
uld be investigated immediately.
15.6.7  SSH tunneled serial bridging
You have the option to apply SSH tunneling when two Black Box console servers are configured for ser\
ial bridging. 
As detailed in Chapter 4, the Server console server is setup in Console Server mode with either RAW or RFC2217 enabled and 
the Client console server is set up in Serial Bridging Mode with the Server Addres\
s, and Server TCP Port (4000 + port for RAW 
or 5000 + port # for RFC2217) specified:  
						

							236
Chapter 15: Advanced Configuration
• Select SSH Tunnel when configuring the Serial Bridging Setting
Next you will need to set up SSH keys for each end of the tunnel and upload these keys to the Server a\
nd Client console 
servers.
Client Keys:
The first step in setting up ssh tunnels is to generate keys. Ideally, you will use a separate, secure, machine to generate and 
store all keys to be used on the Console Servers.  However, if this is not ideal to your situation, keys may be generated on the 
Console Servers themselves.
It is possible to generate only one set of keys, and reuse them for ever\
y SSH session.  While this is not recommended, each 
organization will need to balance the security of separate keys against \
the additional administration they bring.
Generated keys may be one of two types - RSA or DSA (and it is beyond t\
he scope of this document to recommend one over 
the other). RSA keys will go into the files id_rsa and id_rsa.pub.  DSA keys will be stored in the files id_dsa and id_dsa.pub.
For simplicity going forward the term private key will be used to refer to either id_rsa or id_dsa and public key to refer to either 
id_rsa.pub or id_dsa.pub.
To generate the keys using OpenBSD's OpenSSH suite, we use the ssh-keygen program:
$ ssh-keygen -t [rsa|dsa]
Generating public/private [rsa|dsa] key pair.
Enter file in which to save the key (/home/user/.ssh/id_[rsa|dsa]):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_[rsa|dsa]. 
Your public key has been saved in /home/user/.ssh/id_[rsa|dsa].pub.
The key fingerprint is:
28:aa:29:38:ba:40:f4:11:5e:3f:d4:fa:e5:36:14:d6 user@server
$  
						

							237
Chapter 15: Advanced Configuration
It is advisable to create a new directory to store your generated keys. \
It is also possible to name the files after the device they 
will be used for.  For example:
$ mkdir keys 
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):  /home/user/keys/control_room
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/keys/control_room
Your public key has been saved in /home/user/keys/control_room.pub.
The key fingerprint is:
28:aa:29:38:ba:40:f4:11:5e:3f:d4:fa:e5:36:14:d6 user@server
$
You should ensure there is no password associated with the keys.  If ther\
e is a password, then the Console Servers will have 
no way to supply it as runtime.
Authorized Keys: 
If the Console Server selected to be the server will only have one clien\
t device, then the authorized_keys file is simply a copy 
of the public key for that device. If one or more devices will be client\
s of the server, then the authorized_keys file will contain a 
copy of all of the public keys. RSA and DSA keys may be freely mixed in \
the authorized_keys file.
For example, assume we already have one server, called bridge_server, and two sets of keys, for the control_room and the 
plant_entrance:
$ ls /home/user/keys
control_room control_room.pub plant_entrance plant_entrance.pub
$ cat /home/user/keys/control_room.pub 
/home/user/keys/plant_entrance.pub > 
/home/user/keys/authorized_keys_bridge_server
Uploading Keys:
The keys for the server can be uploaded through the web interface, on th\
e System: Administration page as detailed earlier.  
If only one client will be connecting, then simply upload the appropriat\
e public key as the authorized keys file. Otherwise, 
upload the authorized keys file constructed in the previous step.
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 pri\
vate keys are in the correct spot.
15.6.8  SDT Connector Public Key Authentication 
SDT Connector can authenticate against a Console Server using your SSH key pair rather than requiring your to enter your 
password (i.e. public key authentication).
• To use public key authentication with SDT Connector, first 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 Console Server – 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 establ\
ished using password authentication.
If you have a host behind the Console Server that you connect to by clic\
king the SSH button in SDT Connector, you can also 
configure it for public key authentication. Essentially what you are u\
sing is SSH over SSH, and the two SSH connections 
are entirely separate, and the host configuration is entirely independ\
ent 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.    
						

							238
Chapter 15: Advanced Configuration
15.7 Secure Sockets L ayer (SSL) Support
Secure Sockets Layer (SSL) is a protocol developed by Netscape for transmitting private docume\
nts 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-gra\
de, 
full-featured, and Open Source toolkit implementing the Secure Sockets L\
ayer (SSL v2/v3) and Transport Layer Security (TLS 
v1) protocols as well as a full-strength general purpose cryptography l\
ibrary. The project is managed by a worldwide community 
of volunteers that use the Internet to communicate, plan, and develop th\
e 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 licence, which basically means that yo\
u are free to get and use it for commercial and 
non-commercial purposes subject to some simple license conditions. In th\
e Console Server OpenSSL is used primarily in 
conjunction with ‘http’ in order 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
15.8  HTTPS
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 http://www.fefe.de/fnord/
The SSL implementation is provided by the sslwrap application compiled with OpenSSL support. More detailed documentation 
can be found at http://www.rickk.com/sslwrap/
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.
15.8.1  Generating an encryption key
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
15.8.2  Generating a self-signed certificate with OpenSSL
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 http://www.openssl.org/related/binaries.html)
To create a 1024 bit RSA key and a self-signed certificate issue the following openssl command from the host you have 
openssl installed on:
openssl req -x509 -nodes -days 1000 \
-newkey rsa:1024 -keyout ssl_key.pem -out ssl_cert.pem
You will be prompted to enter a lot of information. Most of it doesn't ma\
tter, but the "Common Name" should be the domain 
name of your computer. When you have entered everything, the certificate will be created in\
 a file called ssl_cert.pem.  
						

							239
Chapter 15: Advanced Configuration
15.8.3  Installing the key and certificate
The recommended method for copying files securely to the Console Serve\
r unit is with an SCP (Secure Copying Protocol) 
client. The scp utility is distributed with OpenSSH for most Unix distributions while Windows users can use something like the 
PSCP command line utility available with PuTTY.
The files created in the steps above can be installed remotely with th\
e scp utility as follows:
scp ssl_key.pem root@:/etc/config/
scp ssl_cert.pem root@:/etc/config/
or using PSCP:
pscp -scp ssl_key.pem root@:/etc/config/
pscp -scp ssl_cert.pem root@:/etc/config/
PuTTY and the PSCP utility can be downloaded from: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
More detailed documentation on the PSCP can be found: 
http://the.earth.li/~sgtatham/putty/0.58/htmldoc/Chapter5.html#pscp
15.8.4  L aunching the HTTPS Server
Note that the easiest way to enable the HTTPS server is from the web Management Console. Simply click the appropri\
ate 
checkbox in Network: Services: HTTPS Server and the HTTPS server will be activated (assuming the ssl_key.pem & ssl_cert.
pem files exist in the /etc/config directory).
Alternatively inetd can be configured to launch the secure fnord server from the command line of the unit as follows.
Edit the inetd configuration file. From the unit command line:
vi /etc/config/inetd.conf
Append a line: 
443 stream tcp nowait root sslwrap -cert /etc/config/ssl_cert.pem -key\
 /etc/config/ssl_key.pem -exec /bin/httpd
/home/httpd"
Save the file and signal inetd of the configuration change.
kill -HUP `cat /var/run/inetd.pid`
The HTTPS server should be accessible from a web client at a URL similar to th\
is: https://
More detailed documentation about the openssl utility can be found at the website: http://www.openssl.org/  
						

							240
Chapter 15: Advanced Configuration
15.9  Power Strip Control 
The Console Server supports a growing list of remote power-control devices (RPCs) which can be configured using the 
Management Console as described in Chapter 8. These RPCs are controlled \
using the open source NUT and PowerMan tools 
and the pmpower utility.
15.9.1 PowerMan
PowerMan provides power management in a data center or compute cluster en\
vironment. It performs operations such as 
power on, power off, and power cycle via remote power controller (RPC) devices. Target hostnames are mapped to plugs on 
RPC devices in powerman.conf
powerman - power on/off nodes 
Synopsis
powerman [-option] [targets]
pm [-option] [targets] 
Options
-1, --on   Power ON targets. 
-0, --off  Power OFF targets. 
-c, --cycle  Power cycle targets. 
-r, --reset   Assert hardware reset for targets (if implemented by RPC). 
-f, --flash   Turn beacon ON for targets (if implemented by RPC). 
-u, --unflash  Turn beacon OFF for targets (if implemented by RPC). 
-l, --list   List available targets. If possible, output will be compressed into a ho\
st range (see TARGET 
SPECIFICATION below). 
-q, --query   Query plug status of targets. If none specified, query all targets. St\
atus is not cached; each 
time this option is used, powermand queries the appropriate RPC's. Targets connected to RPC's 
that could not be contacted (e.g. due to network failure) are reported\
 as status "unknown". If 
possible, output will be compressed into host ranges. 
-n, --node   Query node power status of targets (if implemented by RPC). If no targ\
ets are specified, query all 
targets. In this context, a node in the OFF state could be ON at the plu\
g but operating in standby 
power mode. 
-b, --beacon Query beacon status (if implemented by RPC). If no targets are specifi\
ed, query all targets. 
-t, --temp   Query node temperature (if implemented by RPC). If no targets are spec\
ified, query all targets. 
Temperature information is not interpreted by powerman and is reported as\
 received from the 
RPC on one line per target, prefixed by target name. 
-h, --help   Display option summary. 
-L, --license  Show powerman license information. 
-d, --destination host[:port]  Connect to a powerman daemon on non-default host and optionally port. 
-V, --version  Display the powerman version number and exit. 
-D, --device  Displays RPC status information. If targets are specified, only RPC's \
matching the target list are 
displayed. 
-T, --telemetry Causes RPC telemetry information to be displayed as commands are process\
ed. Useful for 
debugging device scripts. 
-x, --exprange Expand host ranges in query responses.
For more details refer http://linux.die.net/man/1/powerman. Also refer powermand (http://linux.die.net/man/1/powermand) 
documentation and powerman.conf (http://linux.die.net/man/5/powerman.conf)
Target Specification
powerman target hostnames may be specified as comma-separated or space-separat\
ed hostnames or host ranges. Host 
ranges are of the general form: prefix[n-m,l-k,...], where n < m and l\
 < k, etc., This form should not be confused with 
regular expression character classes (also denoted by ''[]''). For example, foo[19] does not represent foo1 or foo9, but rather 
represents a degenerate range: foo19. 
This range syntax is meant only as a convenience on clusters with a prefi\
x NN naming convention and specification of ranges 
should not be considered necessary -- the list foo1,foo9 could be specifi\
ed as such, or by the range foo[1,9].