Grant Basic Access to Owned Query Engines

How to allow access to a user who owns one or more CGE query engines.

The Cray Graph Engine (CGE) query engine and CGE CLI commands use your SSH configuration to obtain public and private keys for use in authentication.  Configuring basic query engine authentication is almost the same as configuring SSH passwordless authentication to the localhost IP host for your login account.  The steps involved in granting basic access to your query engine are listed below:
  1. Ensure that you have a .ssh directory in your home directory and that the directory permissions are 700 (rwx------).
    To find out whether you have a .ssh directory, and whether or not it is correctly protected, use the following command:
    $ ls -ld $HOME/.ssh
    drwx------  6 username  group  204 Nov 20 07:15 /users/username/.ssh
    If this looks correct you can move on to the next step.  If the directory does not exist at all, you will need to create it, as shown below:
    $ mkdir $HOME/.ssh
    $ chmod 700 $HOME/.ssh
    $ ls -ld $HOME/.ssh
    drwx------  6 username  group  204 Nov 20 07:15 /users/username/.ssh
    If the directory does not have the correct permissions, you can simply change those. However, it is important to ensure that the directory is writable only by you. As long as this requirement is met, you do not need to change anything.  The following command can be used if it is required to set the permissions on the directory:
    $ chmod 700 $HOME/.ssh
    $ ls -ld $HOME/.ssh
    drwx------  6 username  group  204 Nov 20 07:15 /users/username/.ssh
  2. Create a public / private authentication key pair using ssh-keygen if the key pair does not currently exist. Use the following command to find out whether or not a public / private key pair has been configured.
    Note: The following shows only key files (there will probably be other files as well unless this is a brand new .ssh directory):
    $ ls -l $HOME/.ssh
    total 80
    -rw------- 1 username group   668 Apr  8  2014 id_dsa
    -rw-r--r-- 1 username group   601 Apr  8  2014 id_dsa.pub
    -rw------- 1 username group   883 Apr  8  2014 id_rsa
    -rw-r--r-- 1 username group   221 Apr  8  2014 id_rsa.pub
    In the above example, there may be only an RSA key pair (id_rsa and id_rsa.pub), only a DSA key pair (id_dsa and id_dsa.pub) or both.  A file with ".pub" in its name is a public key file.  A file without ".pub" in its name is a private key file.  All of your private key files should have -rw------- for their permissions as shown above.  Your public key files may be readable (not writable) by anyone, but do not need to be, so the permissions shown above are okay, but not required. The minimum permission set that should be used is -rw------- , this enables reading and modifying the file. The maximum permission set should have -rw-r--r-- , which permits other users to read but not modify the public key. If there is not even a single public/private key pair in the .ssh directory, an SSH key will need to be generated .  This can be done using the ssh-keygen command:
    $ ssh-keygen
    Generating public/private rsa key pair.
    Enter file in which to save the key (/users/username/.ssh/id_rsa):
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in /users/username/.ssh/id_rsa.
    Your public key has been saved in /users/username/.ssh/id_rsa.pub.
    The key fingerprint is:
    eb:0d:10:cd:4f:4b:f1:2b:20:87:99:82:93:b5:8d:ee [MD5] username@host
    The key's randomart image is:
    +--[ RSA 2048]----+
    |    .     .      |
    |   + + *   o     |
    |  + + B = o .    |
    |   o . + = . .   |
    |    . . S + .    |
    |   .   . . .     |
    |    E   o        |
    |       . o       |
    |        . .      |
    +--[MD5]----------+
    $ ls -l $HOME/.ssh
    total 8
    -rw------- 1 username group 1679 Jan  6 11:49 id_rsa
    -rw-r--r-- 1 username group  391 Jan  6 11:49 id_rsa.pub
    This produces a public / private key pair which can be used for passwordless authentication to localhost. 
    Note: At present, CGE does not support ssh-agent forwarding, so it is not recommended to specify a pass-phrase when creating a key.
  3. Place the public authentication key in the .ssh/authorized_keys file. This will enable interacting with CGE query engines started by the user on this machine (it does not allow other users to use the user's query engines). Set this up as follows:
    $ cat $HOME/.ssh/id_*.pub >> $HOME/.ssh/authorized_keys
    $ chmod 644 $HOME/.ssh/authorized_keys
    $ ls -l $HOME/.ssh
    total 80
    -rw-r--r-- 1 username group  2601 Jun 18  2014 authorized_keys
    -rw------- 1 username group   668 Apr  8  2014 id_dsa
    -rw-r--r-- 1 username group   601 Apr  8  2014 id_dsa.pub
    -rw------- 1 username group   883 Apr  8  2014 id_rsa
    -rw-r--r-- 1 username group   221 Apr  8  2014 id_rsa.pub
  4. Test using ssh to log into localhost without a password. The simplest way to test this is to try connecting to localhost through SSH. This will have the effect of logging on to the same host the the user is currently logged on to:
    $ ssh localhost
    The authenticity of host 'localhost (::1)' can't be established.
    ECDSA key fingerprint is 0a:34:d6:d9:71:b4:6c:e6:1d:49:95:ea:7d:09:54:89 [MD5].
    Are you sure you want to continue connecting (yes/no)? yes
    Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
    Last login: Tue Jan  6 11:56:10 2015 from localhost
    -------------------------------------------------------------------------------
    Message of the day...
    -------------------------------------------------------------------------------
    $ exit
    As you can see, the first time you do this, you will be prompted to verify that the key for localhost is correct.  The user will also be prompted like this the first time the user tries to connect with a query engine with a new TCP/IP port number, so it is a good idea to do an interactive query or other kind of front-end command before trying to use a new query engine port from a script or other automated environment.  Once authenticity of the host / port pair has been verified, this pair will be added automatically to your list of known hosts and the user should not need to do this again. To avoid the need for performing the interactive Host Key verification step, see Eliminating the Interactive Host Key Verification Steps. To show that this works, try a second attempt to use SSH to log into localhost:
    $  ssh localhost
    Last login: Tue Jan  6 11:56:10 2015 from localhost
    -------------------------------------------------------------------------------
    Message of the day...
    -------------------------------------------------------------------------------
    $ exit
    $
  5. Once this has been set up, it is required to authenticate the localhost / <port number> pairs for all query engine ports so that the clients can connect non-interactively. To do this, start CGE on each port you intend to use and  run an interactive request through CGE, once for each port.  The cge-cli echo command provides a simple way of doing so, as shown in the following example:
    $ cge-cli echo --db-port=73737
    The authenticity of host 'localhost' can't be established.
    RSA key fingerprint is d2:b4:ad:70:f1:44:d3:8a:f5:16:db:db:76:07:19:47.
    Are you sure you want to continue connecting? [Yes/No]: yes  
    13835 [main] WARN com.cray.cge.cli.communications.client.ssh.LoggingBridge  - Permanently added 'localhost' (RSA) to the list of known hosts.
    14110 [main] INFO com.cray.cge.cli.commands.debug.EchoCommand  - Sending echo request...
    14157 [main] INFO com.cray.cge.cli.lightweight.commands.debug.EchoCommand  - Echoed data received and validated successfully
    
    To avoid the need for performing the interactive Host Key verification step, see Eliminating the Interactive Host Key Verification Steps.