HostKeys are currently checked to exist, but we don't check versions. As it turns out, there are different default host keys available for old vs new SSH versions. As an example: RedHat/CentOS/Oracle 6.4:

/etc/ssh/ssh_host_dsa_key
/etc/ssh/ssh_host_key
/etc/ssh/ssh_host_rsa_key

And moving slightly over, Ubuntu 12.04:

 /etc/ssh/ssh_host_dsa_key
 /etc/ssh/ssh_host_ecdsa_key
 /etc/ssh/ssh_host_rsa_key

We have 2 choices: Either require HostKeys and adopt checking for the different versions and OSes, or ignore this field for hardening. If we support it, we have to make sure we use the correct fields in both puppet and chef as well.

SSH server already does some nice checking when starting to see if the host key is not world-writable. Also, the defaults are sane for all supported operating systems. Imho, unless there is a reason to specify, we should leave it out of integration testing.

I'm currently working on dev-sec/chef-ssh-hardening#87,

During the test I get following:

 ✖  sshd-01: Server: Check for secure ssh ciphers (
     expected: "[email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr"
          got: "aes256-ctr,aes192-ctr,aes128-ctr,[email protected],[email protected],[email protected],aes256-cbc,aes192-cbc,aes128-cbc"

     (compared using ==)
     )
     ✖  SSH Configuration Ciphers should eq "[email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr"

     expected: "[email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr"
          got: "aes256-ctr,aes192-ctr,aes128-ctr,[email protected],[email protected],[email protected],aes256-cbc,aes192-cbc,aes128-cbc"

     (compared using ==)

I know, I have here a bug with *-cbc ciphers which should be absent. But I have another question: is there some way to compare the ciphers, especially its('Ciphers') as an array?

The related code is here and here

@atomic111 @chris-rock @arlimus any hint?

Describe the bug
Applying ansible-ssh-hardening only adds UseRoaming no to /etc/ssh/ssh_config when OpenSSH version is <= 7.1 .

https://github.com/dev-sec/ansible-ssh-hardening/blob/master/templates/openssh.conf.j2#L114

However, the ssh-baseline inspec profile does not account for the OpenSSH version in control ssh-21 (it always requires UseRoaming no to be present) so it will not pass if you have OpenSSH version > 7.1.

https://github.com/dev-sec/ssh-baseline/blob/master/controls/ssh_spec.rb#L223

Expected behavior
Having OpenSSH 7.6p1 installed should not result in the ssh-baseline inspec profile to fail control ssh-21.

Actual behavior

 <testcase name='SSH Configuration UseRoaming should eq &quot;no&quot;' classname='ssh-baseline.ssh-21' target='ssh://[email protected]:2200' time='0.00801644'>
      <failure message='
expected: &quot;no&quot;
     got: nil

(compared using ==)
'/>
    </testcase>

Example code

- name: apply remediations
  hosts: all
  become: true

  tasks:
    - import_tasks: playbooks/entropy.yml
    - import_tasks: playbooks/ssh.yml

inspec exec https://github.com/dev-sec/ssh-baseline \
                --host=127.0.0.1 \
                --backend=ssh \
                --user=ubuntu \
                --sudo \
                --no-distinct-exit \
                --port=2200 \
                --key-files=$(ls /tmp/ansible-key*) \
                --no-color \
                --reporter cli junit:results/dev-sec-ssh-baseline-test-results.xml

OS / Environment

Ubuntu 18.04 (ami-0edd3706ab2e952c4)

Inspec Version

2.3.4

Your version of InSpec is out of date! The latest version is 3.2.6.

Baseline Version

https://github.com/dev-sec/ssh-baseline/commit/3a0383bb6b1b3e2ed3d8ac315b55f75868baad6d
https://github.com/dev-sec/ansible-ssh-hardening/commit/75f7153a6d73cb3a4e3ee54d77d4ae90a9231245

Although you can specify a path for the ssh config it seems to assume that the host keys are always assumed to be in /etc/ssh

here's the bit of code

