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
