Re: [Puppet-users] AuthorizedKeys...Type?
Luke Kanies
> So I'm staring at solution 1, which is the native type, which
> currently
> just manages the stuff in /etc/ssh/* keys. I'm looking for tips on how
> to extent and/or replace that type to add the following functionality:
>
> * management of arbitrary "authorized_keys" (/etc/ssh/ssh_known_hosts,
> /home/anarcat/.ssh/authorized_keys...)
> * generation of ssh keys (/etc/ssh/ssh_host_[rd]sa_key{,.pub},
> /home/anarcat/.ssh/id_[rd]sa{,.pub}
> * generation of revocation certificates
>
> From what I can see, right now, the Sshkey type could be extended to
> the
> the first item in there. I *think* we would need a seperate type for
> the
> second and third one, and I think the current type should therefore be
> renamed to "ssh_authorized_keys".
I agree with most of your analysis, I guess.
The only strange thing about managing authorized_keys is that a given
key might be in more than one file, so you'd need a parameter that
specified where the key is stored (e.g., user => [root, luke]) and
this parameter would need some special term that indicated it should
be stored in the primary known_hosts file rather than a user's file.
As to renaming it, I assume you want that because you want some other
type named 'sshkey' that can generate the keys. I don't think that
ssh_authorized_key is a very good name, esp. since it will also manage
host keys. It might be more reasonable to have an 'ensure =>
generated' value or something to the main key type, so it would
generate them if necessary, which should be easy enough.
I don't even know what a revocation cert is, or at least I didn't know
you could do them wth ssh, so I've no idea how to go about doing that.
>
> Any bright ideas on the path I should follow? I won't have time to
> work
> on that for the next two weeks, so feel free to take your time to
> bring
> valuable input that would save myself valuable time in my first native
> type. :)
Again, your biggest complication will be supporting the same key in
multiple places. Otherwise, it shouldn't be too hard to extend the
existing type to get the behaviour you want.
--
A great many people think they are thinking when they are merely
rearranging their prejudices. -- William James
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
Francois Deppierraz
The Anarcat wrote:
> So I'm staring at solution 1, which is the native type, which currently
> just manages the stuff in /etc/ssh/* keys. I'm looking for tips on how
> to extent and/or replace that type to add the following functionality:
>
> * management of arbitrary "authorized_keys" (/etc/ssh/ssh_known_hosts,
> /home/anarcat/.ssh/authorized_keys...)
Which syntax were you thinking of ?
I have this one in mind.
ssh_authorized_key {"useless identifier":
ensure => present,
type => dsa
key => "AAAAB3NzaC...",
comment => "francois....@camptocamp.com",
target => "/root/.ssh/authorized_keys",
options => ["command=/bin/blah.sh", "from=1.2.3.4"],
}
Unfortunately, it seems currently impossible to get rid of the "useless
identifier" because puppet types don't support compound keys[1], right ?
> * generation of ssh keys (/etc/ssh/ssh_host_[rd]sa_key{,.pub},
> /home/anarcat/.ssh/id_[rd]sa{,.pub}
Yes, you also need a way to bring those public keys back on the
puppetmaster to be able to distribute them on other nodes. Exported
resources should allow that.
> * generation of revocation certificates
I never used that with openssh. For usual authorized_keys,
ensure=>absent should be sufficient, no ?
> From what I can see, right now, the Sshkey type could be extended to the
> the first item in there. I *think* we would need a seperate type for the
> second and third one, and I think the current type should therefore be
> renamed to "ssh_authorized_keys".
The known_hosts and authorized_keys do not share the exact same syntax.
IMHO, two different types are required.
> Any bright ideas on the path I should follow? I won't have time to work
> on that for the next two weeks, so feel free to take your time to bring
> valuable input that would save myself valuable time in my first native
> type. :)
I'd be interested is looking at the code you already have if any.
[1] http://reductivelabs.com/trac/puppet/wiki/ImprovedResourceIdentification
Evan Hisey
to how to hanlde this using file. The lack of a recursive copy is a
bit annoying( Or I am just doing something wrong).
On Fri, Mar 28, 2008 at 10:35 AM, Francois Deppierraz
<fran...@ctrlaltdel.ch> wrote:
>
> I'm quite interested in getting involved with this native type.
> ssh_authorized_key {"useless identifier":
> ensure => present,
> type => dsa
> key => "AAAAB3NzaC...",
> comment => "francois....@camptocamp.com",
> target => "/root/.ssh/authorized_keys",
> options => ["command=/bin/blah.sh", "from=1.2.3.4"],
> }
>
> Unfortunately, it seems currently impossible to get rid of the "useless
> identifier" because puppet types don't support compound keys[1], right ?
>
I do not think the Identifier is useless. It looks like a good way to
quickly ID which key goes to which server, should I have to make a
manual change somewhere and then change it in puppet. also a good way
to require a key be installed before setting up other services.
Evan
Francois Deppierraz
> I do not think the Identifier is useless. It looks like a good way to
> quickly ID which key goes to which server, should I have to make a
> manual change somewhere and then change it in puppet. also a good way
> to require a key be installed before setting up other services.
Yes, but in that case a better identifier would be a compound key
derivable from both the key and target attributes.
Evan Hisey
grep than a human readable name of a server. If I know the server name
it is alot faster to grep for that than to figure out a derivable key.
I may be missing something, so feel free to enlighten.
Evan
Frank Sweetser
> I have this one in mind.
>
> ssh_authorized_key {"useless identifier":
> ensure => present,
> type => dsa
> key => "AAAAB3NzaC...",
> comment => "francois....@camptocamp.com",
> target => "/root/.ssh/authorized_keys",
> options => ["command=/bin/blah.sh", "from=1.2.3.4"],
> }
This is definitely something I'd be interested in, and I just had a quick
comment on the syntax here.
First, is that you'll need to specify the user who's keys you're adding in.
At a minimum, the contents of the .ssh directory need to be owned by that user
(as well as has pretty restrictive perms on them), otherwise sshd will ignore
them.
Once you have the user specified in there somehow, it would be very useful to
just specify the home directory of the user, such as with traditional
~username syntax, rather than specifying the full path. This would allow it
to work on different machines that keep home directories in different
locations, and also let you do a sensible default target value of '~user/.ssh/'.
--
Frank Sweetser fs at wpi.edu | For every problem, there is a solution that
WPI Senior Network Engineer | is simple, elegant, and wrong. - HL Mencken
GPG fingerprint = 6174 1257 129E 0D21 D8D4 E8A3 8E39 29E3 E2E8 8CEC
Francois Deppierraz
> First, is that you'll need to specify the user who's keys you're adding in.
IMHO, this user attribute is not required in the native type itself, see
below.
> At a minimum, the contents of the .ssh directory need to be owned by that user
> (as well as has pretty restrictive perms on them), otherwise sshd will ignore
> them.
Yes, it might be interesting to add those permission checks.
> Once you have the user specified in there somehow, it would be very useful to
> just specify the home directory of the user, such as with traditional
> ~username syntax, rather than specifying the full path. This would allow it
> to work on different machines that keep home directories in different
> locations, and also let you do a sensible default target value of '~user/.ssh/'.
We could even get rid of the target attribute altogether by adding a
user attribute, but this will make the type less generic.
What if my sshd looks for authorized keys in
/etc/ssh/authorized_keys/%u.pub instead of ~%u/.ssh/authorized_keys, for
instance ? What if I want to store those public keys elsewhere because
I'm running two different sshd ?
I know that my examples may be looking kind of silly but I'm sure that
we'll be better off by keeping the native types the most basic possible.
Any other opinion ?
You can easily create the type you describe with something like that.
Well, except for the user home directory lookup which seems currently
unsupported by the file type.
define my_ssh_authorized_key($ensure, $key, $user) {
ssh_authorized_key{$user:
ensure => $ensure,
key => $key,
target => "/home/${user}/.ssh/authorized_keys",
}
}
Maybe we can even have both a user and a target attributes which are
mutually exclusive ?
Francois Deppierraz
> Not really seeing how a derived compund key is going ot be easier to
> grep than a human readable name of a server. If I know the server name
> it is alot faster to grep for that than to figure out a derivable key.
> I may be missing something, so feel free to enlighten.
No, it won't be easier to grep, but you won't need to create some
artificial identifier such as "my key on host srv1". You can always put
such a comment in the comment attribute.
Frank Sweetser
> Frank Sweetser wrote:
>
>> First, is that you'll need to specify the user who's keys you're adding in.
>
> IMHO, this user attribute is not required in the native type itself, see
> below.
>
>> At a minimum, the contents of the .ssh directory need to be owned by that user
>> (as well as has pretty restrictive perms on them), otherwise sshd will ignore
>> them.
>
> Yes, it might be interesting to add those permission checks.
>
>> Once you have the user specified in there somehow, it would be very useful to
>> just specify the home directory of the user, such as with traditional
>> ~username syntax, rather than specifying the full path. This would allow it
>> to work on different machines that keep home directories in different
>> locations, and also let you do a sensible default target value of '~user/.ssh/'.
>
> We could even get rid of the target attribute altogether by adding a
> user attribute, but this will make the type less generic.
>
> What if my sshd looks for authorized keys in
> /etc/ssh/authorized_keys/%u.pub instead of ~%u/.ssh/authorized_keys, for
> instance ? What if I want to store those public keys elsewhere because
> I'm running two different sshd ?
I didn't think about the system wide case, so that's one where the user might
not make sense. As for just sticking it somewhere, I certainly didn't mean to
imply that adding in a user would necessitate removing the target field,
merely that it would help in providing a useful default.
> I know that my examples may be looking kind of silly but I'm sure that
> we'll be better off by keeping the native types the most basic possible.
> Any other opinion ?
>
> You can easily create the type you describe with something like that.
> Well, except for the user home directory lookup which seems currently
> unsupported by the file type.
>
> define my_ssh_authorized_key($ensure, $key, $user) {
> ssh_authorized_key{$user:
> ensure => $ensure,
> key => $key,
> target => "/home/${user}/.ssh/authorized_keys",
> }
> }
The problem is that this recipe couldn't be easily used at the same time on
two different hosts, if those hosts each kept user home directories in a
different location. I might, for example, want to push the same key out to my
linux box in /home/fs/.ssh and an OSX box in /Users/fs/.ssh
> Maybe we can even have both a user and a target attributes which are
> mutually exclusive ?
I don't think they'd have to be mutually exclusive. Basically, what I was
picturing was this:
if (user is set)
ensure file is owned by that user
default target to ~user/.ssh
if (target is set)
override default target with configured value
So you'd end up having to specify at least one of the two, but both would work
fine.
Does that make more sense?
Jean-Baptiste Quenot
>
> Agreed this could be arelly useful type. Right now I am figuring out
> to how to hanlde this using file. The lack of a recursive copy is a
> bit annoying( Or I am just doing something wrong).
What is wrong with "recurse => true" on the "file" type?
However I didn't find how to set permissions for the files inside the
directory. Creating another "file" for eg .ssh/id_dsa conflicts with
File[".ssh"], so I ended up using exec { "chmod 600 .ssh/id_dsa" }.
Best regards,
--
Jean-Baptiste Quenot
http://caraldi.com/jbq/blog/
David Schmitt
Hash: SHA1
Which is why I believe that with this syntax, the "comment" field is
superfluous. Writing the comment into the namevar will also make the
implementation much easier (see ParsedFile and friends).
Regards, DavidS
- --
The primary freedom of open source is not the freedom from cost, but the free-
dom to shape software to do what you want. This freedom is /never/ exercised
without cost, but is available /at all/ only by accepting the very different
costs associated with open source, costs not in money, but in time and effort.
- -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFH7oKo/Pp1N6Uzh0URAvM/AJ9Lbk6aRunGXEjY1n7sSZM/PEehPgCfZX1z
TF7QdbNudL002rDYA90oPxo=
=RnEu
-----END PGP SIGNATURE-----
Evan Hisey
> > Agreed this could be arelly useful type. Right now I am figuring out
> > to how to hanlde this using file. The lack of a recursive copy is a
> > bit annoying( Or I am just doing something wrong).
>
> What is wrong with "recurse => true" on the "file" type?
>
> However I didn't find how to set permissions for the files inside the
> directory. Creating another "file" for eg .ssh/id_dsa conflicts with
> File[".ssh"], so I ended up using exec { "chmod 600 .ssh/id_dsa" }.
I was doing something wrong it seems, recurse was a bit vague for me
as to what it really did. I was setting the ensure wrong which was
given me an erro I was not groking.
Evan
Francois Deppierraz
> Which is why I believe that with this syntax, the "comment" field is
> superfluous. Writing the comment into the namevar will also make the
> implementation much easier (see ParsedFile and friends).
That's a good point.