# returns the hostkeys value based on valid_algorithms
def valid_hostkeys
  hostkeys = valid_algorithms.map { |alg| "/etc/ssh/sshhost#{alg}_key" }
  # its('HostKey') provides a string for a single-element value.
  # we have to return a string if we have a single-element
  # https://github.com/chef/inspec/issues/1434
  return hostkeys[0] if hostkeys.length == 1
  hostkeys
end

So we use BoKS which has it's ssh in an alternate directory and I can cope with that with both the ssh_config and the sshd_config resources because I can specify a path to the config but this doesn't look at it unfortunately.
What might be better is if you can provide a default path for the ssh directory, environment variable maybe that can be set or something that you can pass with --attrs perhaps.

Describe the bug
Using a CentOs 7 AMi, the build fails

Expected behavior
Build should pass

Actual behavior
Build is failing with:

amazon-ebs:   ×  ssh-22: Client: CRYPTO_POLICY
amazon-ebs:      ×  Control Source Code Error ssh-baseline-master/controls/ssh_spec.rb:231
amazon-ebs:      undefined method `match?' for nil:NilClass

OS / Environment

CentOs 7 AMI https://aws.amazon.com/marketplace/pp/Centosorg-CentOS-7-x8664-with-Updates-HVM/B00O7WM7QW

Inspec Version

3.7.11

Baseline Version

2.5.13

Describe the bug
Currently is defined that ssh on CentOS 6 supports only macs from macs53 list. With this settings it's impossible to connect by ssh from CentOS 6 to a server with CentOS 7 -- you can see it, when you compare lists macs53 and macs66.

Expected behavior
In man sshd_config with openssh v. 5.3p1-104.el6_6.1 you can see:

  MACs    Specifies the available MAC (message authentication code) algorithms.  The MAC algorithm is used in protocol version 2 for data integrity protection.  Multiple             
         algorithms must be comma-separated.  The default is:

               hmac-md5,hmac-sha1,[email protected],
               hmac-ripemd160,hmac-sha1-96,hmac-md5-96,
               hmac-sha2-256,hmac-sha2-512

So macs from macs59 list are supported and could be used.

Actual behavior
Only macs from macs53 list are allowed.

OS / Environment
CentOS 6, openssh 5.3p1-104.el6_6.1

Describe the bug
When running the ssh-baseline after hardening with ansible-ssh-hardening it fails on ubuntu 20.04

Expected behavior
Checks should pass

Actual behavior

×  Bash command test $(awk '$5 < 2047 && $5 ~ /^[0-9]+$/ { print $5 }' /etc/ssh/moduli | uniq | wc -c) -eq 0 stderr is expected to eq ""
    amazon-ebs:
    amazon-ebs:      expected: ""
    amazon-ebs:           got: "awk: fatal: cannot open file `/etc/ssh/moduli' for reading (Permission denied)\n"
    amazon-ebs:
    amazon-ebs:      (compared using ==)
    amazon-ebs:
    amazon-ebs:      Diff:
    amazon-ebs:      @@ -1 +1,2 @@
    amazon-ebs:      +awk: fatal: cannot open file `/etc/ssh/moduli' for reading (Permission denied)
    amazon-ebs: 
    amazon-ebs:   ↺  sshd-49: Server: CRYPTO_POLICY
    amazon-ebs:      ↺  Skipped control due to only_if condition: sshd with options is running
    amazon-ebs:
    amazon-ebs:
    amazon-ebs: Profile Summary: 21 successful controls, 1 control failure, 48 controls skipped
    amazon-ebs: Test Summary: 55 successful, 1 failure, 48 skipped

Example code

inspec exec https://github.com/dev-sec/ssh-baseline --log-level=debug --diagnose --no-distinct-exit

OS / Environment

Ubuntu 20.04

Inspec Version

4.23.15

create the tests for this commit dev-sec/chef-ssh-hardening#111

See dev-sec/ansible-ssh-hardening#254

Is your feature request related to a problem? Please describe.
AlmaLinux is a popular distribution and will be replacing CentOS by many users.

Describe the solution you'd like
Add support for AlmaLinux in the configuration.

Both puppet and chef also set ssh client config, which is currently not tested. This has led to issues with the puppet module. Let's add the client config to these tests and make sure it works as it should.

We changed the default behavior in dev-sec/puppet-ssh-hardening/pull/46 by removing 0.0.0.0 as default setting. This currently leads to failed tests:

rspec /tmp/busser/suites/serverspec/ssh_spec.rb:196 # check sshd_config File "/etc/ssh/sshd_config" content should match /^ListenAddress .*/

Is your feature request related to a problem? Please describe.
RedHad Enterprise Linux (and family) support SHA2 HMACs as of RHEL 6.5. Please see Detailed notes on the changes implemented in Red Hat Enterprise Linux 6.5 (BZ#969565).

Describe the solution you'd like
Implement the tests for SHA2 HMACs.

Additional context
See dev-sec/ansible-ssh-hardening#270

The fix is just to put the right expected for the right test.

Right now there's no easy way to install Ansible on the different operationg systems:

• Debian 6 does not have a package
• Oracle 6.4 misses PyYAML

For Debian ansible-omnibus is currently used: Omnibus downloads and runs the following shell script:

#!/bin/bash
sudo apt-get install -y build-essential python-dev python-setuptools
cd /tmp && wget http://releases.ansible.com/ansible/ansible-latest.tar.gz
tar xzf ansible-latest.tar.gz
cd ansible-* && sudo python setup.py install

One could also install (with the help of this shell script) python-pip and then install Ansible with pip install ansible.
The only problem now is that you have to know when to use apt-get or yum or foo-package-manager.
For that we could use pacapt. This script tries to determine the correct package manager and run the appropriate command (e.g. yum or apt-get). Right now pacapt doesn't support unattended upgrades (e.g. yum install foo --yes), but I created a issue for that.

Describe the bug
Protocol sftp is disabled by default. This enforces using scp. Described in README:

This role by default deactivates SFTP.

Expected behavior
Today I have read release notes of OpenSSH 8.0 when they say:

The scp protocol is outdated, inflexible and not readily fixed. We
recommend the use of more modern protocols like sftp and rsync for
file transfer instead.

So maybe it would be better to use sftp, rather than scp..

spaceport builds currently fail with this:

/tmp/busser/suites/serverspec/ssh_spec.rb:21:in `block in <top (required)>': undefined method `backend' for main:Object (NoMethodError)�

