keys.conf

(NOTE:  Some of the techniques shown or described on this page--marked in purple--require new features in the latest official PIKT 1.19.0 release (pikt-current.tar.gz) that are unavailable in any previous version.)

For authentication purposes (and among other authentication methods), also to encrypt master-slave network traffic, PIKT uses the PIKT.conf settings uid, gid, data_encryption_type, auth_encryption_type, and private_key, for example (from a sample PIKT.conf):

uid                     3817379002                      // defaults to 0
gid                     7117260626                      // defaults to 0
...
data_encryption_type    1                               // blowfish
auth_encryption_type    1                               // blowfish
private_key             "8z0 9234bvd; lkjn!z-ne0)s@"  // defaults to
                                                        // "CHANGE_ME"

What if uid, gid, data_encryption_type, auth_encryption_type, and private_key were common across your PIKT domain?  If one managed to crack any system in that domain, one would have access to all common secrets.

To solve this problem, you may use per-slave uid, gid, data_encryption_type, auth_encryption_type, and private_key settings.

On the piktmaster, these settings are activated by the presence in the etcdir (the directory where PIKT.conf resides) of the file keys.conf.  Your etcdir/keys.conf file might look something like the following:

// host, uid, gid, private_key, data_encryption_type & auth_encryption_type
vienna          334292319       963813343       "23gb-[098425ybdbfz;lo3q4"    1    1
nantes          343343411       1043232633      "P)(Q#Rgfjl334ljbq2345;jl"    1    1
berlin          1001239167      1009006239      "234ag-09_)(*lkj24bn;ljfg"    1    1
madrid          482887821       92579099        "Q<^6 +Z9:ec!LVL&Zi7O`L0    0
...

With those settings, vienna's PIKT.conf must have

uid                     334292319
gid                     963813343
...
data_encryption_type    1
auth_encryption_type    1
private_key             "23gb-[098425ybdbfz;lo3q4"

nantes' PIKT.conf must have

uid                     343343411
gid                     1043232633
...
data_encryption_type    1
auth_encryption_type    1
private_key             "P)(Q#Rbgf;jl334;ljbq2345;jl"

berlin's PIKT.conf must have

uid                     1001239167
gid                     1009006239
...
data_encryption_type    1
auth_encryption_type    1
private_key             "234ag-09_)(*lkj24bn;ljfg"

madrid's PIKT.conf must have

uid                     482887821
gid                     92579099
...
data_encryption_type    0
auth_encryption_type    0
private_key             "Q<^6 +Z9:ec!LVL&Zi7O`Land so on for every other host registered in the piktmaster's systems.cfg.
            
Then, the piktmaster piktc will use the vienna keys when communicating with vienna's piktc_svc, the nantes keys when communicating with the nantes piktc_svc, and so on.  If there is any mismatch between a slave's PIKT.conf uid, gid, data_encryption_type, auth_encryption_type, and private_key and their corresponding values registered in the piktmaster keys.conf, authentication will fail, and the requested service will be denied, and/or master-slave network traffic will be garbled.
            
How does one get the keys out to each slave PIKT.conf?  One way to do it is to open up a secure session to the slave (using ssh most likely), and hand-edit in that slave's uid, gid, data_encryption_type, auth_encryption_type, and private_key.
            
But, with PIKT, there is a much better way.
            
First off, you should manage your PIKT.conf files from the central PIKT configuration.  In your piktmaster files.cfg, you should have the directive
            
#include 
Your files/pikt_conf_files.cfg should look as follows:
            
//////////////////////////////////////////////////////////////////////////

PIKT.conf       path "/pikt/etc/PIKT.conf" mode 640 uid 0 gid 0

#fix
        //////////////////////////////////////////////////////////////////

        // general piktc-to-piktc_svc access parameters

        // these are all required

        //uid   0
#unfix
        uid     =piktuid
        gid     =piktgid
#fix
        master  vienna.uppity.edu
        domain  uppity.edu
        access  local   // access may be "local" or "global"

