Boleslaw, you're saying strange things. First of all, Cfengine will only authorize remote files copying if a client is known and matches its host key, so that a client can't grab somebody else's IP and get their files (because keys won't match).
Next, you can add encrypt => "true" to your copy_from body when it comes to transferring sensitive data like password hashes, you don't neet to invent the wheel. Last, but not least, in the server access rules bundle you can strictly define which client has access to any given resource. 2011/6/15 Tokarski Boleslaw <boleslaw.tokar...@tieto.com>: > Hello, deb, > > We have a similar setup and this has bugged me for some time. We have > workstations to manage and their actual users have sudo rights, so there > is no way to forbid them to see the actual .cf files, so putting all the > hashes to one .cf file was not an option. > > For your server setup, the following solution may or may not be > acceptable, you need to assess if the security is good enough for you. > > On the policy server you generate the hashes per-server, each in > seperate file, for which you specify ACLs in cfengine's body server > control. This way only the agent with the IP address allowed by the > server will have access to its password hash. > On the agent side you can use cfengine to replace the /etc/shadow hash > with the one provided. > > Obviously this solution requires you to have DNS (or static hosts) > mapping made right, or rely on IP addresses only. > > IP security is weak security and because in our case we cannot rely on > IP addresses (workstations may get a different IP from the DHCP server > on each boot; we also have laptops). We could use a solution like the > one above if it was possible to create cfengine server-side ACL that > would allow hosts by their public cfengine key. I have been told that > the CF team is working on this and it might be possible in the future. > > However in the meanwhile we needed a prviate client-server channel that > would not be overheard by other clients, even those which are 'trusted' > by the server. We have implemented our push mechanism with XML-RPC (you > can have a look at it at http://dozzie.jarowit.net but I suppose you > would be using your own tool). Once in a while cfengine would run > xmlrpcaller module to acquire a new password hash for the system. > > I hope this helps. > > Best regards, > B > > On 06/14/2011 07:51 PM, no-re...@cfengine.com wrote: >> Forum: Cfengine Help >> Subject: Updating shadow encrypted fields >> Author: debheller >> Link to topic: https://cfengine.com/forum/read.php?3,22438,22438#msg-22438 >> >> Here's a bit of a brain-twister for y'all... Say, for example, you maintain >> a very large group of Linux servers. All access by users accounts are >> managed through SSH keys. But the root account, itself, is a passwd'd >> account. >> >> All of these systems in this very large group need to have the root password >> changed. However, while we might want to use the same passwd for the root >> accounts (which can only be logged into from the console - not the network, >> or accessed via rights from sudo), we do NOT want to use the same encrypted >> string on every system. >> >> This means I need to generate the string on the client. One way I can think >> of is to use: >> >> /usr/bin/openssl passwd -1 newpasswdhere >> >> This would generate the appropriate system string like this: >> >> $1$GVn1KByt$1KRkJsBsVXyevjyH9d/WA1 >> >> This could then be used in an edit_line (from cf3-tutorial): >> >> "/tmp/shadow" # this will be /etc/shadow when we want >> to go live >> edit_line => set_user_field("root",2,"$1$PwWfN9MN$4Blm.M3vCE2bUm.H2NXop0"); >> >> Is there a better way? Has someone already done this, and if so, would you >> be willing to share? I am not sure how to do this - It must be done only >> once, and since the encrypted string will be different on each host, you >> can't check for a static value that has been replaced on subsequent cf-agent >> runs. What would be the best way to know that the change has occurred? >> >> Thoughts? >> >> _______________________________________________ >> Help-cfengine mailing list >> Help-cfengine@cfengine.org >> https://cfengine.org/mailman/listinfo/help-cfengine >> > > _______________________________________________ > Help-cfengine mailing list > Help-cfengine@cfengine.org > https://cfengine.org/mailman/listinfo/help-cfengine > -- SY, Seva Gluschenko. _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
