9:40 a.m.
Hello Team,
One of our customer raised concern that --
The rule going wrong are:
xccdf_org.ssgproject.content_rule_file_permissions_sshd_private_key
xccdf_org.ssgproject.content_rule_file_permissions_sshd_pub_key
On the customer's system, the correct permissions seen --
Red Hat Enterprise Linux Server release 7.5 (Maipo)
openssh-server-7.4p1-16.el7.x86_64
openscap-1.2.16-6.el7.x86_64
- 640 for public key files (*.pub)
- 600 for private key files (*_key)
Output of ls –l /etc/ssh
-rw-r--r--. 1 root root 581843 Nov 24 2017 moduli
-rw-r--r--. 1 root root 2276 Nov 24 2017 ssh_config
-rw-------. 1 root root 4026 Sep 4 14:20 sshd_config
-rw-------. 1 root ssh_keys 241 Sep 4 14:20 ssh_host_ecdsa_key
-rw-r--r--. 1 root root 162 Sep 4 14:20 ssh_host_ecdsa_key.pub
-rw-------. 1 root ssh_keys 1704 Sep 4 14:20 ssh_host_rsa_key
-rw-r--r--. 1 root root 382 Sep 4 14:20 ssh_host_rsa_key.pub
-rw-r--r--. 1 root root 2548 Sep 4 14:20 ssh_known_hosts
Please find attached screenshot and suggest.
Warm Regards,
Dushyant Uge
Red Hat Global Support
9:44 a.m.
The scan fails because permissions should be 0640 for the private key. If
they are not set to 0640, this prevents sshd from generating keys.
On Thu, Sep 20, 2018 at 8:40 AM, Dushyant Uge <duge(a)redhat.com> wrote:
Hello Team,
One of our customer raised concern that --
The rule going wrong are:
xccdf_org.ssgproject.content_rule_file_permissions_sshd_private_key
xccdf_org.ssgproject.content_rule_file_permissions_sshd_pub_key
On the customer's system, the correct permissions seen --
Red Hat Enterprise Linux Server release 7.5 (Maipo)
openssh-server-7.4p1-16.el7.x86_64
openscap-1.2.16-6.el7.x86_64
- 640 for public key files (*.pub)
- 600 for private key files (*_key)
Output of ls –l /etc/ssh
-rw-r--r--. 1 root root 581843 Nov 24 2017 moduli
-rw-r--r--. 1 root root 2276 Nov 24 2017 ssh_config
-rw-------. 1 root root 4026 Sep 4 14:20 sshd_config
-rw-------. 1 root ssh_keys 241 Sep 4 14:20 ssh_host_ecdsa_key
-rw-r--r--. 1 root root 162 Sep 4 14:20 ssh_host_ecdsa_key.pub
-rw-------. 1 root ssh_keys 1704 Sep 4 14:20 ssh_host_rsa_key
-rw-r--r--. 1 root root 382 Sep 4 14:20 ssh_host_rsa_key.pub
-rw-r--r--. 1 root root 2548 Sep 4 14:20 ssh_known_hosts
Please find attached screenshot and suggest.
Warm Regards,
Dushyant Uge
Red Hat Global Support
_______________________________________________
scap-security-guide mailing list -- scap-security-guide@lists.
fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave@
lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/scap-
security-guide(a)lists.fedorahosted.org
9:52 a.m.
New subject: EXTERNAL: Re: False positive message for sshd key file permission
Ok, there’s an inconsistency then. The DISA STIG says that the private keys need to be
0600. Looks like they set permissions to the DISA version of the rule, but are scanning
the SSG version of the rule.
Can you provide a “proof of concept” that shows the key generation failing if the
permissions are set to 0600 so I have something in my back pocket to show our customer?
Tom A.
From: Gabe Alford <redhatrises(a)gmail.com>
Sent: Thursday, September 20, 2018 10:44 AM
To: SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org>
Subject: EXTERNAL: Re: False positive message for sshd key file permission
The scan fails because permissions should be 0640 for the private key. If they are not set
to 0640, this prevents sshd from generating keys.
On Thu, Sep 20, 2018 at 8:40 AM, Dushyant Uge
<duge@redhat.com<mailto:duge@redhat.com>> wrote:
Hello Team,
One of our customer raised concern that --
The rule going wrong are:
xccdf_org.ssgproject.content_rule_file_permissions_sshd_private_key
xccdf_org.ssgproject.content_rule_file_permissions_sshd_pub_key
On the customer's system, the correct permissions seen --
Red Hat Enterprise Linux Server release 7.5 (Maipo)
openssh-server-7.4p1-16.el7.x86_64
openscap-1.2.16-6.el7.x86_64
- 640 for public key files (*.pub)
- 600 for private key files (*_key)
Output of ls –l /etc/ssh
-rw-r--r--. 1 root root 581843 Nov 24 2017 moduli
-rw-r--r--. 1 root root 2276 Nov 24 2017 ssh_config
-rw-------. 1 root root 4026 Sep 4 14:20 sshd_config
-rw-------. 1 root ssh_keys 241 Sep 4 14:20 ssh_host_ecdsa_key
-rw-r--r--. 1 root root 162 Sep 4 14:20 ssh_host_ecdsa_key.pub
-rw-------. 1 root ssh_keys 1704 Sep 4 14:20 ssh_host_rsa_key
-rw-r--r--. 1 root root 382 Sep 4 14:20 ssh_host_rsa_key.pub
-rw-r--r--. 1 root root 2548 Sep 4 14:20 ssh_known_hosts
Please find attached screenshot and suggest.
Warm Regards,
Dushyant Uge
Red Hat Global Support
_______________________________________________
scap-security-guide mailing list --
scap-security-guide@lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>
To unsubscribe send an email to
scap-security-guide-leave@lists.fedorahosted.org<mailto:scap-security-guide-leave@lists.fedorahosted.org>
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fe...
10:05 a.m.
New subject: EXTERNAL: Re: False positive message for sshd key file permission
On 9/20/18 10:52 AM, Albrecht, Thomas C wrote:
Ok, there’s an inconsistency then. The DISA STIG says that the
private keys need to be 0600. Looks like they set permissions to the
DISA version of the rule, but are scanning the SSG version of the rule.
Can you provide a “proof of concept” that shows the key generation
failing if the permissions are set to 0600 so I have something in my
back pocket to show our customer?
It's a known issue in the DISA content. We let them know about it a few
years ago now. Have been told a fix is making it's way through their
release processes.
1:30 p.m.
New subject: EXTERNAL: Re: False positive message for sshd key file permission
Thank you all for your responses.
@Albrecht, Thomas C
Yes, the customer said --
We are using the profile DISA STIG for Red Hat Enterprise Linux 7 based on
ssg-rhel7-ds security.xml as found on
https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.40...
and tried with the default openscap scanner from the RHEL 7.5 ISO as well
as the latest version available on the redhat site (1.2.16.8.el7_5).
Warm Regards,
Dushyant Uge
Red Hat Global Support
On Thu, Sep 20, 2018 at 8:05 AM, Shawn Wells <shawn(a)redhat.com> wrote:
On 9/20/18 10:52 AM, Albrecht, Thomas C wrote:
Ok, there’s an inconsistency then. The DISA STIG says that the private
keys need to be 0600. Looks like they set permissions to the DISA version
of the rule, but are scanning the SSG version of the rule.
Can you provide a “proof of concept” that shows the key generation failing
if the permissions are set to 0600 so I have something in my back pocket to
show our customer?
It's a known issue in the DISA content. We let them know about it a few
years ago now. Have been told a fix is making it's way through their
release processes.
_______________________________________________
scap-security-guide mailing list -- scap-security-guide@lists.
fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave@
lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/scap-
security-guide(a)lists.fedorahosted.org
7:23 a.m.
New subject: EXTERNAL: Re: False positive message for sshd key file permission
Hello,
@Shawn Wells <swells(a)redhat.com> you are right and I fixed our content, see
https://github.com/ComplianceAsCode/content/pull/3362 for more details. Is
it okay or should we stay with 0600 until DISA fixes it in their content?
Best Regards,
Matus
On Thu, Sep 20, 2018 at 8:31 PM Dushyant Uge <duge(a)redhat.com> wrote:
Thank you all for your responses.
@Albrecht, Thomas C
Yes, the customer said --
We are using the profile DISA STIG for Red Hat Enterprise Linux 7 based
on ssg-rhel7-ds security.xml as found on
https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.40...
and tried with the default openscap scanner from the RHEL 7.5 ISO as well
as the latest version available on the redhat site (1.2.16.8.el7_5).
Warm Regards,
Dushyant Uge
Red Hat Global Support
On Thu, Sep 20, 2018 at 8:05 AM, Shawn Wells <shawn(a)redhat.com> wrote:
>
>
> On 9/20/18 10:52 AM, Albrecht, Thomas C wrote:
>
> Ok, there’s an inconsistency then. The DISA STIG says that the private
> keys need to be 0600. Looks like they set permissions to the DISA version
> of the rule, but are scanning the SSG version of the rule.
>
> Can you provide a “proof of concept” that shows the key generation
> failing if the permissions are set to 0600 so I have something in my back
> pocket to show our customer?
>
>
> It's a known issue in the DISA content. We let them know about it a few
> years ago now. Have been told a fix is making it's way through their
> release processes.
>
> _______________________________________________
> scap-security-guide mailing list --
> scap-security-guide(a)lists.fedorahosted.org
> To unsubscribe send an email to
> scap-security-guide-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
>
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fe...
>
>
_______________________________________________
scap-security-guide mailing list --
scap-security-guide(a)lists.fedorahosted.org
To unsubscribe send an email to
scap-security-guide-leave(a)lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fe...
7:45 a.m.
New subject: EXTERNAL: Re: False positive message for sshd key file permission
I’d leave it, since something seems to revert the permissions later back to 0640.
(Probably a package update, but I haven’t researched it yet.).
Tom A.
Sent from my iPhone
On Sep 25, 2018, at 2:24 PM, Matus Marhefka
<mmarhefk@redhat.com<mailto:mmarhefk@redhat.com>> wrote:
Hello,
@Shawn Wells<mailto:swells@redhat.com> you are right and I fixed our content, see
https://github.com/ComplianceAsCode/content/pull/3362 for more details. Is it okay or
should we stay with 0600 until DISA fixes it in their content?
Best Regards,
Matus
On Thu, Sep 20, 2018 at 8:31 PM Dushyant Uge
<duge@redhat.com<mailto:duge@redhat.com>> wrote:
Thank you all for your responses.
@Albrecht, Thomas C
Yes, the customer said --
We are using the profile DISA STIG for Red Hat Enterprise Linux 7 based on ssg-rhel7-ds
security.xml as found on
https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.40...
and tried with the default openscap scanner from the RHEL 7.5 ISO as well as the latest
version available on the redhat site (1.2.16.8.el7_5).
Warm Regards,
Dushyant Uge
Red Hat Global Support
On Thu, Sep 20, 2018 at 8:05 AM, Shawn Wells
<shawn@redhat.com<mailto:shawn@redhat.com>> wrote:
On 9/20/18 10:52 AM, Albrecht, Thomas C wrote:
Ok, there’s an inconsistency then. The DISA STIG says that the private keys need to be
0600. Looks like they set permissions to the DISA version of the rule, but are scanning
the SSG version of the rule.
Can you provide a “proof of concept” that shows the key generation failing if the
permissions are set to 0600 so I have something in my back pocket to show our customer?
It's a known issue in the DISA content. We let them know about it a few years ago now.
Have been told a fix is making it's way through their release processes.
_______________________________________________
scap-security-guide mailing list --
scap-security-guide@lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>
To unsubscribe send an email to
scap-security-guide-leave@lists.fedorahosted.org<mailto:scap-security-guide-leave@lists.fedorahosted.org>
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fe...
_______________________________________________
scap-security-guide mailing list --
scap-security-guide@lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>
To unsubscribe send an email to
scap-security-guide-leave@lists.fedorahosted.org<mailto:scap-security-guide-leave@lists.fedorahosted.org>
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fe...
_______________________________________________
scap-security-guide mailing list --
scap-security-guide@lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>
To unsubscribe send an email to
scap-security-guide-leave@lists.fedorahosted.org<mailto:scap-security-guide-leave@lists.fedorahosted.org>
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fe...
10:22 a.m.
New subject: EXTERNAL: Re: False positive message for sshd key file permission
On 9/25/18 8:45 AM, Albrecht, Thomas C wrote:
I’d leave it, since something seems to revert the permissions later
back to 0640. (Probably a package update, but I haven’t researched it yet.).
+1, agree with Tom.
2039
days inactive
2045
days old
scap-security-guide@lists.fedorahosted.org
7 comments
5 participants
participants (5)
-
Albrecht, Thomas C -
Dushyant Uge -
Gabe Alford -
Matus Marhefka -
Shawn Wells