...

#unfix
        data_encryption_type            =piktdataenctyp
        auth_encryption_type            =piktauthenctyp
        private_key                     =piktprivate_key
#fix

        //////////////////////////////////////////////////////////////////
#unfix

//////////////////////////////////////////////////////////////////////////
=piktuid, =piktgid, =piktdataenctyp, =piktauthenctyp, and =piktprivate_key are pre-defined, built-in macros, much like =piktdir, =pikthostname, etc.  =piktuid resolves to the uid setting for the current host.  So for example, if piktc were installing PIKT.conf to vienna, =piktuid would resolve to 334292319, =piktgid would resolve to 963813343, =piktdataenctyp would resolve to 1, =piktauthenctyp would resolve to 1, and =piktprivate_key would resolve to "23gb-[098425ybdbfz;lo3q4".  As piktc turns its attention to installing PIKT.conf to different systems, the macro resolutions would resolve differently, based on the keys.conf settings, for each different system.
            
There is a gotcha when installing PIKT.conf from files/pikt_conf_files.cfg.  If vienna has the indicated uid, gid, data_encryption_type, auth_encryption_type, and private_key settings in its PIKT.conf, if you change those settings to something else in the piktmaster keys.conf, you have introduced a mismatch, service will be denied, and your 'piktc -iv +F PIKT.conf +H vienna' operation will fail.  What to do?
            
You may make use of a special piktc option, -Q for "install PIKT.conf", to solve this problem.  'piktc -Q' bypasses the usual PIKT install mechanism to rely instead on scp (the "secure copy" program distributed with Ssh or OpenSsh) and piktx, which itself relies internally on ssh.
            
If you issue the command 'piktc -Qv +H vienna', you would see this:
            
processing vienna...
killing daemon (piktc_svc)...
installing PIKT.conf...
PIKT.conf installed
restarting daemon (piktc_svc)...
determining piktc_svc pid...
daemon (re)started
Behind the scenes, piktc:
            

              
invokes piktx to kill the running piktc_svc (if any) on the slave
              
invokes piktx, which invokes scp to install the revised PIKT.conf on the slave
              
invokes piktx to set the proper ownerships and permissions on the newly installed PIKT.conf
              
invokes piktx to (re)start piktc_svc on the slave
              
checks the piktc_svc pid, to see if the (re)start was successful
            
To update the keys for a single system, say vienna, you would edit its line in keys.conf, then push the revised PIKT.conf out to vienna with the command 'piktc -Qv +H vienna'.  'piktc -Qv +H all' (or perhaps 'piktc -Qv -H down') would push updated PIKT.conf files to all systems.  'piktc -Q' takes as much as a minute or two per system, so updating keys across all systems is not something you'll want to do often.
            
In order for this all to work, you MUST
            

              
manage your PIKT.conf from files/pikt_conf_files.cfg in the manner described above
              
have both scp and ssh working from piktmaster to all slaves, with no password prompts or other blocking prompts (such as when a host key change is detected)
              
have a working piktx
              
have defined the following UNIX command paths and PIKT directories in all relevant macros/unixcmds_*_macros.cfg files (and/or in macros.cfg):
                
  =psall
  =grep
  =awk
  =xargs
  =kill
  =scp
  =chmod
  =chown
  =chgrp
  =etcdir
  =bindir
See the PIKT lib/configs_samples for the suggested way to do this.
              
            
If you haven't done the setup correctly, your results are uncertain.  Most likely your 'piktc -Q' will fail.
            
For each host in keys.conf, you may:
            

              

              
list the uid, gid, data_encryption_type, auth_encryption_type, and private_key
              
list just the uid, gid, and private_key
              
list just the uid and gid
              
list just the private_key
              
omit the host entirely
              
mention the hosts more than once, in which case the values set last are the ones that apply
            
For example, these are all legitimate keys.conf settings.
            