Most probably related to a breaking change in serverspec-2.0, http://serverspec.org/changes-of-v2.html

Here a bounch of option ssh-baseline say it's required and, at least for CentOS7, claimed as deprecated

• UseLogin
• RSAAuthentication
• RhostsRSAAuthentication

would be interesting to ignore these on CentOS7 at least.

Regards!

Jonathan

Is your feature request related to a problem? Please describe.
I use https://github.com/dev-sec/cis-dil-benchmark as well as this profile. In the cis profile the check is '<60'. To put '30s' instead of '30' makes this check red.

Describe the solution you'd like
Use '30' instead of '30s'.

Describe alternatives you've considered
Disable this check and rely only on the one provided by the cis profile.

Is your feature request related to a problem? Please describe.
I would like to test a sshd running in a container with another user.

Running a sshd with another user in a container environment is more secure than root.

Describe the solution you'd like
The possibility to set the user that replace root in the tests.
Handle UsePrivilegeSeparation no and UsePam no as stated here https://serverfault.com/questions/344295/is-it-possible-to-run-sshd-as-a-normal-user

Currently if there are Match blocks containing an option, inspec will return an array

for example

�[0;32m        "\u001b[38;5;9m  ×  sshd-39: Server: Disable TCP forwarding", �[0m
�[0;32m        "\u001b[38;5;9m     ×  SSHD Configuration AllowTcpForwarding should eq \"no\"", �[0m
�[0;32m        "     ", �[0m
�[0;32m        "     expected: \"no\"", �[0m
�[0;32m        "          got: [\"no\", \"yes\", \"no\", \"no\", \"yes\", \"no\"]", �[0m

ideally it should be possible to match default config value (the one outside of any Match block or inside a 'Match all') and the one per Match rule string.

tested on 2.2.78-1

I'm new to Ansible and have got a lot of value from your ansible-ssh-hardening project, thanks!

I did hit one snag with the MaxAuthTries setting of 2, compared to the default of 6. I actually managed to lock myself out of a host due to my ssh agent offering different keys before the correct one, causing a "Too many authentication failures for XXX" disconnection. After discovering the issue I wanted to understand from the baseline why this setting is chosen.

I read the description for this control baseline and am struggling to see if changing this setting offers any tangible benefits for the increased risk of inconvenience (based on the fact the baseline already requires password login disabled).

I wanted to offer a general observation here. The internet is full of varying quality guides for hardening SSH with very little reference to reputable STIG or other similar frameworks for secure configuration. I think the vision for this project is fantastic, it should streamline things for many people but I think it's important to track why baseline settings are chosen, citations for any particular attack vectors and noting some of the tradeoffs for the decision. Otherwise it feels like just an extension of "cargo cult" style blog posts where everyone is offering their chosen secure settings with little critical evaluation on why this setting was chosen.

Are you able to provide some background on this setting?

I'm happy to open a PR for the ansible-ssh-hardening to update the documentation/faq to flag this, unfortunately as Ansible uses SSH as the control channel it's particularly sensitive to these types of issues!

Currently we distinguish different target parameters within library based on the distro information.

It would be much better to have this logic based on the openssh version instead (and maybe to keep the distro information logic as fallback), similar to the chef-ssh-hardening implementation.

This would save maintenance efforts with adding/updating distros.

Description

There are a number of checks made against the version of SSH within the controls. All rely on this particular command in ssh_crypto.rb.

inspec.command('ssh -V 2>&1 | cut -f1 -d" " | cut -f2 -d"_"').stdout.to_f

Reproduction steps

go to a server that you want to run the controls against.
execute the ssh command as shown above

ssh -V 2>&1 | cut -f1 -d" " | cut -f2 -d"_"

[xxxx@xxxxx ~]$ ssh -V 2>&1 | cut -f1 -d" " | cut -f2 -d"_"
7.4p1,

Current Behavior

[xxxx@xxxx ~]$ ssh -V 2>&1 | cut -f1 -d" " | cut -f2 -d"_"
7.4p1,

Obviously if you are going to be checking this via a numerical check, having non numerics in the result is problematic

Expected Behavior

I'd expect to see

7.4

OS / Environment

Redhat 7 (3.10.0-1160.76.1.el7.x86_64)

Inspec Version

5.17.4

Baseline Version

ssh-baseline-2.8.0

Additional information

To get this to return the correct information I did this (although I'm sure there's a better way.

ssh -V 2>&1 | cut -f1 -d" " | cut -f2 -d"_"| sed "s/(.)p./\1/"

Hi,

I've recently built openssh and learned the following: sshd privilege separation feature requires specific "privsep" directory (sshd chroot) ownership & permissions to be applied.

• path to privsep dir differs between common distributions: /var/empty/sshd(RHEL) or /var/run/sshd (Debian) or xxx if ./configure --with-privsep-path=xxx
• owned by root or yyy if ./configure --with-privsep-user=yyy
• additional permissions: not readable/writable by group and "others"

I am not sure on the following bonus assumptions:

• sshd system user must (?) exist with home directory == privsep directory and a "nologin" shell, so in sum it must not be able to read/write from/to the privsep directory*
• no files should (?) exist within privsep dir: https://github.com/openssh/openssh-portable/blob/master/README.privsep

So if sshd UsePrivilegeSeparation is enabled - which is true on common Linux distributions - the privdir requirements above should be verified aswell.

Do you think such checks make sense as an addition to https://github.com/dev-sec/ssh-baseline/blob/master/controls/sshd_spec.rb#L186 ? Or linux-baseline? Or not at all?

Best Regards,
Markus

Hi,

I've been running the ssh-baseline for sometime and recently ran the CentOS 7 CIS-1 baseline and the xccdf_org.cisecurity.benchmarks_rule_5.2.3_Ensure_SSH_LogLevel_is_set_to_INFO control fails:

×  xccdf_org.cisecurity.benchmarks_rule_5.2.3_Ensure_SSH_LogLevel_is_set_to_INFO: Ensure SSH LogLevel is set to INFO
   ×  SSHD Configuration LogLevel should eq "INFO"

   expected: "INFO"
        got: "VERBOSE"

   (compared using ==)

This baseline recommends setting it to VERBOSE; should sshd-13 be updated to check for INFO instead?

Stephen

Can you create a new release please ?

The last one is nearly a year old.

OpenSSH 7.6 deprecates hmac-ripemd160 MAC, see here: https://www.openssh.com/txt/release-7.6.
The baseline should reflect this.

According to this thread, compression can be vulnerable to CRIME/BREACH attacks (if the encrypted data carries public data as well).

I am not into crypto but I guess compression should be opt-in, at least, shouldn't it?

(This issue was migrated here from dev-sec/ansible-ssh-hardening#90)

Describe the bug
Can't start sshd baseline config at ssh server

Expected behavior
expected that sshd config start without errors

Actual behavior
in attached screen

Example code
in attached screen

**OS / Environment**

<!--- Provide all relevant information below, e.g. target OS versions, network device firmware, etc. -->

**Inspec Version**
4.37.17

Baseline Version
https://github.com/dev-sec/ssh-baseline/blob/master/controls/sshd_spec.rb

**Additional context**
Add any other context about the problem here.

Because of historical reasons (RHEL 6 did some special things) we use OS version to detect the best usable SSH Ciphers/Kex/Mac.

Instead we should use OpenSSH version to determine available ciphers.

Describe the bug
Since PR #163 sshd-14-check fires the following error for us:

×  sshd-14: Server: Specify SSH HostKeys
   ×  SSHD Configuration HostKey
   undefined local variable or method `sshd_custom_path' for ssh_crypto:#<Class:0x0000000006e25058>

Expected behavior
Test should pass as before.

Baseline Version

2.5.4

Hi,

Sorry to raise an issue for such a trivial thing, but there isn't a tag for the latest release. The changelog seems to be finalised so I assume it is 'released'?

Could someone add that? We like to reference specific versions where we can.

Thanks,
Tim

Is your feature request related to a problem? Please describe.
Create an automated release workflow.

Based on https://github.com/dev-sec/ansible-nginx-hardening/pull/28/files

We must add the inspec.yml version field update.

Internally, I use mikefarah/yq with the following cli:

yq w -I4 -i inspec.yml version ${nextRelease.version} && sed -i '1i---' inspec.yml

The sed is needed as yq removes the leading --- yq issue

What are your thoughts on that @rndmh3ro ?

After applying the ansible role I've ran ssh_scan which is inspired by Mozilla Guideline

In the result I've got

"recommendations": [
        "Add these key exchange algorithms: ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256",
        "Add these MAC algorithms: [email protected]"
      ],

Natually I'm interested to know if these should be considered at all, or this information is outdated?

Describe the bug
The subject option has been deprecated since OpenSSH 7.5 (https://www.openssh.com/txt/release-7.5), hence the check shall be conditional.

Expected behavior
No error

Actual behavior

  ×  sshd-16: Server: Use privilege separation
     ×  SSHD Configuration UsePrivilegeSeparation is expected to eq "sandbox"

     expected: "sandbox"
          got: nil

     (compared using ==)

OS / Environment

$ lsb_release -d
Description:	Ubuntu 20.04 LTS

$ ssh -V
OpenSSH_8.2p1 Ubuntu-4, OpenSSL 1.1.1f  31 Mar 2020

Inspec Version

$ inspec --version
4.18.114

Baseline Version

name: ssh-baseline
title: DevSec SSH Baseline
maintainer: DevSec Hardening Framework Team
copyright: DevSec Hardening Framework Team
copyright_email: [email protected]
license: Apache-2.0
summary: Test-suite for best-practice SSH hardening
version: 2.5.6
supports:
  - os-family: unix

Depending on the implementation, things like commented options may not make it into the final ssh file. Testing for them depends on the ssh-provider. As an example, puppet-ssh-hardening only puts in options that actually appear in the final config. This needs discussing and adjustments.

Describe the bug
Since PR 992faad we get the following error:

amazon-linux-ami:   ×  sshd-19: Server: Specify Limit for maximum authentication retries
amazon-linux-ami:      ×  SSHD Configuration MaxAuthTries should be == 2
amazon-linux-ami:      expected: == 2
amazon-linux-ami:           got:    "2"

Expected behavior
Test should pass.

Actual behavior

amazon-linux-ami:   ×  sshd-19: Server: Specify Limit for maximum authentication retries
amazon-linux-ami:      ×  SSHD Configuration MaxAuthTries should be == 2
amazon-linux-ami:      expected: == 2
amazon-linux-ami:           got:    "2"

Inspec Version
3.6.6

I am getting an error - seems to be specific to the ruby script in the libraries folder

  ✔  ssh-21: Client: Do not allow Roaming
     ✔  SSH Configuration UseRoaming should eq "no"
  ✖  sshd-01: Server: Check for secure ssh ciphers (undefined local variable or method `ssh_crypto' for #<RSpec::ExampleGroups::SSHConfiguration_21::Ciphers:0x007fbb93984238>
     Did you mean?  ssh_config)
  ✖  sshd-02: Server: Check for secure ssh Key-Exchange Algorithm (undefined local variable or method `ssh_crypto' for #<RSpec::ExampleGroups::SSHConfiguration_22::KexAlgorithms:0x007fbb9397e798>
     Did you mean?  ssh_config)
  ✖  sshd-03: Server: Check for secure ssh Message Authentication Codes (undefined local variable or method `ssh_crypto' for #<RSpec::ExampleGroups::SSHConfiguration_23::MACs:0x007fbb9397c088>
     Did you mean?  ssh_config)

Ruby/Gem specifics

❯❯❯ ruby -v                                                                                                     ⏎
ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-darwin14]

christopher@PhishMe λ ~/inspec rb:ruby-2.3.1p112
❯❯❯ gem list

*** LOCAL GEMS ***

addressable (2.4.0)
ast (2.3.0)
bigdecimal (1.2.8)
builder (3.2.2)
bundler (1.13.1)
bundler-unload (1.0.2)
coderay (1.1.1)
colorize (0.8.1)
descendants_tracker (0.0.4)
did_you_mean (1.0.0)
diff-lcs (1.2.5)
docker-api (1.31.0)
erubis (2.7.0)
excon (0.52.0)
executable-hooks (1.3.2)
faraday (0.9.2)
ffi (1.9.14)
gem-wrappers (1.2.7)
github_api (0.14.5)
github_changelog_generator (1.12.1)
gssapi (1.2.0)
gyoku (1.3.1)
hashie (3.4.4)
highline (1.6.21)
httpclient (2.8.2.4)
inspec (0.34.1)
io-console (0.4.5)
json (2.0.2, 1.8.3)
jwt (1.5.4)
little-plugger (1.1.4)
logging (2.1.0)
method_source (0.8.2)
minitest (5.8.3)
mixlib-log (1.7.1)
mixlib-shellout (2.2.7)
multi_json (1.12.1)
multi_xml (0.5.5)
multipart-post (2.0.0)
net-scp (1.2.1)
net-ssh (3.2.0)
net-telnet (0.1.1)
nori (2.6.0)
oauth2 (1.2.0)
parallel (1.9.0)
parser (2.3.1.2)
power_assert (0.2.6)
powerpack (0.1.1)
pry (0.10.4)
psych (2.0.17)
rack (1.6.4)
rainbow (2.1.0)
rake (11.2.2, 10.4.2)
rdoc (4.2.1)
rspec (3.5.0)
rspec-core (3.5.3)
rspec-expectations (3.5.0)
rspec-its (1.2.0)
rspec-mocks (3.5.0)
rspec-support (3.5.0)
rubocop (0.36.0)
ruby-progressbar (1.8.1)
rubygems-bundler (1.4.4)
rubyntlm (0.6.0)
rubyzip (1.2.0)
rvm (1.11.3.9)
slop (3.6.0)
sslshake (1.0.12)
test-unit (3.1.5)
thor (0.19.1)
thread_safe (0.3.5)
train (0.19.0)
winrm (2.0.1)
winrm-fs (1.0.0)```

Ciphers, Mac, and Kex diverge at a few points. Ideally they should be the same. Unify and verify on operating systems.