types you want to support in your sshd_config.
We use the ssh_version fact to determine the default hostkey types.
Only enable rsa and ed25519 for ssh versions greater or equal
to 6.5, otherwise enable rsa and dsa.
Some distributions, such as debian, also enable ecdsa as a hostkey
type, but this is a known bad NIST curve, so we do not enable that
by default (thus deviating from the stock sshd config)
Since it's possible to "include sshd::client" without using "include
sshd" (e.g. installing/managing ssh client but not the server) provide a
default value for $sshd_shared_ip also in the sshd::client class.
Signed-off-by: Gabriel Filion <lelutin@gmail.com>
A tentative option from rhatto using the variable named
$ssh_use_strong_ciphers still has two lines in init.pp
Since the same functionality is provided by the variable
$ssh_hardened_ssl that was merged in the shared repository, rhatto
removed his feature. But there are still two lines left, so simply
remove them.
Signed-off-by: Gabriel Filion <lelutin@gmail.com>
Conflicts:
templates/sshd_config/Debian_squeeze.erb
I always picked the shared repository version when conflicts arose.
The only exception to this rule was:
I kept my branch's "HostbasedUsesNameFromPacketOnly yes" in order
to be consistent with existing Etch and Lenny templates.
This is not the default Debian setting, but I would find it weird if a host
had this setting changed by Puppet after upgrading to Squeeze.
The right way to proceed would probably be to make this configurable.
The sshd class currently has a mechanism to make resources for Ubuntu
similar to the ones for Debian, but the sshd::client class doesn't.
Also, There are no templates for sshd_config on Ubuntu so provide for
them. Since Ubuntu releases almost all use ssh versions that are as
recent as the Debian squeeze one, and the default sshd_config file is
usually the same as on Debian, add a default (Ubuntu.erb) template so
that it fits all Ubuntu releases.
Signed-off-by: Gabriel Filion <lelutin@gmail.com>
Currently ssh_authorized_key has some logic about $user being false or
'', but it sets its value to default to 'root'.
So, in order to use the name as the user's name, one has to clear the
user parameter, which is totally redundant.
Since it is sometimes useful to publish multiple keys for a user, the
$user parameter is useful.
To make using ssh_authorized_key for one-key normal users simpler, make
$user default to being empty (which will use $name as the user name).
'root' can always be specified either via the name or by the $user
paramter.
Signed-off-by: Gabriel Filion <lelutin@gmail.com>
When one uses the $name to define the user that should receive an SSH
key, setting $user to a negative value, ssh_authorized_key currently
creates the authorized_keys file under /home/.ssh/authorized_keys
Fix this by changing ${user} to ${real_user} in the key's path.
Signed-off-by: Gabriel Filion <lelutin@gmail.com>
When the os of a client is not one of those that use a specialized
class, (e.g. FreeBSD) the inclusion is currently broken: it tries to
include sshd::default which does not exist.
Change this to include sshd::base instead.
Signed-off-by: Gabriel Filion <lelutin@gmail.com>
