Hi,
When i tested the type sshkey it does not update my ~/authorizedkey file
but the /etc/ssh/ssh_known_hosts file so it seem that there is an error
there ? i am using .17.2
sshkey { backup01:
ensure => present,
key =>
'AAAABddfgdfgdorifjkshdkjflsdgmfgmsdiugfmiugsdmiufgmuisdgfmsodugfHLrwDE$
type => ssh-rsa
}
i got:
core1:/root%(root)> more /etc/ssh/ssh_known_hosts
# HEADER: This file was autogenerated at Wed Jun 14 10:40:34 CEST 2006
# HEADER: by puppet. While it can still be managed manually, it
# HEADER: is definitely not recommended.
backup01 ssh-rsa AAAAsdgfdsfsdfsdf.....
It seems then that the file updated is not the good one. or then the sshkey type should be named the sshknowhost type but there is a problem somewhere here.
Lets say we talk about SSHkeys for user authentification as i understand it.
I think it also needs a "user" parameters to specify which user will get the keyfile updated. The file which have the keys are
~/.ssh/authorized_keys
user => ['root','backupuser']
Also, keys can have options like those from sshd manpage :
The options (if present) consist of comma-separated option specifica-
tions. No spaces are permitted, except within double quotes. The fol-
lowing option specifications are supported (note that option keywords are
case-insensitive):
from="pattern-list"
Specifies that in addition to public key authentication, the
canonical name of the remote host must be present in the comma-
separated list of patterns (`*' and `?' serve as wildcards). The
list may also contain patterns negated by prefixing them with
`!'; if the canonical host name matches a negated pattern, the
key is not accepted. The purpose of this option is to optionally
increase security: public key authentication by itself does not
trust the network or name servers or anything (but the key); how-
ever, if somebody somehow steals the key, the key permits an
intruder to log in from anywhere in the world. This additional
option makes using a stolen key more difficult (name servers
and/or routers would have to be compromised in addition to just
the key).
command="command"
Specifies that the command is executed whenever this key is used
for authentication. The command supplied by the user (if any) is
ignored. The command is run on a pty if the client requests a
pty; otherwise it is run without a tty. If an 8-bit clean chan-
nel is required, one must not request a pty or should specify
no-pty. A quote may be included in the command by quoting it
with a backslash. This option might be useful to restrict cer-
tain public keys to perform just a specific operation. An exam-
ple might be a key that permits remote backups but nothing else.
Note that the client may specify TCP and/or X11 forwarding unless
they are explicitly prohibited. Note that this option applies to
shell, command or subsystem execution.
environment="NAME=value"
Specifies that the string is to be added to the environment when
logging in using this key. Environment variables set this way
override other default environment values. Multiple options of
this type are permitted. Environment processing is disabled by
default and is controlled via the PermitUserEnvironment option.
This option is automatically disabled if UseLogin is enabled.
no-port-forwarding
Forbids TCP forwarding when this key is used for authentication.
Any port forward requests by the client will return an error.
This might be used, e.g., in connection with the command option.
no-X11-forwarding
Forbids X11 forwarding when this key is used for authentication.
Any X11 forward requests by the client will return an error.
no-agent-forwarding
Forbids authentication agent forwarding when this key is used for
authentication.
no-pty Prevents tty allocation (a request to allocate a pty will fail).
permitopen="host:port"
Limit local ``ssh -L'' port forwarding such that it may only con-
nect to the specified host and port. IPv6 addresses can be spec-
ified with an alternative syntax: host/port. Multiple permitopen
options may be applied separated by commas. No pattern matching
is performed on the specified hostnames, they must be literal
domains or addresses.
etc...see man sshd for complete list :)
so i think an "option" parameters would be handy too.
options => ['from=192.168.1.1','no-agent-forwarding']
As a last thing the doc should be update as it is obviously a cut and past from 'host' ;)
also i do think that the 'host' parameters is in fact the "option" parameters that was copypasted without change :) So i think addind options support is easy by renaming the "host" name to "options". One more tricky thing is the user part as it can be an array of user so it could affect the way puppet mmanage the entries in the key fileS.
regards,
Ghislain.
