openssh-formula/README.rst
alxwr aa3da8f2c2 Pillar openssh.known_hosts_salt_ssh (#128)
* Pillar openssh.known_hosts_salt_ssh

* Dropped ill-named file

* Fixed aliasing of host names

* Improved pillar.example

* Opt-in to include localhost

* pillar/known_hosts_salt_ssh: clear cache in run()

* Dropped forgotten debugging output
2018-06-01 14:11:52 +02:00

187 lines
5.9 KiB
ReStructuredText

openssh
=======
Install and configure an openssh server.
.. note::
See the full `Salt Formulas installation and usage instructions
<http://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html>`_.
Available states
================
.. contents::
:local:
``openssh``
-----------
Installs the ``openssh`` server package and service.
``openssh.auth``
-----------
Manages SSH certificates for users.
``openssh.auth_map``
-----------
Same functionality as openssh.auth but with a simplified Pillar syntax.
Plays nicely with `Pillarstack
<https://docs.saltstack.com/en/latest/ref/pillar/all/salt.pillar.stack.html>`_.
``openssh.banner``
------------------
Installs a banner that users see when SSH-ing in.
``openssh.client``
------------------
Installs the openssh client package.
``openssh.config``
------------------
Installs the ssh daemon configuration file included in this formula
(under "openssh/files"). This configuration file is populated
by values from pillar. ``pillar.example`` results in the generation
of the default ``sshd_config`` file on Debian Wheezy.
It is highly recommended ``PermitRootLogin`` is added to pillar
so root login will be disabled.
``openssh.config_ini``
----------------------
Version of managing ``sshd_config`` that uses the
`ini_managed.option_present <https://docs.saltstack.com/en/latest/ref/states/all/salt.states.ini_manage.html>`_
state module, so it enables to override only one or
multiple values and keeping the defaults shipped by your
distribution.
``openssh.known_hosts``
-----------------------
Manages the side-wide ssh_known_hosts file and fills it with the
public SSH host keys of your minions (collected via the Salt mine)
and of hosts listed in you pillar data. It's possible to include
minions managed via ``salt-ssh`` by using the ``known_hosts_salt_ssh`` renderer.
You can restrict the set of minions
whose keys are listed by using the pillar data ``openssh:known_hosts:target``
and ``openssh:known_hosts:tgt_type`` (those fields map directly to the
corresponding attributes of the ``mine.get`` function).
The **Salt mine** is used to share the public SSH host keys, you must thus
configure it accordingly on all hosts that must export their keys. Two
mine functions are required, one that exports the keys (one key per line,
as they are stored in ``/etc/ssh/ssh_host_*_key.pub``) and one that defines
the public hostname that the keys are associated to. Here's the way to
setup those functions through pillar::
# Required for openssh.known_hosts
mine_functions:
public_ssh_host_keys:
mine_function: cmd.run
cmd: cat /etc/ssh/ssh_host_*_key.pub
python_shell: True
public_ssh_host_names:
mine_function: grains.get
key: id
The above example assumes that the minion identifier is a valid DNS name
that can be used to connect to the host. If that's not the case, you might
want to use the ``fqdn`` grain instead of the ``id`` one. The above example
also uses the default mine function names used by this formula. If you have to
use other names, then you should indicate the names to use in pillar keys
``openssh:known_hosts:mine_keys_function`` and
``openssh:known_hosts:mine_hostname_function``.
You can also integrate alternate DNS names of the various hosts in the
ssh_known_hosts files. You just have to list all the alternate DNS names as a
list in the ``openssh:known_hosts:aliases`` pillar key. Whenever the IPv4 or
IPv6 behind one of those DNS entries matches an IPv4 or IPv6 behind the
official hostname of a minion, the alternate DNS name will be associated to the
minion's public SSH host key.
To **include minions managed via salt-ssh** install the ``known_hosts_salt_ssh`` renderer::
# in pillar.top:
'*':
- openssh.known_hosts_salt_ssh
# In your salt/ directory:
# Link the pillar file:
mkdir pillar/openssh
ln -s ../../formulas/openssh-formula/_pillar/known_hosts_salt_ssh.sls pillar/openssh/known_hosts_salt_ssh.sls
Pillar ``openssh:known_hosts:salt_ssh`` overrides the Salt Mine.
The pillar is fed by a host key cache. Populate it by applying ``openssh.gather_host_keys``
to the salt master::
salt 'salt-master.example.test' state.apply openssh.gather_host_keys
The state tries to fetch the SSH host keys via ``salt-ssh``. It calls the command as user
``salt-master`` by default. The username can be changed via Pillar::
openssh:
known_hosts:
salt_ssh:
user: salt-master
It's possible to define aliases for certain hosts::
openssh:
known_hosts:
salt_ssh:
public_ssh_host_names:
minion.id:
- minion.id
- alias.of.minion.id
You can use a cronjob to populate a host key cache::
# crontab -e -u salt-master
0 1 * * * salt 'salt-master.example.test' state.apply openssh.gather_host_keys
Or just add it to your salt master::
# states/top.sls:
base:
salt:
- openssh.known_hosts_salt_ssh
You can also use a "golden" known hosts file. It overrides the keys fetched by the cronjob.
This lets you re-use the trust estabished in the salt-ssh user's known_hosts file::
# In your salt/ directory: (Pillar expects the file here.)
ln -s /home/salt-master/.ssh/known_hosts ./known_hosts
# Test it:
salt-ssh 'minion' pillar.get 'openssh:known_hosts:salt_ssh'
To add **public keys of hosts not among your minions** list them under the
pillar key ``openssh:known_hosts:static``::
openssh:
known_hosts:
static:
github.com: 'ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq[...]'
gitlab.com: 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABA[...]'
Pillar ``openssh:known_hosts:static`` overrides ``openssh:known_hosts:salt_ssh``.
To **include localhost** and local IP addresses (``127.0.0.1`` and ``::1``) use this Pillar::
openssh:
known_hosts:
include_localhost: True
``openssh.moduli``
-----------------------
Manages the system wide ``/etc/ssh/moduli`` file.