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 there 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 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

Uploading Keys:

The keys for the server can be uploaded through the web interface, on the System: Administration page as detailed earlier. If only one client will

be connecting, then simply upload the appropriate public key as the authorized keys file. Otherwise, upload the authorized keys file constructed in

the previous step.

Client #1