(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)[email protected]@5" // 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`L<e" 0 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`L<e"and 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 <files/pikt_conf_files.cfg>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)startedBehind 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
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 =bindirSee the PIKT lib/configs_samples for the suggested way to do this.
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
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`L<e" 0 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 1If the nantes settings were specified as above, its resultant settings would be
898573211 483450870 "vb-0xf%-r0s* #$%^ 8vw-bs" 1 1In 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`L<e" 0 0in 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`L<e" 0 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|