saltstack-formulas/openssh-formula

openssh-formula

Install and configure an openssh server.

Table of Contents

General notes

See the full SaltStack Formulas installation and usage instructions.

If you are interested in writing or contributing to formulas, please pay attention to the Writing Formula Section.

If you want to use this formula, please pay attention to the FORMULA file and/or git tag, which contains the currently released version. This formula is versioned according to Semantic Versioning.

See Formula Versioning Section for more details.

If you need (non-default) configuration, please refer to:

• how to configure the formula with map.jinja
• the pillar.example file

Contributing to this repo

Commit message formatting is significant!!

Please see How to contribute for more details.

Available states

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.

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 state module, so it enables to override only one or multiple values and keeping the defaults shipped by your distribution.

openssh.known_hosts

Manages /etc/ssh/ssh_known_hosts 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_hostname:
    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 /etc/ssh/ssh_known_hosts. You just have to specify 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

You'll find the cached pubkeys in Pillar openssh:known_hosts:salt_ssh.

It's possible to define aliases for certain hosts:

openssh:
  known_hosts:
    cache:
      public_ssh_host_names:
        minion.id:
          - minion.id
          - alias.of.minion.id

The cache is populated 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:
    cache:
      user: salt-master

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

If you must have the latest pubkeys, run the state before all others:

# states/top.sls:
base:
  salt:
    # slooooow!
    - openssh.gather_host_keys

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

To prevent ever-changing IP addresses from being added to a host, use this:

openssh:
  known_hosts:
    omit_ip_address:
      - my.host.tld

To completely disable adding IP addresses:

openssh:
  known_hosts:
    omit_ip_address: true

openssh.moduli

Manages the system wide /etc/ssh/moduli file.

openssh._mapdata

Testing state which dumps the map.jinja values in /tmp/salt_mapdata_dump.yaml. This state is not called by any include but is mostly used by kitchen and Inspec infrastructure to validate map.jinja.

Testing

Linux testing is done with kitchen-salt.

Requirements

• Ruby
• Docker

$ gem install bundler
$ bundle install
$ bin/kitchen test [platform]

Where [platform] is the platform name defined in kitchen.yml, e.g. debian-9-2019-2-py3.

bin/kitchen converge

Creates the docker instance and runs the openssh main states, ready for testing.

bin/kitchen verify

Runs the inspec tests on the actual instance.

bin/kitchen destroy

Removes the docker instance.

bin/kitchen test

Runs all of the stages above in one go: i.e. destroy + converge + verify + destroy.

bin/kitchen login

Gives you SSH access to the instance for manual testing.

Testing with Vagrant

Windows/FreeBSD/OpenBSD testing is done with kitchen-salt.

Requirements

• Ruby
• Virtualbox
• Vagrant

Setup

$ gem install bundler
$ bundle install --with=vagrant
$ bin/kitchen test [platform]

Where [platform] is the platform name defined in kitchen.vagrant.yml, e.g. windows-81-latest-py3.

Note

When testing using Vagrant you must set the environment variable KITCHEN_LOCAL_YAML to kitchen.vagrant.yml. For example:

$ KITCHEN_LOCAL_YAML=kitchen.vagrant.yml bin/kitchen test      # Alternatively,
$ export KITCHEN_LOCAL_YAML=kitchen.vagrant.yml
$ bin/kitchen test

Then run the following commands as needed.

bin/kitchen converge

Creates the Vagrant instance and runs the openssh main states, ready for testing.

bin/kitchen verify

Runs the inspec tests on the actual instance.

bin/kitchen destroy

Removes the Vagrant instance.

bin/kitchen test

Runs all of the stages above in one go: i.e. destroy + converge + verify + destroy.

bin/kitchen login

Gives you RDP/SSH access to the instance for manual testing.

openssh-formula's Issues

auth_map: cant create options

Hello, I wanted to add some keys to my authorized_keys.

I need some options, like from="8.8.8.8" and command="uptime". I tried to create this entries with the auth_map state of this formula.

First problem

pillar file

openssh:
  ...
  auth_map:
    ssh_to_host:
      source: salt://ssh/keys
      users:
        user1:
          first-key:
            options:
              from=8.8.8.8
          second-key:
            options:
              command=uptime
...

I get the following result:

f,r,o,m,=,8,.,8,.,8,.,8 ssh-rsa ...

Second problem

In the authorized key file, values like IP-addresses need quotes, otherwise I get an error. How can I handle this problem?

openssh:
  ...
  auth_map:
    ssh_to_host:
      source: salt://ssh/keys
      users:
        user1:
          first-key:
            options:
              - from='8.8.8.8'
              - command='uptime'
...

I get the following error:

 Data failed to compile:
----------
    Rendering SLS 'base:openssh.auth_map' failed: while parsing a block mapping
  in "<unicode string>", line 60, column 7:
        - options: "["from='8.8.8.8'", "co ...
          ^
expected <block end>, but found '<scalar>'
  in "<unicode string>", line 60, column 19:
        - options: "["from='8.8.8.8'", "command='uptime'"]"

Please help me to answer my problems.

Subsystem sftp location for FreeBSD

The default sftp subsystem is currently set to /usr/lib/openssh/sftp-server . This causes sshfs to fail in FreeBSD, with the default config file. The error is

subsystem request for sftp by user deployer failed, subsystem not found

The location for sftp in FreeBSd is /usr/libexec/sftp-server. Currently I am manually setting the Subsystem in the pillars file

Subsystem: "sftp /usr/libexec/sftp-server"

Can this be added to the map.jinja file as a default?

Change file extension of `_pillar/known_hosts_salt_ssh.sls` to `.py`

@alxwr @aboe76 While introducing salt-lint to this repo, I came across this violation regarding this file:

Examining _pillar/known_hosts_salt_ssh.sls of type state
[206] Jinja variables should have spaces before and after: {{ var_name }}
_pillar/known_hosts_salt_ssh.sls:112
    return {'openssh': {'known_hosts': {'salt_ssh': config}}}

While it's easy to ignore this from a salt-lint perspective, shouldn't this Python file be given the appropriate file extension?

Using openssh.config To Configure Just Keys Fails

