[chef] Re: Re: Re: Creating authorized_keys for LDAP users.


Chronological Thread 
  • From: Matt Juszczak < >
  • To:
  • Subject: [chef] Re: Re: Re: Creating authorized_keys for LDAP users.
  • Date: Tue, 10 Mar 2015 11:33:54 -0400

You could always use Augeus…. http://augeas.net. I’ve used this elsewhere ;
before, but not sure how well it would function in Chef.

-Matt

> On Mar 10, 2015, at 11:22 AM, Morgan Blackthorne 
> < >
>  wrote:
> 
> I have not, but I think that that's somewhat irrelevant. No matter if I 
> store them on disk (which would be preferred as it's simplest, especially 
> as we mandate proxy usage in the datacenter), or use a command to look the 
> keys up, I still need to alter the sshd_config file. My question is how 
> best to do that without replacing the entire file; while I would like to 
> standardize our config, there are simply too many distros and versions of 
> distros in play for me to feel comfortable biting that off right now.
> 
> --
> ~*~ StormeRider ~*~
> 
> "Every world needs its heroes [...] They inspire us to be better than we 
> are. And they protect from the darkness that's just around the corner."
> 
> (from Smallville Season 6x1: "Zod")
> 
> On why I hate the phrase "that's so lame"... http://bit.ly/Ps3uSS
> 
> On Tue, Mar 10, 2015 at 8:16 AM, Matt Juszczak 
> < >
>  wrote:
> Have you looked into OpenSSH’ authorized_keys_command? Might be a nice way 
> to pull keys from github or another “trusted” source and not have them as 
> files on disk at all. YMMV.
> 
> > On Mar 10, 2015, at 11:03 AM, Morgan Blackthorne 
> > < >
> >  wrote:
> >
> > And our shop has not had much luck with SSSD, personally. We use a mix of 
> > RHEL, Oracle Linux, CentOS, Amazon Linux, Ubuntu, and Debian. I'd rather 
> > keep the SSH key piece separate from the LDAP piece... we already have an 
> > LDAP config that works.
> >
> > --
> > ~*~ StormeRider ~*~
> >
> > "Every world needs its heroes [...] They inspire us to be better than we 
> > are. And they protect from the darkness that's just around the corner."
> >
> > (from Smallville Season 6x1: "Zod")
> >
> > On why I hate the phrase "that's so lame"... http://bit.ly/Ps3uSS
> >
> > On Tue, Mar 10, 2015 at 7:41 AM, Ed Ropple 
> > < >
> >  wrote:
> > YMMV, but I'd reconsider the approach you're taking--"configuring users 
> > with LDAP" seems like the tail wagging the dog a little. I've had much 
> > better luck using SSSD to act as an authentication system that talks to 
> > LDAP instead. You can store public keys in your LDAP server, then, and 
> > SSSD will do the Right Thing. It's a huge step up over nslcd or ldapd.
> >
> > I've used it on both CentOS and Ubuntu, with significant success.
> >
> > Good luck!
> >
> > -Ed
> >
> > On Tue, Mar 10, 2015 at 10:15 AM, Morgan Blackthorne 
> > < >
> >  wrote:
> > So I'm actually looking to do this myself, though I want the config to be:
> >
> >     AuthorizedKeysFile "%h/.ssh/authorized_keys 
> > /etc/ssh/%u/authorized_keys"
> >
> > That way they can use manual keys in addition to the ones I'll be having 
> > chef drop in place. However, I'm not currently managing 
> > /etc/ssh/sshd_config. What's the best way to modify just that one line? 
> > I'm a bit uneasy about trying to just cookbook_file that, given how many 
> > different Linux distributions we have (Oracle, Redhat, Debian, Ubuntu, 
> > CentOS, etc).
> >
> > On Jan 26, 2015 4:15 PM, "Douglas Garstang" 
> > < >
> >  wrote:
> > Or... something like:
> >
> > AuthorizedKeysFile  /etc/ssh/authorized_keys/%u
> >
> > in /etc/ssh/sshd_config. The users account doesn't need to exist first, 
> > and it's owned by root and managed by chef, not the user.
> >
> > Doug.
> >
> > On Mon, Jan 26, 2015 at 3:56 PM, Douglas Garstang 
> > < >
> >  wrote:
> > Actually, I think it's time for a script.
> >
> > On Mon, Jan 26, 2015 at 3:55 PM, Douglas Garstang 
> > < >
> >  wrote:
> > So, it would seem this this is a general chef issue then. It's not an 
> > LDAP issue, or an ohai issue. It's a chef issue.
> >
> > A workaround for this limitation sure would be nice. Configuring user 
> > with LDAP and then being able to create their ssh keys seems like a 
> > pretty standard use case.
> >
> > Doug.
> >
> > On Mon, Jan 26, 2015 at 3:52 PM, Noah Kantrowitz 
> > < >
> >  wrote:
> > Chef and Ohai use the Etc library in Ruby, which in turn uses the 
> > standard getpw* and getgr* calls. These are configured by nsswitch.conf. 
> > If you go look this up, you'll see that that file is only read once for a 
> > given process and there is no universal way to clear the config. Some 
> > libcs offer non-standard calls for it, but I doubt any of those are 
> > exposed to Ruby.
> >
> > --Noah
> >
> > On Jan 26, 2015, at 3:29 PM, Douglas Garstang 
> > < >
> >  wrote:
> >
> > > Sorry to have to repeat myself, but I can't use 'owner' and 'group' on 
> > > resources. Even thought LDAP is configured, chef isn't able to see the 
> > > users and groups.
> > >
> > > David suggested I reload ohai. I had no idea this was necessary or 
> > > required, but I tried it anyway. I put this at the end of my ldap 
> > > cookbook.
> > >
> > > ohai "reload_passwd" do
> > >   plugin "etc"
> > > end
> > > log node['etc']['passwd']
> > >
> > > What I am seeing, (I'm using vagrant), is that on the first chef run, 
> > > the LDAP users are not in in the node structure. However, if I 
> > > reprovision, (without making any changes), then the users ARE there.
> > >
> > > In hindsight, isn't this just the typical node[] not being populated 
> > > until after the chef run issue?
> > >
> > > Doug.
> > >
> > > On Mon, Jan 26, 2015 at 3:22 PM, Lamont Granquist 
> > > < >
> > >  wrote:
> > > On 1/26/15 2:29 PM, Douglas Garstang wrote:
> > >> I'm having trouble setting up users authorized keys. A cookbook that 
> > >> runs earlier in the runlist sets up LDAP. However, due to reasons I 
> > >> don't understand, none of that user information is available during 
> > >> the chef run. I previously posted about this once before. As a result, 
> > >> I can't simply create files and directories and use 'owner' and 'group.
> > >>
> > >> I came up with the below idea. I'm iterating over the ssh keys in a 
> > >> data bag and then for each user running a command as this user. That 
> > >> makes PAM do all the home directory setup for me. I create the ~/.ssh 
> > >> directory in a similar fashion, as the user. All works ok. However, 
> > >> I'm having an issue with adding the array of ssh_keys pulled from the 
> > >> data bag to the users authorized keys file.
> > >>
> > >> include_recipe "slice-ldap"
> > >> bag = data_bag("ssh-keys")
> > >> for item in bag do
> > >>   user = data_bag_item('ssh-keys', item)
> > >>   user_name = user['id']
> > >>   ssh_keys = user['ssh_keys']
> > >>   execute "create_home_#{user_name}" do
> > >>     command "su - #{user_name} -c \"ls\""
> > >>     creates "/home/#{user_name}"
> > >>     notifies :run, "execute[create_ssh_dir_#{user_name}]", :immediately
> > >>   end
> > >>   execute "create_ssh_dir_#{user_name}" do
> > >>     command "su - #{user_name} -c \"mkdir /home/#{user_name}/.ssh\""
> > >>     notifies :run, "execute[install_public_rsa_#{user_name}]", 
> > >> :immediately
> > >>     creates "/home/#{user_name}/.ssh"
> > >>   end
> > >>   ssh_keys.each_with_index do |k, index|
> > >>     log "k = #{k}"
> > >>     execute "install_public_rsa_#{user_name}" do
> > >>       command "su - #{user_name} -c \"echo '#{k}' >> 
> > >> /home/#{user_name}/.ssh/authorized_keys\""
> > >>       action :nothing
> > >>     end
> > >>   end
> > >> end
> > >>
> > >> However, I'm having an issue with adding the array of ssh_keys pulled 
> > >> from the data bag to the users authorized keys file. The loop at the 
> > >> end does this, but chef also gives me this warning:
> > >>
> > >> ==> default: [2015-01-26T22:23:47+00:00] WARN: Previous 
> > >> execute[install_public_rsa_doug]: 
> > >> /tmp/vagrant-chef-3/chef-solo-1/cookbooks/slice-ssh-keys/recipes/default.rb:38:in
> > >>  `block (2 levels) in from_file'
> > >> ==> default: [2015-01-26T22:23:47+00:00] WARN: Current  
> > >> execute[install_public_rsa_doug]: 
> > >> /tmp/vagrant-chef-3/chef-solo-1/cookbooks/slice-ssh-keys/recipes/default.rb:38:in
> > >>  `block (2 levels) in from_file'
> > >>
> > >>
> > >> Apart from the warning, only the last ssh keys is being added to the 
> > >> authorized_keys file. Even though I'm using echo and >>, the last one 
> > >> is not there. The log statement shows each key, so I know the loop is 
> > >> iterating over both. What gives?
> > >>
> > >> Doug
> > >>
> > > Yeah the warning is trying to tell you the problem.  You're defining 
> > > multiple resources called `execute[install_public_rsa_doug]` and the 
> > > resource collection and the way notifies and subscribes is implemented 
> > > requires unique names.  So you're getting resource cloning and you're 
> > > only notifying one of those blocks.  You could add the index to then 
> > > name and then subscribe to the previous resources:
> > >
> > >   ssh_keys.each_with_index do |k, index|
> > >     log "k = #{k}"
> > >     execute "install_public_rsa_#{user_name}_#{index}" do
> > >       command "su - #{user_name} -c \"echo '#{k}' >> 
> > > /home/#{user_name}/.ssh/authorized_keys\""
> > >       subscribes :run, "execute[#{create_ssh_dir_#{user_name}]"
> > >       subscribes :run, "execute[#{create_home_#{user_name}]"
> > >       action :nothing
> > >     end
> > >   end
> > >
> > > You'll be way better off just doing this though:
> > >
> > > file "/home/#{user_name}" do
> > >   owner user_name
> > >   group user_name  # or "users" or whatever
> > >   mode "0600"
> > > end
> > >
> > > file "/home/#{user_name}/.ssh" do
> > >   owner user_name
> > >   group user_name
> > >   mode "0600"
> > > end
> > >
> > > file "/home/#{user_name}/.ssh/authorized_keys" do
> > >   owner user_name
> > >   group user_name
> > >   mode "0600"
> > >   content ssh_keys.join("\n")
> > > end
> > >
> > > That's idempotent, you don't need the action :nothing or any 
> > > notifications or subscriptions, you can push new keys out and it'll 
> > > correctly update, gets the job done with fewer resources, etc.  
> > > Similarly executing to su is a huge antipattern, so you can replace the 
> > > rest of that.
> > >
> > >
> > >
> > >
> > > --
> > > Regards,
> > >
> > > Douglas Garstang
> > > http://www.linkedin.com/in/garstang
> > > Email: 
> > > 
> > > Cell: +1-805-340-5627
> >
> >
> >
> >
> > --
> > Regards,
> >
> > Douglas Garstang
> > http://www.linkedin.com/in/garstang
> > Email: 
> > 
> > Cell: +1-805-340-5627
> >
> >
> >
> > --
> > Regards,
> >
> > Douglas Garstang
> > http://www.linkedin.com/in/garstang
> > Email: 
> > 
> > Cell: +1-805-340-5627
> >
> >
> >
> > --
> > Regards,
> >
> > Douglas Garstang
> > http://www.linkedin.com/in/garstang
> > Email: 
> > 
> > Cell: +1-805-340-5627
> >
> >
> 
> 




Archive powered by MHonArc 2.6.16.

§