Adoptable Cookbooks List

Supermarket Belongs to the Community

Supermarket belongs to the community. While Chef has the responsibility to keep it running and be stewards of its functionality, what it does and how it works is driven by the community. The chef/supermarket repository will continue to be where development of the Supermarket application takes place. Come be part of shaping the direction of Supermarket by opening issues and pull requests or by joining us on the Chef Mailing List.

ssh-hardening (Chef cookbook)

Description

This cookbook provides secure ssh-client and ssh-server configurations. This cookbook does not provide capabilities for management of users and/or ssh keys, please use other cookbooks for that.

Requirements

Chef >= 12.5.1

Platform

Debian 7, 8

Ubuntu 12.04, 14.04, 16.04

RHEL 6, 7

CentOS 6, 7

Oracle Linux 6, 7

Fedora 24, 25

OpenSuse Leap 42.1

OpenSuse 13.2

Attributes

Below you can find the attribute documentation and their default values.

Notice: Some of attribute defaults of this cookbook are set in the recipes. You should use a higher attribute precedence level for overriding of such attributes. Such attributes are flagged with #override attribute# in the list below. Example for overriding a such attribute:

['ssh-hardening']['ssh'][{'client', 'server'}]['cipher'] - nil to calculate best ciphers based on server version, otherwise specify a string of Cipher values

['ssh-hardening']['ssh'][{'client', 'server'}]['cbc_required'] - false. Set to true if CBC for ciphers is required. This is usually only necessary, if older M2M mechanism need to communicate with SSH, that don't have any of the configured secure ciphers enabled. CBC is a weak alternative. Anything weaker should be avoided and is thus not available.

['ssh-hardening']['ssh'][{'client', 'server'}]['weak_hmac'] - false. Set to true if weaker HMAC mechanisms are required. This is usually only necessary, if older M2M mechanism need to communicate with SSH, that don't have any of the configured secure HMACs enabled.

['ssh-hardening']['ssh'][{'client', 'server'}]['weak_kex'] - false. Set to true if weaker Key-Exchange (KEX) mechanisms are required. This is usually only necessary, if older M2M mechanism need to communicate with SSH, that don't have any of the configured secure KEXs enabled.

['ssh-hardening']['ssh']['client']['remote_hosts'] - [] - one or more hosts, to which ssh-client can connect to.

['ssh-hardening']['ssh']['client']['password_authentication'] - false. Set to true if password authentication should be enabled.

['ssh-hardening']['ssh']['client']['roaming'] - false. Set to true if experimental client roaming should be enabled. This is known to cause potential issues with secrets being disclosed to malicious servers and defaults to being disabled.

['ssh-hardening']['ssh']['server']['dh_min_prime_size'] - 2048 - Minimal acceptable prime length in bits in /etc/ssh/moduli. Primes below this number will get removed. (See this for more information and background)

['ssh-hardening']['ssh']['server']['dh_build_primes'] - false - If own primes should be built. This rebuild happens only once and takes a lot of time (~ 1.5 - 2h on the modern hardware for 4096 length).

['ssh-hardening']['ssh']['server']['dh_build_primes_size'] - 4096 - Prime length which should be generated. This option is only valid if dh_build_primes is enabled.

['ssh-hardening']['ssh']['server']['listen_to']#override attribute# - one or more ip addresses, to which ssh-server should listen to. Default is to listen on all interfaces. It should be configured for security reasons!

['ssh-hardening']['ssh']['server']['deny_users'] - [] to configure DenyUsers, if specified login is disallowed for user names that match one of the patterns.

['ssh-hardening']['ssh']['server']['allow_users'] - [] to configure AllowUsers, if specified, login is allowed only for user names that match one of the patterns.

['ssh-hardening']['ssh']['server']['deny_groups'] - [] to configure DenyGroups, if specified, login is disallowed for users whose primary group or supplementary group list matches one of the patterns.

['ssh-hardening']['ssh']['server']['allow_groups'] - [] to configure AllowGroups, if specified, login is allowed only for users whose primary group or supplementary group list matches one of the patterns.

['ssh-hardening']['ssh']['server']['print_motd'] - false. Set to true to enable printing of the MOTD

['ssh-hardening']['ssh']['server']['print_last_log'] - false. Set to true to enable printing of last login information

['ssh-hardening']['ssh']['server']['banner'] - nil. Set a path like '/etc/issue.net' to enable the banner

['ssh-hardening']['ssh']['server']['os_banner'] - false to disable version information during the protocol handshake (debian family only). Set to true to enable it

['ssh-hardening']['ssh']['server']['use_dns'] - nil to use the openssh default. Set to true or false to enable/disable the DNS lookup and check of remote host

['ssh-hardening']['ssh']['server']['use_privilege_separation'] - nil to calculate the best value based on server version, otherwise set true or false

['ssh-hardening']['ssh']['server']['login_grace_time'] - 30s. Time in which the login should be successfully, otherwise the user is disconnected.

['ssh-hardening']['ssh']['server']['max_auth_tries'] - 2. The number of authentication attempts per connection

['ssh-hardening']['ssh']['server']['max_sessions'] - 10 The number of sessions per connection

['ssh-hardening']['ssh']['server']['password_authentication'] - false. Set to true if password authentication should be enabled

This will enable the SFTP Server and chroot every user in the sftpusers group to the /home/sftp/%u directory.

Local Testing

For local testing you can use vagrant and Virtualbox of VMWare to run tests locally. You will have to install Virtualbox and Vagrant on your system. See Vagrant Downloads for a vagrant package suitable for your system. For all our tests we use test-kitchen. If you are not familiar with test-kitchen please have a look at their guide. We are writing our test with InSpec.

FAQ / Pitfalls

I can't log into my account. I have registered the client key, but it still doesn't let me it.

If you have exhausted all typical issues (firewall, network, key missing, wrong key, account disabled etc.), it may be that your account is locked. The quickest way to find out is to look at the password hash for your user:

sudo grep myuser /etc/shadow

If the hash includes an !, your account is locked:

myuser:!:16280:7:60:7:::

The proper way to solve this is to unlock the account (passwd -u myuser). If the user doesn't have a password, you should can unlock it via:

usermod -p "*" myuser

Alternatively, if you intend to use PAM, you enabled it via ['ssh-hardening']['ssh']['use_pam'] = true. PAM will allow locked users to get in with keys.

Why doesn't my application connect via SSH anymore?

Always look into log files first and if possible look at the negotation between client and server that is completed when connecting.

We have seen some issues in applications (based on python and ruby) that are due to their use of an outdated crypto set. This collides with this hardening module, which reduced the list of ciphers, message authentication codes (MACs) and key exchange (KEX) algorithms to a more secure selection.

If you find this isn't enough, feel free to activate the attributes cbc_requires for ciphers, weak_hmac for MACs and weak_kexfor KEX in the namespaces ['ssh-hardening']['ssh']['client'] or ['ssh-hardening']['ssh']['server'] based on where you want to support them.

Why can't I log to the SFTP server after I added a user to my SFTP group?

This is a ChrootDirectory ownership problem. sshd will reject SFTP connections to accounts that are set to chroot into any directory that has ownership/permissions that sshd considers insecure. sshd's strict ownership/permissions requirements dictate that every directory in the chroot path must be owned by root and only writable by the owner. So, for example, if the chroot environment is /home must be owned by root.

Contributing

License and Author

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.