Using the openssh.config state to configure just SSH keys (leaving the minion's sshd configuration untouched) results in the following error:

primarymaster:
    Data failed to compile:
----------
    Cannot extend ID 'sshd_config' in 'base:openssh.config'. It is not part of the high state.
This is likely due to a missing include statement or an incorrectly typed ID.
Ensure that a state with an ID of 'sshd_config' is available
in environment 'base' and to SLS 'openssh.config'

Example pillar (keys truncated for brevity, but otherwise complete):

openssh:
  provide_rsa_keys: True
  rsa:
    private_key: |
      -----BEGIN RSA PRIVATE KEY-----
      MIIEowIBAAKC...
      -----END RSA PRIVATE KEY-----
    public_key: |
      ssh-rsa AAAAB3...

This is because of the require_in added to the key management states pointing to the sshd_config state, which doesn't exist if there's no sshd_config pillar defined. The use case here is admittedly a testing scenario where the distribution's default sshd config is fine, but I don't think that's too much of an edge case to support.

Wishlist: ability to include short hostname entries in known_hosts

openssh.known_hosts works great, except it only includes the fqdn in the entries.
In our environment we use 'search' in resolv.conf and thus often use short names.
This does not match the known hosts entry which uses the fqdn, and thus either asks the user to verify the host key or if strict checking is on it blocks the connection altogether.

It would be nice if there was an option to have the formula generate host-key entries using the short hostname in addition to the fqdn entries it already adds when using openssh.known_hosts.

[BUG] ssh_config multiple IdentityFile not supported

In my pillar I have

IdentityFile:
- ~/.ssh/id_rsa
- ~/.ssh/id_ed25519
- ~/.ssh/id_ecdsa

This Renders to:

Host *IdentityFile ~/.ssh/id_rsaIdentityFile ~/.ssh/id_ed25519IdentityFile ~/.ssh/id_ecdsa

It seems that ssh_config does not support multiple IdentityFile

any way to define multiple TCP ports?

Hi,

I wonder if there is anyway to define multiple ports for OpenSSH to listen to? I can't find how.
If it's not possible, do you think this option can be added?

Thanks.

Some minor version issues

Along with #98 (by the way, this isn't CentOS-specific; it's sshd-version specific. 6.5+ add ed25519 support, CentOS 6.10 is on OpenSSH 5.3), I have some other suggestions. Forgive me if they're present; I haven't read through all the mappings and such.

Note that these can be determined via something like {% set sshver = salt['pkg.version']('openssh-server').split('p')[0] | float %} in Jinja2 syntax (for CentOS; the 'openssh-server' should obviously be the actual package name). This conveniently lets you do things like:

{% if sshver > 6.5 %}
Option foo
{% else %}
OldOption bar
{% fi %}

I have a regex pattern that will also work on e.g. Sun's SSH if you'd like to make it even more flexible (though admittedly I haven't tested it on any of the BSDs).

That said, the inconsistencies I know of are:

• AuthorizedKeysCommandUser is, prior to OpenSSH 6.2, known as AuthorizedKeysCommandRunAs (I'd just recommend changing the option name in the sshd_config perhaps?)
• The "Secure Secure Shell" recommendations should probably be default. Here's a convenient list of supported Kex, Ciphers, etc. between CentOS 6.10 and 7.6 (OpenSSH 5.3 and OpenSSH 7.4 respectively):

CentOS 6:

| ssh2-enum-algos: 
|   kex_algorithms: (4)
|       diffie-hellman-group-exchange-sha256
|       diffie-hellman-group-exchange-sha1
|       diffie-hellman-group14-sha1
|       diffie-hellman-group1-sha1
|   server_host_key_algorithms: (1)
|       ssh-rsa
|   encryption_algorithms: (13)
|       aes128-ctr
|       aes192-ctr
|       aes256-ctr
|       arcfour256
|       arcfour128
|       aes128-cbc
|       3des-cbc
|       blowfish-cbc
|       cast128-cbc
|       aes192-cbc
|       aes256-cbc
|       arcfour
|       [email protected]
|   mac_algorithms: (9)
|       hmac-md5
|       hmac-sha1
|       [email protected]
|       hmac-sha2-256
|       hmac-sha2-512
|       hmac-ripemd160
|       [email protected]
|       hmac-sha1-96
|       hmac-md5-96
|   compression_algorithms: (2)
|       none
|_      [email protected]

CentOS 7:

| ssh2-enum-algos: 
|   kex_algorithms: (12)
|       curve25519-sha256
|       [email protected]
|       ecdh-sha2-nistp256
|       ecdh-sha2-nistp384
|       ecdh-sha2-nistp521
|       diffie-hellman-group-exchange-sha256
|       diffie-hellman-group16-sha512
|       diffie-hellman-group18-sha512
|       diffie-hellman-group-exchange-sha1
|       diffie-hellman-group14-sha256
|       diffie-hellman-group14-sha1
|       diffie-hellman-group1-sha1
|   server_host_key_algorithms: (4)
|       ssh-rsa
|       rsa-sha2-512
|       rsa-sha2-256
|       ssh-ed25519
|   encryption_algorithms: (12)
|       [email protected]
|       aes128-ctr
|       aes192-ctr
|       aes256-ctr
|       [email protected]
|       [email protected]
|       aes128-cbc
|       aes192-cbc
|       aes256-cbc
|       blowfish-cbc
|       cast128-cbc
|       3des-cbc
|   mac_algorithms: (10)
|       [email protected]
|       [email protected]
|       [email protected]
|       [email protected]
|       [email protected]
|       [email protected]
|       [email protected]
|       hmac-sha2-256
|       hmac-sha2-512
|       hmac-sha1
|   compression_algorithms: (2)
|       none
|_      [email protected]

Which means, as per #26, the respective recommended defaults should then be:

CentOS 6:

• KexAlgorithms diffie-hellman-group-exchange-sha256
• Ciphers aes256-ctr,aes192-ctr,aes128-ctr
• MACs hmac-sha2-512,hmac-sha2-256

CentOS 7:

• KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256
• Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr
• MACs [email protected],[email protected],[email protected],hmac-sha2-512,hmac-sha2-256,[email protected]

Per @aboe76's concerns in #26 (comment), I have tested from both PuTTY and the built-in Windows SSH client (in Windows 10). All keys work as expected (PuTTY-generated RSA4096 and ED25519, Windows' ssh-keygen rsa with default options and ed25519 with default options; the RSA keys on both CentOS 6 and 7, the ED25519 keys on CentOS 7).

Deprecated sshd options

I am using this formula to manage openssh in small home environment, and while applying some states I came across deprecation warnings in the sshd logs of a Fedora 26 minion:

$ journalctl -u sshd
Jul 22 12:51:24  systemd[1]: Starting OpenSSH server daemon...
Jul 22 12:51:24  sshd[12040]: /etc/ssh/sshd_config line 23: Deprecated option UsePrivilegeSeparation
Jul 22 12:51:24  sshd[12040]: /etc/ssh/sshd_config line 26: Deprecated option KeyRegenerationInterval
Jul 22 12:51:24  sshd[12040]: /etc/ssh/sshd_config line 27: Deprecated option ServerKeyBits
Jul 22 12:51:24  sshd[12040]: /etc/ssh/sshd_config line 45: Deprecated option RSAAuthentication
Jul 22 12:51:24  sshd[12040]: /etc/ssh/sshd_config line 54: Deprecated option RhostsRSAAuthentication
Jul 22 12:51:24  sshd[12040]: Could not load host key: /etc/ssh/ssh_host_dsa_key
Jul 22 12:51:24  sshd[12040]: Server listening on 0.0.0.0 port 22.
Jul 22 12:51:24  sshd[12040]: Server listening on :: port 22.
Jul 22 12:51:24  systemd[1]: Started OpenSSH server daemon.

(I don't have the deprecated options specified in Pillar.)

I did a little research and it seems to be that these options were removed from the sshd_config file in recent versions of OpenSSH 7, in preparation of removing support for SSH protocol 1. This makes sense as Fedora 26 uses version 7.5 of OpenSSH and I don't get these warnings when running the state on Centos 7.3 systems which are using version 6.6 of OpenSSH.

This isn't a major issue as nothing is broken of course, but I thought it might be a good idea to bring it up.

Jinja error: variable 'dict object' has no attribute 'ssh_config'

Since 29b89f0 rendering of openssh/files/ssh_config is broken.

Pull request is on its way.

enforce DSA and ECDSA host key lengths too

That should be accomplished with just some minor modifications

FreeBSD fails with no package name

In FreeBSD 11, the run of this state fails because there is no package listed in the map, which is correct since there is no package ( pkg install sshd is not a thing ). However, there is no logic to not install the package that doesnt exist, resulting in a failed state, like below.

What is a good way to handle this? We could just {%if .. %} around the package installation to avoid it, or is there something more proper to ensure ssh is in-fact installed.

I'm happy to do the patch if anyone has an opinion about how it would be best to make it function.

----------
          ID: openssh-server
    Function: pkg.latest
      Result: False
     Comment: An exception occurred in this state: Traceback (most recent call last):
                File "/usr/local/lib/python2.7/site-packages/salt/state.py", line 1746, in call
                  **cdata['kwargs'])
                File "/usr/local/lib/python2.7/site-packages/salt/loader.py", line 1704, in wrapper
                  return f(*args, **kwargs)
                File "/usr/local/lib/python2.7/site-packages/salt/states/pkg.py", line 1879, in latest
                  **kwargs)
                File "/usr/local/lib/python2.7/site-packages/salt/modules/pkgng.py", line 318, in latest_version
                  ).pop(0)
              IndexError: pop from empty list
     Started: 18:17:46.085997
    Duration: 491.426 ms
     Changes:
----------

uname -a
FreeBSD server 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0 r306420: Thu Sep 29 01:43:23 UTC 2016     [email protected]:/usr/obj/usr/src/sys/GENERIC  amd64

Ubuntu Bug

I'm running into a bug when using this with Ubuntu 14.04. I enabled it in my top.sls, but it fails to run on Ubuntu and spits out this error:

    Data failed to compile:
