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.