vienna          334292319       963813343       "23gb-[098425ybdbfz;lo3q4"    1    1
nantes          343343411       1043232633
berlin                                          "234ag-09_)(*lkj24bn;ljfg"
madrid          482887821       92579099        "Q<^6 +Z9:ec!LVL&Zi7O`L0    0
nantes          898573211       483450870
...
nantes                                          "vb-0xf%-r0s* #$%^ 8vw-bs"
For any missing settings, they default to the piktmaster's values.
            
In this example, assume that vienna is the piktmaster.  (There is no need for the piktmaster to go first.  It could go anywhere in the keys.conf file.  If the piktmaster were missing entirely from the keys.conf file, its settings would be those established in its PIKT.conf file.)
            
If there was only one berlin line as shown, its uid-gid-private_key settings would be
            
                334292319       963813343       "234ag-09_)(*lkj24bn;ljfg"    1    1
If the nantes settings were specified as above, its resultant settings would be
            
                898573211       483450870       "vb-0xf%-r0s* #$%^ 8vw-bs"    1    1
In other words, it's not a grievous mistake to omit a host from the keys.conf file.  The host(s) will assume the uid, gid, data_encryption_type, auth_encryption_type, and private_key of the piktmaster.  It's not terribly bad to omit the piktmaster, since it (and any missing hosts) will assume the uid, gid, data_encryption_type, auth_encryption_type, and private_key from its (the piktmaster's) existing PIKT.conf file.  Nor is it bad (but it would be confusing!) to list a host more than once in keys.conf.  The last listed values will apply.
            
Note that one implication of this flexibility is that you could have a keys.conf file with private_key settings only, leaving out any uid-gid-data_encryption_type-auth_encryption_type settings (in which case the uid-gid-data_encryption_type-auth_encryption_type settings would default to those in the piktmaster's PIKT.conf).
            
Note also that, since the madrid data_encryption_type & auth_encryption_type are both 0 (i.e., madrid authentication and network traffic are not encrypted), you must list all of madrid's key attributes,
            
madrid          482887821       92579099        "Q<^6 +Z9:ec!LVL&Zi7O`L0    0

in particular data_encryption_type & auth_encryption_type, otherwise by omitting them they would default to the the vienna piktmaster's (1 & 1, which would conflict with the 0 & 0 settings in madrid's PIKT.conf).
            
Having said all the above, we should add that in the typical setup, data_encryption_type & auth_encryption_type are the same everywhere, i.e., both 1 on every host, or (less likely, since it is not as secure), both 0 on every host.  If that is the case, in keys.conf you really only need to specify uid, gid & private_key, for example
            
vienna          334292319       963813343       "23gb-[098425ybdbfz;lo3q4"
...

omitting data_encryption_type & auth_encryption_type.  (You must still register those settings in every host's PIKT.conf, however.)  The piktmaster's data_encryption_type & auth_encryption_type, as specified in its PIKT.conf, are then assumed to apply site-wide.  Or it might be that you have just one or two "troublesome" hosts, so you might add the data_encryption_type & auth_encryption_type in keys.conf for just those two host lines (as in the madrid example just above), leaving all other keys.conf lines with just the uid, gid & private_key line (as shown in the vienna example immediately preceding).
            
In other words, in most situations, this is how you might best do your keys.conf:
            
vienna          334292319       963813343       "23gb-[098425ybdbfz;lo3q4"
...  [more of the same]
madrid          482887821       92579099        "Q<^6 +Z9:ec!LVL&Zi7O`L0    0
...  [the exceptions, if any]

            
It goes without saying that keys.conf should be on the piktmaster only (in its etcdir).  Do not manage your keys.conf as you would PIKT manage other files (in files.cfg), for then you might mistakenly install your keys.conf file onto one or all of the slave systems!
            
There is a PIKT utility, rkey, for generating keys.conf entries, or that file in its entirety.  Note that rkey will generate the uid, gid & private_key only.  You would add any data_encryption_type & auth_encryption_type manually.  See rkey for more details.

            

            

              

                

 prev page

                
1st page
                

next page