----------
    Rendering SLS "base:openssh" failed: Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/salt/utils/templates.py", line 77, in render_tmpl
    output = render_str(tmplstr, context, tmplpath)
  File "/usr/lib/python2.7/dist-packages/salt/utils/templates.py", line 169, in render_jinja_tmpl
    output = jinja_env.from_string(tmplstr).render(**unicode_context)
  File "/usr/lib/python2.7/dist-packages/jinja2/environment.py", line 969, in render
    return self.environment.handle_exception(exc_info, True)
  File "/usr/lib/python2.7/dist-packages/jinja2/environment.py", line 742, in handle_exception
    reraise(exc_type, exc_value, tb)
  File "<template>", line 1, in top-level template code
  File "/usr/lib/python2.7/dist-packages/jinja2/environment.py", line 1013, in make_module
    return TemplateModule(self, self.new_context(vars, shared, locals))
  File "/usr/lib/python2.7/dist-packages/jinja2/environment.py", line 1070, in __init__
    self._body_stream = list(template.root_render_func(context))
  File "/var/cache/salt/minion/files/base/openssh/map.jinja", line 50, in top-level template code
    {% set openssh = salt['pillar.get'](
TypeError: get() got an unexpected keyword argument 'merge'

----------

Implement 'Secure Secure Shell' best practices

The Secure Secure Shell article outlines some best practices to increase the security of the SSH client and server configuration.

The server part could be implemented in this formula.

It should be enabled by default, but it should be possible to disable or weaken it a bit as AFAIK there are some issues with poor Windows or Android clients which aren't able to keep up with the latest & greatest security standards. I don't have any specific details what options cause trouble on Windows/Android, but this could be implemented incrementally when real-world issues are reported.

Deprecated iteritems() method not forward-compatible with Python 3

Formulas iterating over dictionaries should use the items() method instead of iteritems() because the latter method has been removed from Python 3. While the items() method in Python 2 uses more memory than iteritems(), these dictionaries are typically small (e.g., sets of settings from Pillar).

ServerKeyBits default in pillar.example is too low

According to the sshd_config manpage on my Ubuntu and Arch boxes, the minimum and default value for ServerKeyBits is 1024.

pillar.example sets it to

ServerKeyBits: 768

PILLAR_RAISE_ON_MISSING error for sshd_config:lookup

When I try to apply the oppenssh with PILLAR_RAISE_ON_MISSING in minion config set to true, sshd_config:lookup causes and error.
I have tried to define this key but if I do the "lookup" ends up in the config file and "lookup" is not recognised by sshd on Centos.
I assume the sshd_config: lookup should have not been merged in.
Am I missing something? Do you have a suggestion on how I should define sshd_config:lookup to get it working with Centos sshd?
Thanks for any suggestions.

Adding multiple keys for a user

I am not able to add multiple keys for the same user.
How should I do that? Right now my pillar file looks something like this:

openssh:
  auth:
    root:
      - name: AAAAB3NzaC1yc2EAAAADAQABAAABAQDSGAsHBf0oK5+NfnPyhTU/6/jwQ6Wp45PWzjCb5vLGM/wpmpemaMQFu58Y1mxrUBj8vQaoQ2MfN2lH7J3n/CXJ3WD9l4qwbX29lXmVxeK/wblablabla/5/sb18OiRo2pGzDifb67EOjQX7KoB26SdPqUB8mVDyhcucgu01hmHgO1rdq4pmK+uIj1gDUG4B3xpqQyLOW1nHoAUJTh+wMACg9wkGn+6yTb3Ut1SnVh20DJag203btgTx88KFLaRRUKkxObw37KsiUBV/kUmwN4aPSgvPt1NkkuDYlcMYOY6/FEw6n
        present: True
        enc: ssh-rsa
        comment: Bogdan
    www-data:
      - name: AAAAB3NzaC1yc2EAAAADAQblablablatduecy8ZD9D+tBde1S0OP7nu9F/IYDTl+mnMULzEN9mYKhGzsPCwVjGzjrlqrF4HSN/je52WNM8YxLepnjf9dKOVGtrCmYDT1S3ny0HBf0Uj7X46ntXF0B3wLVVg3tylIzbKNWFIaLuW1IpJCRl7w1FqeXQzA8deVLmHBG8okHT9HXbZvB93bf0Tvx9Axi8Jym/Krj7dLT8oeErVXr6uF+PrmtonfMsbctSrHOOflbeBu29R63wUFWFndO9Xej2SNAidunb/1dToRcTOBOaFiLh4/8S0/Mp0ZWzGFN
        present: True
        enc: ssh-rsa
        comment: Florin
    www-data:
      - name: AAAAB3NzaC1yc2EAblablablaPdEDEmCZkvsotubdcmgT/+p2KXNGjXBbvA0quoII93WCsrl1LqwBWfJOMXyWQFsF6tTi4ruLtGg9d/bSxfm/dBSg/4lePSYnEHhB+6RHL86qc/Q9f8jH5gm6rix9fCzUmTZPoYBlCpneHNIL877DrVS5LFPYWWZdupN+h98xgOtGaIhUSAWBpMSfjHcMu38TtitfYW1lxAl86fhmeDyZ0F4gy5/vOXp6BBSKsYwa3XV7G25ljMncfrEkPZlLXJyTbM9YlYiFcsHRJeOtw3J+b0B7NAssdaUIEXaRiFcYRs/duAi6h2Y6xf
        present: True
        enc: ssh-rsa
        comment: Georgian

The error that is produced is this:

    Rendering SLS 'openssh' failed, render error:
Conflicting ID 'www-data'

sshd_config: wrong comment

# The contents of the original sshd_config are kept on the bottom for
# quick reference.

Since #117 this is no longer the case.

Convert tests from Serverspec to Inspec (working on both Docker and Vagrant)

From #166 (comment):

• Convert tests from Serverspec to Inspec
• Test new InSpec tests in both Docker and Vagrant
• Consider updating/reducing the Vagrant testing matrix

---

With semantic-release in place, the existing Serverspec tests can be converted to InSpec and then used during the Travis run. The extra issue here is ensuring the tests can be run from Vagrant (i.e. using kitchen.vagrant.yml). The matrix there probably needs updating as well.

Test config before restarting service

To avoid rendering a server inaccessible, should include something like this (for both .config and .config_ini)

/usr/sbin/sshd -t:
  cmd.run:
    - onchanges:
      - file: sshd_config
    - require_in:
      - service: openssh

Wish: Add support for Win32-OpenSSH

Microsoft has officially ported OpenSSH to Windows. See here for download and installation instructions. Would be great to have it supported by this formula.

openssh.config_ini / HostKey clobbering

While testing the ini style config formula I've found that it clobbers the 4 default HostKey in the Ubuntu sshd_config down to the last one (without a HostKey specified in the pillar).

sshd_config Before

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

sshd_config After

HostKey /etc/ssh/ssh_host_ed25519_key

Following the pillar.example style of HostKey config Salt fails to compile the SLS on the minion. I think that's just because the current pillar.example isn't made with the config_ini formula in mind (it has a list/block of hostkeys which causes the compile issue).

All the other config variables which only appear once aren't affected and update just fine.

Pillar data

Hi there I was wanting to know if I could get some help with an issue I am having using this formula.

This issue is after installing the formula and adding the folder to my salt masters top file I am able to set the pillar data and can look up the values I have set inside the pillar however these are not being applied to the salt run.

The main example I can give is have set the port over into 10022 however when running a high state the openssh-server still ends up on port 22, I can look up the salt pillar values with the following commands.

salt 'salt-master' pillar.get ssh_config & salt 'salt-master' pillar.get sshd_config

Both of these commands show port 10022 as the port yet this will not take effect, how do I fix the formula so that I will run correctly?

Top file

base:
  '*':
    - vim
    - core
    - openssh

Pillar top file

base:
  '*':
    - openssh

Tree view from the base for the salt config.

├── core
│   └── init.sls
├── openssh
│   ├── auth.sls
│   ├── banner.sls
│   ├── client.sls
│   ├── config.sls
│   ├── defaults.yaml
│   ├── files
│   │   ├── banner
│   │   ├── fire_banner
│   │   ├── ssh_config
│   │   ├── sshd_config
│   │   └── ssh_known_hosts
│   ├── init.sls
│   ├── known_hosts.sls
│   ├── map.jinja
│   └── moduli.sls
├── pillars
│   ├── openssh
│   │   └── init.sls
│   └── top.sls
├── top.sls
└── vim
    └── init.sls

Indicate deprecated config

I propose indicating options in the example pillar that are deprecated with a concise format. I will create a pull request which will give an example.

Using inline comments after the option it applies to would appear as thus:

sshd_config:
    UsePrivilegeSeparation: 'sandbox' # D: >=7.5

This would indicate that the option is deprecated in sshd version 7.5 and higher.

Additional comments can be included at the beginning of the example pillar which could describe the format.

sshd_config:
  # Deprecated and Removed sshd options will be indicated by inline
  # comments. D: indicates an option that is deprecated. R: indicates
  # an option that is removed. These will be followed by the version
  # of sshd where this applies.
  UsePrivilegeSeparation: 'sandbox' # D: >=7.5
  Protocol: 2 # D: >=1.2 R: >7.5

Note that this hypothetical example would indicate that the UsePrivilegeSeparation option is deprecated in sshd versions 7.5 and higher and the Protocol option is deprecated in versions 1.2 and higher and removed in version 7.5. (I don't actually know when or if protocol was ever deprecated, this is an example only).

The examples above are based on the release notes for openssh 7.5. https://www.openssh.com/txt/release-7.5

Related #102 and #150

Implement `semantic-release` for this formula

I've pretty much completed this process but there are a few issues to resolve here, which I'm opening up for discussion in the meantime.

vagrant vs. docker

openssh-formula/.kitchen.yml

Lines 2 to 14 in 193ff7e

	driver:
	name: vagrant
	platforms:
	- name: centos-6.8
	- name: centos-7.2
	- name: ubuntu-14.04
	- name: ubuntu-16.04
	- name: debian-8.5
	- name: freebsd-10.3
	driver:
	cache_directory: false
	- name: freebsd-11.0

• Which of these need to be kept? I'd still have to work on integrating vagrant-based platforms, if those were required.

Serverspec vs. InSpec

The testing section under test/integration.

• Any issue with moving over to InSpec?

ConfigBanner option seems to add data at end that causes the sshd_config file not to parse

I played with some options here and ConfigBanner seems to cause an issue when I use it.

Pillar data:

sshd_config:
  ConfigBanner: |
    # This is a test of the
    # ConfigBanner pillar setting.

This results in the following:

Beginning of file (as expected):

# This is a test of the
# ConfigBanner pillar setting.

End of file (not expected and causes the parse issue):

ConfigBanner # This is a test of the
# ConfigBanner pillar setting.

This appears to be due to the code in the sshd_config Jinja file that attempts to write out all options not handled by the time it reaches the end of the file. I was able to fix this by adding ConfigBanner to the processed_options array. This could be done blindly at the beginning or when handling ConfgBanner if it exists. I tried the second approach and tested that. I did not bother making a pull request as it was not clear which would be preferred and if a comment would be desired (no comments elsewhere describing what processed_options is used for.

If it would help, I will make a pull request using either approach if I know which method is preferred and what comments might be desired.

Here is the one-line addition that worked for me:

diff --git a/openssh/files/sshd_config b/openssh/files/sshd_config
index 8038e4a..b9ea342 100644
--- a/openssh/files/sshd_config
+++ b/openssh/files/sshd_config
@@ -62,6 +62,7 @@
 {%- endmacro -%}
 
 {%- if sshd_config.get('ConfigBanner', False) -%}
+  {%- do processed_options.append('ConfigBanner') -%}
 {{ sshd_config['ConfigBanner'] }}
 {%- else -%}
 # This file is managed by salt. Manual changes risk being overwritten.

Both the initial issue and patch tests were done on a ubuntu/xenial VM from salt master on ubuntu/xenial.

Thanks,
Brian

Arch's dig package is bind-tools

Just as the title says. There isn't the appropriate override in map.jinja, so this formula tries to install the wrong package.

Name moduli in sls openssh is not a dictionary

Hi I am getting the following error on ubuntu 14.04

Name moduli in sls openssh is not a dictionary

I have updated so i am no longer getting the bug of the older salt-maser & minion version so thanks for that.
However I am unsure of how to fix the issue with the moduli section of the pillar.

SSH options not created using file-based public keys.

This is probably a complex solve.

In ssh_auth.{present|absent}, options should be included regardless of a file-based public key or a key in 'name'. However, in openssh/auth.sls, there seems to be a bug where if a static file is used, options are disabled. The behavior is not explicitly stated to be different from the ssh_auth documentation in the pillar.example. Sudo fix is here:

auth.sls.diff.txt

Patching this fixes specifying the ssh options with the key using file-based public key, however, forcing absent now fails seemingly because of a bad search/replace for key.

I suspect this is the same or a very similar issue to #140

Workaround:

Store the public key in the pillar data: openssh.auth.<key_label>.name. Example:

openssh:
  auth:
    key_label:
      - user: my_user
        present: True
        options:
          - no-X11-forwarding
          - no-port-forwarding
          - permitopen='localhost:80'
        name: <pubkey dump>

Error adding rsa keys on pillar

Having the following pillar:

openssh:
    provide_rsa_keys: True
    rsa:
        private_key: |
            -----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEA1pI/rHGQnGUxCeiockyJnH03JTWs23V1nymR7dtQeC/XiuAO
yk9o8CnBM40wuF26psrOES9JN0jxLAQO4YDn0Th3E1a0klylso6hBCmpLrOAmz34
bSLWR5vCsOSQhZuzcs78eHmDkocKcZ7Jre2//fa4Xq7y0bERGyBxAvS5lFjNQaHd
hiWnmSlMVLNtFGt3+EQexlv20yLiweJZ5VS0CoP77RlbMrfx/gYz6cS62PORKcZ6
VujU62jXbpUKxHlwryN8ifsEpWskxbpqiWk/CRA32fH02q8iEd61D/qzzJIrh9Zp
QKo3ms7T1+LFFPDqcgHFCX4tKtas7IugfPEABQIDAQABAoIBADKi7NfbLQ9bagk2
mJnwqgD+I8dqNVLNE2buPnvwe45rtgsdfgVhs7UJhYiO51J6/BNkhODVUef0FMYY
ZxKcgxiasdffa1Lr3/1/PECd3UrcYo4dsfadadzem0F3jwuYxO5xHm+n7X7k03gg
yuN62fYrBTODAdaufKT0MPdLnYf+RkMyiQsEBOJnk/m4n4KWx82M8pWZbbgY2Mvb
Y7X10MDPXZV31E4W+2RnrGJpYtjiU6WR4QyRWiZtcMpy7TlQYvULgDq2FXCD96J3
ncQk1nj5HVArf+6RlviCF4OBiklgJ4TSjzPOC24EOZTnelrdjFQAXr8b5zUYLDF3
EMPshEECgYEA6y1wDG1AJ9ps+hFN/FvMrKBGDydDfteIXmhpXU73w22PaIMS1BgV
uJS4dBhAcRulq1LqIWdqSfoHkmZ66gAh2iNb9GGm68ACyiOu4Xk5ZReuZjjR2p/a
pDa7676CviQ/+L+/7eV8UHMe4OUxwNTjjNp7UbsRPZwaM7EGb1zKFTkCgYEA6ZG/
iOcnxtBwZ9N96uQl/PZjB1YQ5iFu3rbTRVRcGbgQ+SotCFBO+V0SA9j4GeYA/ISR
4mEreIHSxB+DCvJlwKG4ajoqtrJ7E4y0br+y77qiK4VevDX4t0qVGOA7g3awiE70
rm5TjkzvnciY/qZZDoMFj42tnhHoctlo4idybS0CgYB+pO1eA8c0ru9YitEQQO8r
VvPjXSV/vNl23Ys/8DKETw+XHF6bUI0B5TSfcB/jyRuh8viaHHKke7xwHje6o2+X
ZMs0AxI8ih32dNjMGtfJlMMZ0SdRMBwxqjfwb5tAgYzhi4Dzv0z+lb/fJA1y5jHT
vCQEk1RpdRKasdfasdfasdfasdfWM/MrE4r4GxqrLVtSOs/X8QIarUSsOMcb+yFA
eMBKWfM+/v3znOsAZ+lom+fUoIoRC2da7HBYgP8RHDEqrejBQ88DpLqdeIvE/wpO
cwIgNtIZBaQ/CWRCfGTGPoZ15zi4asdfasdfasdfasdff6w20dQctfsedx/tjBNT
LIgVNQKBgHZQFIBhkdczV7UrCtfV0xsOZfoRDRzv3y38IE3Ctm3TMdWhBSlCXVHU
+K5uIJht9UITfB5K+Icl71qwerqwerqwerqoRRsojMepmBkZq1w5w9+Py0qrd5zv
VNAArdvCbcFjI//7mESRjcEck55D2zNTbiTpHntzfy98zqmBfx/N
            -----END RSA PRIVATE KEY-----
        public_key: |
            ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDWkj+scZCcZTEJ6KhyTImcfTclNazbdXWfKZHt21B4L9eK4A7KT2jwKcEzjTC4Xasdfasdfasdfasdfasdfasdfasdfasdfasdfakus4CbPfhtItZHm8Kw5JCFm7Nyzvx4eYOShwpxnsmt7b/99rhervLRsREbIHEC9LmUWM1Bod2GJaeZKUxUs20Ua3f4RB7GW/bTIuLB4lnlVLQKg/vtGVsyt/H+BjPpxLrY85EpxnpW6NTraNdulQrEeXCvI3yJ+wSlbiTFumqJaT8JEDfZ8fT234234234234P+rPMkiuH1mlAqjeaztPX4sUU8OpyAcUJfi0q1qzsi6B88QAF root@test

It shows an error when it renders the sls:

2017-07-13 21:01:42,122 [salt.pillar      ][CRITICAL][32055] Rendering SLS 'openssh' failed, render error:
could not found expected ':'; line 33

---
[...]
    provide_rsa_keys: True
    rsa:
        private_key: |
            -----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEA1pI/rHGQnGUxCeiockyJnH03JTWs23V1nymR7dtQeC/XiuAO
yk9o8CnBM40wuF26psrOES9JN0jxLAQO4YDn0Th3E1a0klylso6hBCmpLrOAmz34    <======================
bSLWR5vCsOSQhZuzcs78eHmDkocKcZ7Jre2//fa4Xq7y0bERGyBxAvS5lFjNQaHd
hiWnmSlMVLNtFGt3+EQexlv20yLiweJZ5VS0CoP77Rlbasdfasdf232wf23345ff
VujU62jXbpUKxHlwryN8ifsEpW4kxbpqiWk/C2345df45tsrgd61D/qzzJIrh9Zp
QKo3ms7T1+LFFPDqcgHFCX4tKtas7IugfPEABQIDAQABAoIBADKi7NfbLQ9bagk2
mJnwqgD+I8dqNVLNE2buPnvtZ74VPD6Pxa3Es7UJhYiO51J6/BNkhODVUef0FMYY
[...]

Which is the proper way to add the specific rsa keys for a server in the pillar?

sshd_config ends up almost empty when trying to modify one value

When adding the following pillar and using openssh.config :

sshd_config:
  PermitRootLogin: no

I end up with the following file

# This file is managed by salt. Manual changes risk being overwritten.
# The contents of the original sshd_config are kept on the bottom for
# quick reference.
# See the sshd_config(5) manpage for details

PermitRootLogin no

I'm not sure this is a good result, are the default values shipped by the distro always the default values upstream ? I don't think so.

Any chance of getting this config to be handled in a way that keeps the default values shipped by the distro. Maybe with https://docs.saltstack.com/en/latest/ref/states/all/salt.states.ini_manage.html ?

kali linux is not a supported distribution

This formula is not support on Kali Linux because the os_family grain is 'Kali' and not 'Debian'. Adding a mapping in map.jinja, which I've included below, will resolve the issue. I will fork and submit a pull request, but figured given how simple the fix is it would be quick for one of the maintainers to make it.

--- a/openssh/map.jinja
+++ b/openssh/map.jinja
@@ -17,6 +17,11 @@ that differ from whats in defaults.yaml
       'client': 'openssh-client',
       'service': 'ssh',
     },
+    'Kali': {
+      'server': 'openssh-server',
+      'client': 'openssh-client',
+      'service': 'ssh',
+    },
     'FreeBSD': {
       'service': 'sshd',
       'dig_pkg': 'bind-tools',

Error when attempting to apply the state.

[salt.state       ][CRITICAL][52394] Rendering SLS 'base:openssh' failed: Jinja error: 'NoneType' object is not iterable
/var/cache/salt/minion/files/base/openssh/map.jinja(53):
---
[...]
  , grain="os_family"
  , merge=salt['pillar.get']('openssh:lookup'))
%}

{## Merge the flavor_map to the default settings ##}
{% do default_settings.openssh.update(os_family_map) %}    <======================

{## Merge in openssh:lookup pillar ##}
{% set openssh = salt['pillar.get'](
    'openssh',
    default=default_settings.openssh,
[...]
---
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/salt/utils/templates.py", line 368, in render_jinja_tmpl
    output = template.render(**decoded_context)
  File "/usr/lib/python2.7/dist-packages/jinja2/environment.py", line 1008, in render
    return self.environment.handle_exception(exc_info, True)
  File "/usr/lib/python2.7/dist-packages/jinja2/environment.py", line 780, in handle_exception
    reraise(exc_type, exc_value, tb)
  File "<template>", line 1, in top-level template code
  File "/usr/lib/python2.7/dist-packages/jinja2/environment.py", line 1073, in make_module
    return TemplateModule(self, self.new_context(vars, shared, locals))
  File "/usr/lib/python2.7/dist-packages/jinja2/environment.py", line 1152, in __init__
    body_stream = list(template.root_render_func(context))
  File "/var/cache/salt/minion/files/base/openssh/map.jinja", line 53, in top-level template code
    {% do default_settings.openssh.update(os_family_map) %}
TypeError: 'NoneType' object is not iterable

Needs workaround for RedHat-family 6.x with SELinux enabled ("check_cmd execution failed ... Permission denied") (fix included)

In RHEL/CentOS 6.10 with SELinux set to enforcing, the following access violation will occur when testing the new sshd_config with check_cmd (openssh/config.sls, line 17):

type=AVC msg=audit(1548598945.937:183): avc:  denied  { open } for  pid=13492 comm="sshd" name="__salt.tmp.BYA0jz" dev=dm-0 ino=410972 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=file

Which, according to audit2allow -w, is because:

(...)
	Was caused by:
		Missing type enforcement (TE) allow rule.

		You can use audit2allow to generate a loadable module to allow this access.

This issue was reported in the (as yet unresolved) #98.

There are two ways around this.

The hacky way:

diff --git a/openssh/config.sls b/openssh/config.sls
index 9fbe895..7ada708 100644
--- a/openssh/config.sls
+++ b/openssh/config.sls
@@ -14,7 +14,9 @@ sshd_config:
     - user: {{ openssh.sshd_config_user }}
     - group: {{ openssh.sshd_config_group }}
     - mode: {{ openssh.sshd_config_mode }}
+    {%- if not ((grains['os_family'] == 'RedHat') and (grains['osmajorrelease'] == 6) and (salt['grains.get']('selinux:enforced', False) == 'Enforcing')) %}
     - check_cmd: {{ openssh.sshd_binary }} -t -f
+    {%- endif %}
     {%- if openssh.sshd_config_backup  %}
     - backup: minion
     {%- endif %}

or the proper way - by using selinux.module_install, you can install an SELinux policy that will allow the tmp file to be read by check_cmd.

I have taken the liberty of generating this policy. In the interest of transparency for those that wish to use it, here's how (all commands assume root):

1. yum -y install policycoreutils-python (if you currently don't have the audit2allow program installed)
2. grep 'name="__salt.tmp.' /var/log/audit/audit.log > /tmp/avc_err
3. cat /tmp/avc_err | audit2allow -m salt.openssh_formula.fix_centos6_selinux > salt.openssh_formula.fix_centos6_selinux.te
4. checkmodule -M -m -o salt.openssh_formula.fix_centos6_selinux.mod salt.openssh_formula.fix_centos6_selinux.te
5. semodule_package -o salt.openssh_formula.fix_centos6_selinux.pp -m salt.openssh_formula.fix_centos6_selinux.mod
6. Then, of course, one would NORMALLY install via semodule -i salt.openssh_formula.fix_centos6_selinux.pp but in this case, SaltStack should install this.

Here are those files that are generated:

salt.openssh_formula.fix_centos6_selinux.te:

module salt.openssh_formula.fix_centos6_selinux 1.0;

require {
	type initrc_tmp_t;
	type sshd_t;
	class file open;
}

#============= sshd_t ==============
# Created by GitHub user johnnybubonic
# Fix for: https://github.com/saltstack-formulas/openssh-formula/issues/147
allow sshd_t initrc_tmp_t:file open;

salt.openssh_formula.fix_centos6_selinux.mod (binary file; in Base64)[0]:

jf98+Q8AAABTRSBMaW51eCBNb2R1bGUCAAAACgAAAAEAAAAIAAAAAAAAACgAAABzYWx0Lm9wZW5z
c2hfZm9ybXVsYS5maXhfY2VudG9zNl9zZWxpbnV4AwAAADEuMEAAAAAAAAAAAAAAAAAAAAAAAAAA
AQAAAAEAAAAEAAAAAAAAAAEAAAABAAAAAQAAAAAAAABmaWxlBAAAAAEAAABvcGVuAQAAAAEAAAAI
AAAAAQAAAAAAAABvYmplY3RfckAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAA
AAACAAAAAgAAAAwAAAABAAAAAQAAAAEAAAAAAAAAQAAAAAAAAAAAAAAAaW5pdHJjX3RtcF90BgAA
AAIAAAABAAAAAQAAAAAAAABAAAAAAAAAAAAAAABzc2hkX3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAEAAAABAAAAAQAAAAAAAAAAAAAAAQAAAAEAAAAAAAAAQAAAAEAAAAABAAAAAAAA
AAIAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAEAAAABAAAAAAQAAAAAAAAABAAAAAAAAAEAAAAAAAAAA
AAAAAAAAAAABAAAAAQAAAAEAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAABAAAAAQAAAAAEAAAAA
AAAAAQAAAAAAAABAAAAAAAAAAAAAAABAAAAAQAAAAAEAAAAAAAAAAwAAAAAAAABAAAAAAAAAAAAA
AABAAAAAAAAAAAAAAABAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAABAAAAQAAAAEAAAAABAAAAAAAA
AAEAAAAAAAAAQAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAA
QAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAQAAAAQAAABmaWxlAQAAAAEAAAABAAAAAQAAAAgAAABvYmplY3RfcgIAAAABAAAAAQAA
AAIAAAAMAAAAaW5pdHJjX3RtcF90AQAAAAEAAAABAAAABgAAAHNzaGRfdAEAAAABAAAAAQAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAA

salt.openssh_formula.fix_centos6_selinux.pp (binary file; in Base64)[0]:

j/98+QEAAAABAAAAEAAAAI3/fPkPAAAAU0UgTGludXggTW9kdWxlAgAAAAoAAAABAAAACAAAAAAA
AAAoAAAAc2FsdC5vcGVuc3NoX2Zvcm11bGEuZml4X2NlbnRvczZfc2VsaW51eAMAAAAxLjBAAAAA
AAAAAAAAAAAAAAAAAAAAAAEAAAABAAAABAAAAAAAAAABAAAAAQAAAAEAAAAAAAAAZmlsZQQAAAAB
AAAAb3BlbgEAAAABAAAACAAAAAEAAAAAAAAAb2JqZWN0X3JAAAAAAAAAAAAAAABAAAAAAAAAAAAA
AABAAAAAAAAAAAAAAAAAAAAAAgAAAAIAAAAMAAAAAQAAAAEAAAABAAAAAAAAAEAAAAAAAAAAAAAA
AGluaXRyY190bXBfdAYAAAACAAAAAQAAAAEAAAAAAAAAQAAAAAAAAAAAAAAAc3NoZF90AAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAQAAAAEAAAAAAAAAAAAAAAEAAAABAAAAAAAA
AEAAAABAAAAAAQAAAAAAAAACAAAAAAAAAEAAAAAAAAAAAAAAAAAAAABAAAAAQAAAAAEAAAAAAAAA
AQAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAQAAAAEAAAABAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAA
AAAAQAAAAEAAAAABAAAAAAAAAAEAAAAAAAAAQAAAAAAAAAAAAAAAQAAAAEAAAAABAAAAAAAAAAMA
AAAAAAAAQAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAQAA
AEAAAABAAAAAAQAAAAAAAAABAAAAAAAAAEAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAEAAAAAAAAAA
AAAAAEAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAEAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAEAAAAZmlsZQEAAAABAAAAAQAAAAEAAAAIAAAAb2Jq
ZWN0X3ICAAAAAQAAAAEAAAACAAAADAAAAGluaXRyY190bXBfdAEAAAABAAAAAQAAAAYAAABzc2hk
X3QBAAAAAQAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==

[0] To decode base64 back into a binary file, copy the entire base64 string to a file (e.g. selinuxpolicy.b64) and then do base64 -d selinuxpolicy.b64 > newfilename. newfilename is the reassembled file. You can pipe it as well: echo '<base64_string>' | base64 -d > newfilename - but if you do it this way, you must remove the linebreaks.

You SHOULD only need the salt.openssh_formula.fix_centos6_selinux.pp file. Use a file.manage to get that in place if:

• os_family == RedHat AND
• osmajorrelease == 6 AND
• selinux:enforced == Enforcing

and then apply it with selinux.module_install.

I have tested the policy and it does indeed work.

I have confirmed the following works on a fresh install of CentOS 6.10:

{%- if ((grains['os_family'] == 'RedHat')
      and (grains['osmajorrelease'] == 6)
      and (salt['grains.get']('selinux:enforced', False) == 'Enforcing')) %}
Install_selinux_helpers:
  pkg.installed:
    - name: policycoreutils
    - name: policycoreutils-python

Copy_module:
  file.managed:
    - source: salt://roles/common/files/ssh/salt.openssh_formula.fix_centos6_selinux.pp
      source_hash: d2f5ce648d7953e284a3e0a6d74bb9c9dc41636683b0b5e790761a04fcdd050168509b65f197f393ca4dcd4570ab97f755705c63c50ee1396e67a3a1fa01f21c
      name: /var/tmp/salt.openssh_formula.fix_centos6_selinux.pp
      user: root
      group: root
      mode: 0400

Install_module:
  selinux.module_install:
    - name: /var/tmp/salt.openssh_formula.fix_centos6_selinux.pp

Enabling_module:
  selinux.module:
    - name: salt.openssh_formula.fix_centos6_selinux
      module_state: 'Enabled'
{%- endif %}

[BUG] When running with salt-ssh, getting error that 'opts' is not defined.

Your setup

Formula commit hash / release tag

git master branch, commit hash d48bdde

Versions reports (master & minion)

Salt Version:
Salt: 3002.2

Dependency Versions:
cffi: 1.14.6
cherrypy: Not Installed
dateutil: 2.8.1
docker-py: 5.0.0
gitdb: 4.0.7
gitpython: 3.1.18
Jinja2: 3.0.1
libgit2: Not Installed
M2Crypto: Not Installed
Mako: 1.1.4
msgpack: 1.0.2
msgpack-pure: Not Installed
mysql-python: Not Installed
pycparser: 2.20
pycrypto: Not Installed
pycryptodome: 3.10.1
pygit2: Not Installed
Python: 3.9.6 (default, Jun 30 2021, 10:22:16)
python-gnupg: Not Installed
PyYAML: 5.4.1
PyZMQ: 22.1.0
smmap: 4.0.0
timelib: Not Installed
Tornado: 4.5.3
ZMQ: 4.3.4

System Versions:
dist: manjaro 21.1.0 Pahvo
locale: utf-8
machine: x86_64
release: 5.4.135-1-MANJARO
system: Linux
version: Manjaro Linux 21.1.0 Pahvo

Pillar / config used

---

Bug details

Describe the bug

Trying to run a state.highstate via salt-ssh, and among others, using this formula.
I get an exception:
...
[DEBUG ] In saltenv 'base', looking at rel_path 'openssh/libsaltcli.jinja' to resolve 'salt://openssh/libsaltcli.jinja'
[DEBUG ] In saltenv 'base', ** considering ** path '/var/tmp/.root_9669d5_salt/running_data/var/cache/salt/minion/files/base/openssh/libsaltcli.jinja' to resolve 'salt://openssh/libsaltcli.jinja'
[ERROR ] Rendering exception occurred
Traceback (most recent call last):
File "/usr/lib/python3.9/site-packages/salt/utils/templates.py", line 495, in render_jinja_tmpl
output = template.render(**decoded_context)
File "/usr/lib/python3.9/site-packages/jinja2/environment.py", line 1304, in render
self.environment.handle_exception()
File "/usr/lib/python3.9/site-packages/jinja2/environment.py", line 925, in handle_exception
raise rewrite_traceback_stack(source=source)
File "", line 1, in top-level template code
File "/usr/lib/python3.9/site-packages/jinja2/environment.py", line 1412, in make_module
return TemplateModule(self, ctx)
File "/usr/lib/python3.9/site-packages/jinja2/environment.py", line 1542, in init
body_stream = list(template.root_render_func(context)) # type: ignore
File "/var/tmp/.root_9669d5_salt/running_data/var/cache/salt/minion/files/base/openssh/map.jinja", line 6, in top-level template code
{%- from tplroot ~ "/libmapstack.jinja" import mapstack %}
File "/usr/lib/python3.9/site-packages/jinja2/environment.py", line 1412, in make_module
return TemplateModule(self, ctx)
File "/usr/lib/python3.9/site-packages/jinja2/environment.py", line 1542, in init
body_stream = list(template.root_render_func(context)) # type: ignore
File "/var/tmp/.root_9669d5_salt/running_data/var/cache/salt/minion/files/base/openssh/libmapstack.jinja", line 6, in top-level template code
{%- from tplroot ~ "/libmatchers.jinja" import parse_matchers, query_map %}
File "/usr/lib/python3.9/site-packages/jinja2/environment.py", line 1412, in make_module
return TemplateModule(self, ctx)
File "/usr/lib/python3.9/site-packages/jinja2/environment.py", line 1542, in init
body_stream = list(template.root_render_func(context)) # type: ignore
File "/var/tmp/.root_9669d5_salt/running_data/var/cache/salt/minion/files/base/openssh/libmatchers.jinja", line 6, in top-level template code
{%- from tplroot ~ "/libsaltcli.jinja" import cli %}
File "/usr/lib/python3.9/site-packages/jinja2/environment.py", line 1412, in make_module
return TemplateModule(self, ctx)
File "/usr/lib/python3.9/site-packages/jinja2/environment.py", line 1542, in init
body_stream = list(template.root_render_func(context)) # type: ignore
File "/var/tmp/.root_9669d5_salt/running_data/var/cache/salt/minion/files/base/openssh/libsaltcli.jinja", line 5, in top-level template code
{%- set opts_cli = opts.get('__cli', '') %}
File "/usr/lib/python3.9/site-packages/jinja2/environment.py", line 474, in getattr
return getattr(obj, attribute)
jinja2.exceptions.UndefinedError: 'opts' is undefined

Steps to reproduce the bug

I guess just try using this formula and run it with salt-ssh.

Expected behaviour

To work correctly when running via salt-ssh as well.
Note: months ago, when running it via salt-master/minion, it worked ok. But I want to run it now agentless.

Attempts to fix the bug

None.

Additional context

none

Indenting does not render properly

The rendering for ssh_config needs a bit of an overhaul since it renders with some options as unindented under Host sections and it doesn't even render the MACs, KeyAlgorithms, or Ciphers options as correctly (they cannot be specified cumulatively on multiple lines, they must be joined with commas to a single string).

Additionally, ConfigBanner was getting added as an actual config directive rather than used internally.

I'd recommend fiddling with the spacing as well, as there's a lot of empty lines at the end of the file.

Here's a patch:

--- a/openssh/files/ssh_config	2019-01-22 02:24:32.858871892 -0500
+++ b/openssh/files/ssh_config	2019-01-22 18:39:32.701567269 -0500
@@ -1,7 +1,7 @@
 {%- import_yaml "openssh/defaults.yaml" as default_settings -%}
 {%- set ssh_config = salt['pillar.get']('ssh_config', default=default_settings.ssh_config, merge=True) -%}
 {#- present in ssh_config and known in actual file options -#}
-{%- set processed_options = [] -%}
+{%- set processed_options = ['ConfigBanner'] -%}
 {%- set string_or_list_options = ['KexAlgorithms', 'Ciphers', 'MACs'] -%}
 
 {%- macro render_raw_option(keyword, value) -%}
@@ -18,6 +18,24 @@
   {%- endif -%}
 {%- endmacro -%}
 
+{%- macro render_host_option(keyword, value) -%}
+{%- if value is sameas true %}
+    {{ keyword }} yes
+  {%- elif value is sameas false %}
+    {{ keyword }} no
+  {%- elif value is string or value is number %}
+    {{ keyword }} {{ value }}
+  {%- else -%}
+    {%- if keyword in string_or_list_options %}
+    {{ keyword }} {{ value|join(',') }}
+    {%- else %}
+    {%- for single_value in value -%}
+    {{ keyword }} {{ single_value }}
+    {%- endfor -%}
+    {%- endif -%}
+{%- endif -%}
+{%- endmacro -%}
+
 {#- generic renderer used for ssh matches, known options, -#}
 {#- and unknown options -#}
 {%- macro render_option(keyword, default, config_dict=ssh_config) -%}
@@ -85,14 +103,14 @@
 {%- do processed_options.append('Hosts') %}
 {%  for host, conf in ssh_config['Hosts'].items() %}
 Host {{ host }}
-  {%- for key, val in conf.items() %}
-    {{ render_raw_option(key, val) }}
+  {%- for key, val in conf.items() -%}
+    {{ render_host_option(key, val) }}
   {%- endfor %}
 {%- endfor %}
 {%- endif %}
 
 {# Handling unknown in salt template options #}
-{%- for keyword in ssh_config.keys() %}
+{% for keyword in ssh_config.keys() -%}
   {#- Matches have to be at the bottom and should be handled differently -#}
   {%- if not keyword in processed_options and keyword != 'matches' -%}
     {%- if not keyword in string_or_list_options -%}
@@ -103,17 +121,16 @@
 {{ option_string_or_list(keyword, '', True) }}
     {%- endif -%}
   {%- endif -%}
-{%- endfor %}
+{%- endfor -%}
 
 {# Handle matches last as they need to go at the bottom #}
-{%- if 'matches' in ssh_config %}
+{% if 'matches' in ssh_config -%}
   {%- for match in ssh_config['matches'].values() %}
 Match {{ match['type'].keys()[0] }} {{ match['type'].values()[0] }}
     {%- for keyword in match['options'].keys() %}
     {{ render_option(keyword, '', config_dict=match['options']) }}
     {%- endfor %}
   {%- endfor %}
-{%- endif %}
+{%- endif -%}
 
 {#- vim: set ft=jinja : #}
-

Can changed config files default to Backup?

The "backup: minion" setting is not present in the config.sls file. So someone trying to get this working may inadvertently change an SFTP server or a server with custom settings all to defaults and will not have an easy way to restore. Salt allows easy backups and restoration without having to go to tape or other method - any change to an existing file seems like it should Default to "backup"

Wishlist: functionnality to generate users SSH key

Hello,

This formula is already able to manage (push) SSH pubkeys for users. I wonder if adding users SSH key generation could be interesting?

My use case is the following: a specific pool of some servers where we want to generate SSH key for a user and then propagate each key to others servers in the pool.

openssh.config fails with "No such file or directory"

Just upgraded both the master and the minion to v2017.7.0. Now, when there is a mismatch of the config file, applying the config fails:

----------
          ID: sshd_config
    Function: file.managed
        Name: /etc/ssh/sshd_config
      Result: False
     Comment: Failed to commit change: [Errno 2] No such file or directory: /tmp/__salt.tmp._skAAZ
     Started: 23:55:26.828903
    Duration: 103.767 ms
     Changes:
              ----------
              diff:
                  Replace text file with binary file

It works fine when the config file matches the template, but if there are any changes, 💥.

Sort example pillar options

I propose sorting the options given in the example pillar.

The reason is it could make it easier to set up a new pillar if comparing an example/existing sshd_config. The current sshd_config can be shown with "sshd -T" in the terminal. The lines returned by sshd can be sorted in an editor for comparison.

Implementing this with #156 could create merge conflicts but could be implemented later.

UsePrivilegeSeparation 'sandbox' breaks on older versions

The push last night has broken older versions of openssh e.g. openssh on centos6. Ideally UsePrivilegeSeparation 'sandbox' would be conditional based on the version of openssh installed or would be set to a value that works for older, but still vendor supported, versions.

CentOS 6: check_cmd broken/unsupported key type ed25519

While testing #97 I've noticed the check_cmd fails on CentOS 6:

[root@centos6minion ~]# tail -n 5 /var/log/salt/minion                                                                                                                                         
2017-06-22 02:30:33,752 [salt.state       ][INFO    ][4647] File /etc/ssh/ssh_config is in the correct state
2017-06-22 02:30:33,753 [salt.state       ][INFO    ][4647] Completed state [/etc/ssh/ssh_config] at time 02:30:33.752483
2017-06-22 02:40:47,330 [salt.loaded.int.module.cmdmod              ][ERROR   ][5092] Command '/usr/sbin/sshd -t -f /tmp/tmptj9aZz' failed with return code: 1
2017-06-22 02:40:47,331 [salt.loaded.int.module.cmdmod              ][ERROR   ][5092] output: /tmp/tmptj9aZz: Permission denied
2017-06-22 02:40:47,332 [salt.state                                 ][ERROR   ][5092] check_cmd execution failed
[root@centos6minion ~]# ls -l /tmp/tmpP4oYT8
-rw-r--r--. 1 root root 4479 Jun 22 02:49 /tmp/tmpP4oYT8

The "Permission denied" error is pretty strange, could even be a bug in CentOS 6's python (see versions-report below). But I have another concern: When I run the check manually there's the problem with missing hostkeys

[root@centos6minion ~]# sshd -t -f /tmp/tmpP4oYT8
Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Could not load host key: /etc/ssh/ssh_host_ed25519_key

While one can manually generate an ECDSA hostkey, ED25519 keys are not supported on CentOS 6:

[root@centos6minion ~]# ssh-keygen -t ed25519
unknown key type ed25519

Removing 'ed25519' from openssh/config.sls doesn't help as the check_cmd still fails with this "Permission denied" error. Though the SSH-server actually starts when a host key listed in its config is missing (tested by removing the check_cmd line from openssh/config.sls).

PS: Versions-report and pillar data:

[root@centos6minion ~]# salt-call --versions-report                                            
           Salt: 2015.5.10                                                                     
         Python: 2.6.6 (r266:84292, Aug 18 2016, 15:13:37)                                     
         Jinja2: 2.2.1                         
       M2Crypto: 0.20.2
 msgpack-python: 0.4.6
   msgpack-pure: Not Installed
       pycrypto: 2.0.1
        libnacl: Not Installed
         PyYAML: 3.10
          ioflo: Not Installed
          PyZMQ: 14.3.1
           RAET: Not Installed
            ZMQ: 3.2.5
           Mako: Not Installed
        Tornado: Not Installed
        timelib: Not Installed
       dateutil: Not Installed
[root@centos6minion ~]# salt-call pillar.items
local:
    ----------
    __formulas:
        ----------
        print_template_url:
            True
    openssh-formula:
        ----------
        print_template_url:
            None
    salt:
        ----------
        minion:
            ----------
            master:
                192.168.178.64
    ssh_config:
        ----------
        SendEnv:
            LANG LC_* EDITOR EMAIL GIT_AUTHOR_EMAIL GIT_AUTHOR_NAME VISUAL
    sshd_config:
        ----------
        AcceptEnv:
            LANG LC_* EDITOR EMAIL GIT_AUTHOR_EMAIL GIT_AUTHOR_NAME VISUAL
        PrintMotd:
            yes

Remove blank lines in rendered ssh_config and sshd_config

The conf files you generate are either broken or render to eyesores such as this:

# The contents of the original sshd_config are kept on the bottom for
# quick reference.
# See the sshd_config(5) manpage for details

Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
UsePrivilegeSeparation sandbox
SyslogFacility AUTHPRIV
LogLevel INFO
ClientAliveInterval 1
ClientAliveCountMax 300
LoginGraceTime 120
PermitRootLogin prohibit-password
StrictModes yes
MaxAuthTries 6
MaxSessions 5
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys
ChallengeResponseAuthentication no
AuthenticationMethods publickey
PasswordAuthentication no
Banner /etc/ssh/banner
AcceptEnv XMODIFIERS
Subsystem sftp /usr/lib/ssh/sftp-server
UsePAM yes

AllowUsers root


AllowGroups root

KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256
Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr
MACs [email protected],[email protected],[email protected],hmac-sha2-512,hmac-sha2-256,[email protected]

Match Group sftpusers #sftp_chroot
    AllowTcpForwarding no

    ChrootDirectory /sftp-chroot/%u

    ForceCommand internal-sftp

    X11Forwarding no

Yes, including trailing whitespace.

I'd remove the blank lines between UsePAM/AllowUsers/AllowGroups, and remove the blank lines between all items in the Match section as well as the trailing blank lines. These blank lines make the config harder to visually parse, as they are separating logical sections that should be together.

openssh.known_hosts state is broken in 2015.5.0

the mine_function needed for this state to work uses cmd.run but in 2015.5.0 there has been a change
the pillar example needs to be updated to reflect this change:

for 2015.5.0 this should be:

# 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_hostname:
    mine_function: grains.get
    key: id

Formula has no ability to disable SSH service

Formula has no ability to disable SSH service

First-run of state fails on arch due to missing keys

On Arch, the hostkeys are generated the first time the service is started. However, sshd_config fails because the keys don't exist yet, so the service can't be started.

----------
          ID: sshd_config
    Function: file.managed
        Name: /etc/ssh/sshd_config
      Result: False
     Comment: check_cmd execution failed
              Could not load host key: /etc/ssh/ssh_host_rsa_key
              Could not load host key: /etc/ssh/ssh_host_dsa_key
              Could not load host key: /etc/ssh/ssh_host_ecdsa_key
              Could not load host key: /etc/ssh/ssh_host_ed25519_key
              sshd: no hostkeys available -- exiting.
     Started: 17:56:05.599505
    Duration: 352.189 ms
     Changes:   
----------
          ID: openssh
    Function: service.running
        Name: sshd
      Result: False
     Comment: One or more requisite failed: openssh.config.sshd_config
     Started: 17:56:05.962233
    Duration: 0.015 ms
     Changes:   

A workaround is to start the service manually, then apply the highstate.

config_ini duplicating lines due to tab instead of space (e.g. Subsystem)

After the latest update 3e01ad8 the config_ini state added an extra Subsystem sftp /usr/lib/openssh/sftp-server to all my hosts, resulting in invalid config and sshd failing to start.

I had to manually remove the earlier line (that had the comment # override default of no subsystems) to fix it.

Feature request: make values in map.jinja onverridable

It would be great if one could override values in map.jinja from Pillars.
My use case is that we're using FreeBSD openssh-portable package (because we link it against LibreSSL and it has HPN patches), and it would be great if i could override the service and package in pillars.

Thanks

Uncomment config for openssh.banner?

I may be missing something, but it seems that the banner setting in sshd_config on Ubuntu is not being uncommented and set correctly when the openssh.banner state is run. The banner_src gets copied to /etc/ssh/banner correctly, but I don't see an option to enable/uncomment the banner config line or set the banner_src in the pillar.example file that's provided.

I'm trying with a simple highstate here (UseDNS: 'no' works):

# /srv/salt/top.sls
base:
  '*':
    - openssh
    - openssh.config
    - openssh.banner

# /srv/pillar/openssh.sls
sshd_config:
  UseDNS: 'no'

Running openssh.banner placed a banner file at /etc/ssh/banner, so I manually changed:

# /etc/ssh/sshd_config
...

#Banner /etc/issue.net

to

# /etc/ssh/sshd_config
...

Banner /etc/ssh/banner

and everything worked. Is there another option that needs to be set? I thought I would be able to override that setting somehow in pillar, but I can't figure it out.

Here's the output of state.highstate:

local:
----------
          ID: openssh
    Function: pkg.installed
        Name: openssh-server
      Result: True
     Comment: Package openssh-server is already installed
     Changes:
----------
          ID: sshd_config
    Function: file.managed
        Name: /etc/ssh/sshd_config
      Result: True
     Comment: File /etc/ssh/sshd_config is in the correct state
     Changes:
----------
          ID: openssh
    Function: service.running
        Name: ssh
      Result: True
     Comment: Service ssh is already enabled, and is in the desired state
     Changes:
----------
          ID: sshd_banner
    Function: file.managed
        Name: /etc/ssh/banner
      Result: True
     Comment: File /etc/ssh/banner is in the correct state
     Changes:

Summary
------------
Succeeded: 4
Failed:    0
------------
Total:     4

Thanks, I appreciate you guys posting this formula.

Deprecated option UsePrivilegeSeparation

Hi,
https://www.openssh.com/releasenotes.html
OpenSSH 7.5/7.5p1 (2017-03-20)
This release includes a number of changes that may affect existing
configurations:

• This release deprecates the sshd_config UsePrivilegeSeparation
  option, thereby making privilege separation mandatory. Privilege
  separation has been on by default for almost 15 years and
  sandboxing has been on by default for almost the last five.

UsePrivilegeSeparation must be remove,
Impact: impossible to start sshd