Disabling passwords in the cloud

[Fen Labalme]

If password access is disabled on a cloud-based server - both from
(virtual) console and via SSH - can the set of password checks be disabled
somehow?

- 10 checks: Set Password Quality Requirements with pam_pwquality
   -  5 checks: Set Lockouts for Failed Password Attempts
   -  3 checks: Set Password Hashing Algorithm

Thanks,
=Fen

[Shawn Wells]

On 6/7/17 12:04 PM, Fen Labalme wrote:
> If password access is disabled on a cloud-based server - both from
> (virtual) console and via SSH - can the set of password checks be
> disabled somehow?
> 10 checks: Set Password Quality Requirements with pam_pwquality
> 5 checks: Set Lockouts for Failed Password Attempts
> 3 checks: Set Password Hashing Algorithm

OVAL has the ability to do conditional clauses, e.g. most of the SSH
checks will be notapplicable/pass if sshd is not installed.

Can evaluate password access in sshd configs, but that's only for ssh
server.... what do we check to see if password access is disabled for
the entire system?

[Fen Labalme]

On Wed, Jun 7, 2017 at 1:41 PM, Shawn Wells  wrote:
> OVAL has the ability to do conditional clauses, e.g. most of the SSH
> checks will be notapplicable/pass if sshd is not installed.

This is great, and on a cloud server in a fedramp certified facility one
might think it enough, as how would someone log in other than by using SSH?

Can evaluate password access in sshd configs, but that's only for ssh
> server.... what do we check to see if password access is disabled for the
> entire system?

I can't remember the process offhand, but I believe disabling pam_unix will
prevent access to /etc/passwd or /etc/shadow.

=Fen

[Shawn Wells]

On 6/7/17 4:21 PM, Fen Labalme wrote:
> On Wed, Jun 7, 2017 at 1:41 PM, Shawn Wells <[e-mail]
> > wrote:
> OVAL has the ability to do conditional clauses, e.g. most of the
> SSH checks will be notapplicable/pass if sshd is not installed.
>
>
> This is great, and on a cloud server in a fedramp certified facility
> one might think it enough, as how would someone log in other than by
> using SSH?
> Can evaluate password access in sshd configs, but that's only for
> ssh server.... what do we check to see if password access is
> disabled for the entire system?
>
>
> I can't remember the process offhand, but I believe disabling pam_unix
> will prevent access to /etc/passwd or /etc/shadow.

If you have the interest + time to document how to set this up, it'd be
a worthwhile extension to the OVAL checks.

https://serverfault.com/questions/783082/how-to-use-the-ssh-server-with-pam-...
might get you started

[Brent Kimberley]

Does sshd need to be recompiled - in order to completely disable password authentication?

I would like to reduce the number of false positives in /var/log/secure
^.*sshd.*: Invalid user .* from .*$
^.*sshd.*: reverse mapping checking getaddrinfo for .* failed - POSSIBLE BREAK-IN ATTEMPT!$
^.* sshd.*: input_userauth_request: invalid user .*$
THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.

[Shawn Wells]

On 6/8/17 9:38 AM, Brent Kimberley wrote:
> Does sshd need to be recompiled - in order to completely disable
> password authentication?
>
> I would like to reduce the number of false positives in /var/log/secure
>
> ^.*sshd.*: Invalid user .* from .*$
>
> ^.*sshd.*: reverse mapping checking getaddrinfo for .* failed -
> POSSIBLE BREAK-IN ATTEMPT!$
>
> ^.* sshd.*: input_userauth_request: invalid user .*$

In theory, should be able to disable ChallengeResponseAuthentication and
PasswordAuthentication, then call it a day. Never actually tried, though.

[Non-DoD Source] Re: Disabling passwords in the cloud

[McIntyre, James T. (Farragut Suitland, MD)]

Not sure I understand the complete question.

We do person by person as in loading up authorized_keys with the personal 
rsa.pub key such as:
cat .ssh/id_rsa.pub | ssh b@B 'cat >> .ssh/authorized_keys'.  Will ask you for 
password to complete the task.  Once done, should not ask for password until 
key changes.

The .ssh lives in the home folder of each user so that each user has a unique 
key loaded into their remote home folder.

This gives us passwordless ssh as well as positive identity of each individual 
to load them into the proper account.  Same goes for root so that root will 
ssh into root.

Recompiling, must not.  Positive ID, must have.

Am I way off base?

-----Original Message-----
From: Shawn Wells [mailto:[e-mail]]
Sent: Thursday, June 08, 2017 10:28 PM
To: [e-mail]
Subject: [Non-DoD Source] Re: Disabling passwords in the cloud

On 6/8/17 9:38 AM, Brent Kimberley wrote:

Does sshd need to be recompiled - in order to completely disable password 
authentication?

I would like to reduce the number of false positives in /var/log/secure

^.*sshd.*: Invalid user .* from .*$

^.*sshd.*: reverse mapping checking getaddrinfo for .* failed - POSSIBLE 
BREAK-IN ATTEMPT!$

^.* sshd.*: input_userauth_request: invalid user .*$

In theory, should be able to disable ChallengeResponseAuthentication and 
PasswordAuthentication, then call it a day. Never actually tried, though.

[Non-DoD Source] Re: Disabling passwords in the cloud

[Sean]

I believe the sshd directives to configure the daemon to use keys only for
authentication is mostly all that's required to disable passwords.  I've
used this before.  Be aware that it only affects using passwords to access
the system via ssh though. You will also see password attempts failing in
your logs from all the attacks your servers face.

You would still need user passwords for sudo access. To remedy that, there
are two relatively simple methods, both have security flaws.

1. Disable password challenges in sudo rules, which I think is a horrible
idea for security.

2. Use pam_ssh_agent_auth module and pam_sudo, and use ssh key agents on
the clients. This will make sudo authenticate that the agent's key matched
the user's authorized key for the authentication challenge. I don't presume
to think this can't be compromised, but it's a workable solution and better
than passwordless sudo.

On Jun 12, 2017 9:18 AM, "McIntyre, James T. (Farragut Suitland, MD)" <
[e-mail]> wrote:
> Not sure I understand the complete question.
>
> We do person by person as in loading up authorized_keys with the personal
> rsa.pub key such as:
> cat .ssh/id_rsa.pub | ssh b@B 'cat >> .ssh/authorized_keys'.  Will ask
> you for
> password to complete the task.  Once done, should not ask for password
> until
> key changes.
>
> The .ssh lives in the home folder of each user so that each user has a
> unique
> key loaded into their remote home folder.
>
> This gives us passwordless ssh as well as positive identity of each
> individual
> to load them into the proper account.  Same goes for root so that root will
> ssh into root.
>
> Recompiling, must not.  Positive ID, must have.
>
> Am I way off base?
>
> -----Original Message-----
> From: Shawn Wells [mailto:[e-mail]]
> Sent: Thursday, June 08, 2017 10:28 PM
> To: [e-mail]
> Subject: [Non-DoD Source] Re: Disabling passwords in the cloud
>
> On 6/8/17 9:38 AM, Brent Kimberley wrote:
>     Does sshd need to be recompiled - in order to completely disable
>
> password
> authentication?
>     I would like to reduce the number of false positives in
>
> /var/log/secure
>     ^.*sshd.*: Invalid user .* from .*$
>
>     ^.*sshd.*: reverse mapping checking getaddrinfo for .* failed -
>
> POSSIBLE
> BREAK-IN ATTEMPT!$
>     ^.* sshd.*: input_userauth_request: invalid user .*$
>
>
> In theory, should be able to disable ChallengeResponseAuthentication and
> PasswordAuthentication, then call it a day. Never actually tried, though.
>
> scap-security-guide mailing list -- scap-security-guide@lists.
> fedorahosted.org
> To unsubscribe send an email to scap-security-guide-leave@
> lists.fedorahosted.org

[Non-DoD Source] Re: Disabling passwords in the cloud

[McIntyre, James T. (Farragut Suitland, MD)]

Method #3

If you are in a PKEnabled environment using CAC and pin# to login, you can add 
CAC information such as (example depends on CAC registration):
/C=US/O=U.S. 
Government/OU=DoD/OU=PKI/OU=CONTRACTOR-or-USN-or-USMC-etc/CN=LASTNAME.FIRSTNAME.MIDDLENAME.DODID 
 -> local_username
to the top of /etc/pam.d/common-auth.  This will cause the requirement of a 
CAC and pin# to get into sudo, su and possibly ssh as well.

Unfortunately this method might be impractical in that the 
/etc/pam.d/common-auth file only pertains to the local host it resides on.  If 
you have 5 servers with this setting, you will need to move your CAC to the 
server you are sudoing into.  Good for single local hosts but not so good with 
multiple remote hosts.

We might be deploying a KVM solution that provides CAC support so that 
whichever system you are switched to, CAC support is provided.

Otherwise Sean's method 2 would be a good solution where a user's key is 
passed and matched as an authorized key.

As a preventative measure for unauthorized password attempts would be setting 
a rule in IPTables to only allow specific networks to login.  Even narrowing 
the rule down to specific IPs of your users or cloud services.  I would have 
to dust off my rules but an example would be something like iptables -I 
INPUT -p tcp ! -s yourIPaddress --dport 22 -j DROP.

I know this is getting off topic but at least wanted to address reduction of 
unauthorized login errors.

-----Original Message-----
From: Sean [mailto:[e-mail]]
Sent: Monday, June 12, 2017 10:08 AM
To: SCAP Security Guide
Subject: RE: [Non-DoD Source] Re: Disabling passwords in the cloud

I believe the sshd directives to configure the daemon to use keys only for 
authentication is mostly all that's required to disable passwords.  I've used 
this before.  Be aware that it only affects using passwords to access the 
system via ssh though. You will also see password attempts failing in your 
logs from all the attacks your servers face.

You would still need user passwords for sudo access. To remedy that, there are 
two relatively simple methods, both have security flaws.

1. Disable password challenges in sudo rules, which I think is a horrible idea 
for security.

2. Use pam_ssh_agent_auth module and pam_sudo, and use ssh key agents on the 
clients. This will make sudo authenticate that the agent's key matched the 
user's authorized key for the authentication challenge. I don't presume to 
think this can't be compromised, but it's a workable solution and better than 
passwordless sudo.

On Jun 12, 2017 9:18 AM, "McIntyre, James T. (Farragut Suitland, MD)" 
 wrote:

Not sure I understand the complete question.

We do person by person as in loading up authorized_keys with the personal
    rsa.pub key such as:
    cat .ssh/id_rsa.pub | ssh b@B 'cat >> .ssh/authorized_keys'.  Will ask you 
for
    password to complete the task.  Once done, should not ask for password until
    key changes.

The .ssh lives in the home folder of each user so that each user has a unique
    key loaded into their remote home folder.

This gives us passwordless ssh as well as positive identity of each 
individual
    to load them into the proper account.  Same goes for root so that root will
    ssh into root.

Recompiling, must not.  Positive ID, must have.

Am I way off base?

-----Original Message-----
    From: Shawn Wells [mailto:[e-mail]]
    Sent: Thursday, June 08, 2017 10:28 PM
    To: [e-mail] 

    Subject: [Non-DoD Source] Re: Disabling passwords in the cloud

On 6/8/17 9:38 AM, Brent Kimberley wrote:

Does sshd need to be recompiled - in order to completely disable 
password
    authentication?

I would like to reduce the number of false positives in 
/var/log/secure

^.*sshd.*: Invalid user .* from .*$

^.*sshd.*: reverse mapping checking getaddrinfo for .* failed - 
POSSIBLE
    BREAK-IN ATTEMPT!$

^.* sshd.*: input_userauth_request: invalid user .*$

In theory, should be able to disable ChallengeResponseAuthentication and
    PasswordAuthentication, then call it a day. Never actually tried, though.

_______________________________________________
    scap-security-guide mailing list --  
[e-mail] 

    To unsubscribe send an email to 
[e-mail]

[Non-DoD Source] Re: Disabling passwords in the cloud

[Andrew Gilmore]

Alteration of #3:

You can use the CAC card as a certificate source for an ssh key directly.
This should be forwardable via ssh agents etc., if that's reasonable. A KVM
to switch around the CAC reader becomes unworkable at some point.

On Mon, Jun 12, 2017 at 12:49 PM, McIntyre, James T. (Farragut Suitland,
MD)  wrote:
> Method #3
>
> If you are in a PKEnabled environment using CAC and pin# to login, you can
> add
> CAC information such as (example depends on CAC registration):
> /C=US/O=U.S.
> Government/OU=DoD/OU=PKI/OU=CONTRACTOR-or-USN-or-USMC-etc/
> CN=LASTNAME.FIRSTNAME.MIDDLENAME.DODID
>  -> local_username
> to the top of /etc/pam.d/common-auth.  This will cause the requirement of a
> CAC and pin# to get into sudo, su and possibly ssh as well.
>
> Unfortunately this method might be impractical in that the
> /etc/pam.d/common-auth file only pertains to the local host it resides
> on.  If
> you have 5 servers with this setting, you will need to move your CAC to the
> server you are sudoing into.  Good for single local hosts but not so good
> with
> multiple remote hosts.
>
> We might be deploying a KVM solution that provides CAC support so that
> whichever system you are switched to, CAC support is provided.
>
> Otherwise Sean's method 2 would be a good solution where a user's key is
> passed and matched as an authorized key.
>
> As a preventative measure for unauthorized password attempts would be
> setting
> a rule in IPTables to only allow specific networks to login.  Even
> narrowing
> the rule down to specific IPs of your users or cloud services.  I would
> have
> to dust off my rules but an example would be something like iptables -I
> INPUT -p tcp ! -s yourIPaddress --dport 22 -j DROP.
>
> I know this is getting off topic but at least wanted to address reduction
> of
> unauthorized login errors.
>
> -----Original Message-----
> From: Sean [mailto:[e-mail]]
> Sent: Monday, June 12, 2017 10:08 AM
> To: SCAP Security Guide
> Subject: RE: [Non-DoD Source] Re: Disabling passwords in the cloud
>
> I believe the sshd directives to configure the daemon to use keys only for
> authentication is mostly all that's required to disable passwords.  I've
> used
> this before.  Be aware that it only affects using passwords to access the
> system via ssh though. You will also see password attempts failing in your
> logs from all the attacks your servers face.
>
> You would still need user passwords for sudo access. To remedy that, there
> are
> two relatively simple methods, both have security flaws.
> Disable password challenges in sudo rules, which I think is a horrible
>
> idea
> for security.
> Use pam_ssh_agent_auth module and pam_sudo, and use ssh key agents on
>
> the
> clients. This will make sudo authenticate that the agent's key matched the
> user's authorized key for the authentication challenge. I don't presume to
> think this can't be compromised, but it's a workable solution and better
> than
> passwordless sudo.
>
> On Jun 12, 2017 9:18 AM, "McIntyre, James T. (Farragut Suitland, MD)"
>  wrote:
>     Not sure I understand the complete question.
>
>     We do person by person as in loading up authorized_keys with the
>
> personal
>         rsa.pub key such as:
>         cat .ssh/id_rsa.pub | ssh b@B 'cat >> .ssh/authorized_keys'.
> Will ask you
> for
>         password to complete the task.  Once done, should not ask for
> password until
>         key changes.
>     The .ssh lives in the home folder of each user so that each user
>
> has a unique
>         key loaded into their remote home folder.
>     This gives us passwordless ssh as well as positive identity of each
>
> individual
>         to load them into the proper account.  Same goes for root so that
> root will
>         ssh into root.
>     Recompiling, must not.  Positive ID, must have.
>
>     Am I way off base?
>
>     -----Original Message-----
>     From: Shawn Wells [mailto:[e-mail]]
>     Sent: Thursday, June 08, 2017 10:28 PM
>     To: [e-mail]
>
>         Subject: [Non-DoD Source] Re: Disabling passwords in the cloud
>     On 6/8/17 9:38 AM, Brent Kimberley wrote:
>
>
>             Does sshd need to be recompiled - in order to completely
>
> disable
> password
>         authentication?
>             I would like to reduce the number of false positives in
>
> /var/log/secure
>             ^.*sshd.*: Invalid user .* from .*$
>
>             ^.*sshd.*: reverse mapping checking getaddrinfo for .*
>
> failed -
> POSSIBLE
>         BREAK-IN ATTEMPT!$
>             ^.* sshd.*: input_userauth_request: invalid user .*$
>
>
>     In theory, should be able to disable ChallengeResponseAuthentication
>
> and
>         PasswordAuthentication, then call it a day. Never actually tried,
> though.
>     _______________________________________________
>     scap-security-guide mailing list --
>
> [e-mail]
>
>         To unsubscribe send an email to
> [e-mail]
>
> scap-security-guide mailing list -- scap-security-guide@lists.
> fedorahosted.org
> To unsubscribe send an email to scap-security-guide-leave@
> lists.fedorahosted.org

[Non-DoD Source] Re: Disabling passwords in the cloud

[Brent Kimberley]

CAC support for the KVM is a good first step.

https://blogs.technet.microsoft.com/mmpc/2017/06/07/platinum-continues-to-ev...

From: Andrew Gilmore [mailto:[e-mail]]
Sent: Tuesday, June 13, 2017 12:23 AM
To: SCAP Security Guide 
Subject: Re: [Non-DoD Source] Re: Disabling passwords in the cloud

Alteration of #3:

You can use the CAC card as a certificate source for an ssh key directly. This should be forwardable via ssh agents etc., if that's reasonable. A KVM to switch around the CAC reader becomes unworkable at some point.

On Mon, Jun 12, 2017 at 12:49 PM, McIntyre, James T. (Farragut Suitland, MD) <[e-mail]> wrote:
Method #3

If you are in a PKEnabled environment using CAC and pin# to login, you can add
CAC information such as (example depends on CAC registration):
/C=US/O=U.S.
Government/OU=DoD/OU=PKI/OU=CONTRACTOR-or-USN-or-USMC-etc/CN=LASTNAME.FIRSTNAME.MIDDLENAME.DODID
 -> local_username
to the top of /etc/pam.d/common-auth.  This will cause the requirement of a
CAC and pin# to get into sudo, su and possibly ssh as well.

Unfortunately this method might be impractical in that the
/etc/pam.d/common-auth file only pertains to the local host it resides on.  If
you have 5 servers with this setting, you will need to move your CAC to the
server you are sudoing into.  Good for single local hosts but not so good with
multiple remote hosts.

We might be deploying a KVM solution that provides CAC support so that
whichever system you are switched to, CAC support is provided.

Otherwise Sean's method 2 would be a good solution where a user's key is
passed and matched as an authorized key.

As a preventative measure for unauthorized password attempts would be setting
a rule in IPTables to only allow specific networks to login.  Even narrowing
the rule down to specific IPs of your users or cloud services.  I would have
to dust off my rules but an example would be something like iptables -I
INPUT -p tcp ! -s yourIPaddress --dport 22 -j DROP.

I know this is getting off topic but at least wanted to address reduction of
unauthorized login errors.

-----Original Message-----
From: Sean [mailto:[e-mail]]
Sent: Monday, June 12, 2017 10:08 AM
To: SCAP Security Guide
Subject: RE: [Non-DoD Source] Re: Disabling passwords in the cloud

I believe the sshd directives to configure the daemon to use keys only for
authentication is mostly all that's required to disable passwords.  I've used
this before.  Be aware that it only affects using passwords to access the
system via ssh though. You will also see password attempts failing in your
logs from all the attacks your servers face.

You would still need user passwords for sudo access. To remedy that, there are
two relatively simple methods, both have security flaws.

1. Disable password challenges in sudo rules, which I think is a horrible idea
for security.

2. Use pam_ssh_agent_auth module and pam_sudo, and use ssh key agents on the
clients. This will make sudo authenticate that the agent's key matched the
user's authorized key for the authentication challenge. I don't presume to
think this can't be compromised, but it's a workable solution and better than
passwordless sudo.

On Jun 12, 2017 9:18 AM, "McIntyre, James T. (Farragut Suitland, MD)"
<[e-mail]> wrote:

Not sure I understand the complete question.

We do person by person as in loading up authorized_keys with the personal
        rsa.pub key such as:
        cat .ssh/id_rsa.pub | ssh b@B 'cat >> .ssh/authorized_keys'.  Will ask you
for
        password to complete the task.  Once done, should not ask for password until
        key changes.

The .ssh lives in the home folder of each user so that each user has a unique
        key loaded into their remote home folder.

This gives us passwordless ssh as well as positive identity of each
individual
        to load them into the proper account.  Same goes for root so that root will
        ssh into root.

Recompiling, must not.  Positive ID, must have.

Am I way off base?

-----Original Message-----
        From: Shawn Wells [mailto:[e-mail]]
        Sent: Thursday, June 08, 2017 10:28 PM
        To: [e-mail]
<mailto:[e-mail]>
        Subject: [Non-DoD Source] Re: Disabling passwords in the cloud

On 6/8/17 9:38 AM, Brent Kimberley wrote:

Does sshd need to be recompiled - in order to completely disable
password
        authentication?

I would like to reduce the number of false positives in
/var/log/secure

^.*sshd.*: Invalid user .* from .*$

^.*sshd.*: reverse mapping checking getaddrinfo for .* failed -
POSSIBLE
        BREAK-IN ATTEMPT!$

^.* sshd.*: input_userauth_request: invalid user .*$

In theory, should be able to disable ChallengeResponseAuthentication and
        PasswordAuthentication, then call it a day. Never actually tried, though.

_______________________________________________
        scap-security-guide mailing list --
[e-mail]
<mailto:[e-mail]>
        To unsubscribe send an email to
[e-mail]
<mailto:[e-mail]>

_______________________________________________
scap-security-guide mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]

THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.

[Non-DoD Source] Re: Disabling passwords in the cloud

[Fen Labalme]

Excellent OpenSSH security guidelines:
https://wiki.mozilla.org/Security/Guidelines/OpenSSH

As our servers are in the AWS (FedRAMP certified) cloud, there is no direct
console/tty access - only via SSH.

While non-compliant, we like to have (for example) a remote SCAP scanning
process log in as `oscap-user` and then run `sudo` (without a password) to
scan will elevated privileges. As all ssh sessions time out after 15
minutes of inactivity, and as auditd logs who executes `sudo` why is
disabling "password challenges in sudo rules ... a horrible idea for
security"?

Thanks,
=Fen

On Mon, Jun 12, 2017 at 10:07 AM, Sean  wrote:
> I believe the sshd directives to configure the daemon to use keys only for
> authentication is mostly all that's required to disable passwords.  I've
> used this before.  Be aware that it only affects using passwords to access
> the system via ssh though. You will also see password attempts failing in
> your logs from all the attacks your servers face.
>
> You would still need user passwords for sudo access. To remedy that, there
> are two relatively simple methods, both have security flaws.
> Disable password challenges in sudo rules, which I think is a horrible
>
> idea for security.
> Use pam_ssh_agent_auth module and pam_sudo, and use ssh key agents on
>
> the clients. This will make sudo authenticate that the agent's key matched
> the user's authorized key for the authentication challenge. I don't presume
> to think this can't be compromised, but it's a workable solution and better
> than passwordless sudo.
>
> On Jun 12, 2017 9:18 AM, "McIntyre, James T. (Farragut Suitland, MD)" <
> [e-mail]> wrote:
> > Not sure I understand the complete question.
> >
> > We do person by person as in loading up authorized_keys with the personal
> > rsa.pub key such as:
> > cat .ssh/id_rsa.pub | ssh b@B 'cat >> .ssh/authorized_keys'.  Will ask
> > you for
> > password to complete the task.  Once done, should not ask for password
> > until
> > key changes.
> >
> > The .ssh lives in the home folder of each user so that each user has a
> > unique
> > key loaded into their remote home folder.
> >
> > This gives us passwordless ssh as well as positive identity of each
> > individual
> > to load them into the proper account.  Same goes for root so that root
> > will
> > ssh into root.
> >
> > Recompiling, must not.  Positive ID, must have.
> >
> > Am I way off base?
> >
> > -----Original Message-----
> > From: Shawn Wells [mailto:[e-mail]]
> > Sent: Thursday, June 08, 2017 10:28 PM
> > To: [e-mail]
> > Subject: [Non-DoD Source] Re: Disabling passwords in the cloud
> >
> > On 6/8/17 9:38 AM, Brent Kimberley wrote:
> >     Does sshd need to be recompiled - in order to completely disable
> >
> > password
> > authentication?
> >     I would like to reduce the number of false positives in
> >
> > /var/log/secure
> >     ^.*sshd.*: Invalid user .* from .*$
> >
> >     ^.*sshd.*: reverse mapping checking getaddrinfo for .* failed -
> >
> > POSSIBLE
> > BREAK-IN ATTEMPT!$
> >     ^.* sshd.*: input_userauth_request: invalid user .*$
> >
> >
> > In theory, should be able to disable ChallengeResponseAuthentication and
> > PasswordAuthentication, then call it a day. Never actually tried, though.
> >
> > scap-security-guide mailing list -- [e-mail]
> > rahosted.org
> > To unsubscribe send an email to scap-security-guide-leave@list
> > s.fedorahosted.org
>
> scap-security-guide mailing list -- scap-security-guide@lists.
> fedorahosted.org
> To unsubscribe send an email to scap-security-guide-leave@
> lists.fedorahosted.org

[Non-DoD Source] Re: Disabling passwords in the cloud

[Brent Kimberley]

Hi James.
Why not use two keys to avoid using a static passphrase?

-----Original Message-----
From: McIntyre, James T. (Farragut Suitland, MD) [mailto:[e-mail]]
Sent: Monday, June 12, 2017 9:18 AM
To: [e-mail]
Subject: RE: [Non-DoD Source] Re: Disabling passwords in the cloud

Not sure I understand the complete question.

We do person by person as in loading up authorized_keys with the personal rsa.pub key such as:
cat .ssh/id_rsa.pub | ssh b@B 'cat >> .ssh/authorized_keys'.  Will ask you for password to complete the task.  Once done, should not ask for password until key changes.

The .ssh lives in the home folder of each user so that each user has a unique key loaded into their remote home folder.

This gives us passwordless ssh as well as positive identity of each individual to load them into the proper account.  Same goes for root so that root will ssh into root.

Recompiling, must not.  Positive ID, must have.

Am I way off base?

-----Original Message-----
From: Shawn Wells [mailto:[e-mail]]
Sent: Thursday, June 08, 2017 10:28 PM
To: [e-mail]
Subject: [Non-DoD Source] Re: Disabling passwords in the cloud

On 6/8/17 9:38 AM, Brent Kimberley wrote:

Does sshd need to be recompiled - in order to completely disable password authentication?

I would like to reduce the number of false positives in /var/log/secure

^.*sshd.*: Invalid user .* from .*$

^.*sshd.*: reverse mapping checking getaddrinfo for .* failed - POSSIBLE
BREAK-IN ATTEMPT!$

^.* sshd.*: input_userauth_request: invalid user .*$

In theory, should be able to disable ChallengeResponseAuthentication and
PasswordAuthentication, then call it a day. Never actually tried, though.
THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.

[0x2a]

Hi,

if you want to disable certain checks, I suggest looking at creating a 
tailoring file, scap-workbench can be used for this: 
https://www.open-scap.org/resources/documentation/customizing-scap-security-...

regards,
0x2a

On 2017-06-07 18:04, Fen Labalme wrote:
> If password access is disabled on a cloud-based server - both from
> (virtual) console and via SSH - can the set of password checks be
> disabled somehow?
>
> 10 checks: Set Password Quality Requirements with pam_pwquality
>
> 5 checks: Set Lockouts for Failed Password Attempts
>
> 3 checks: Set Password Hashing Algorithm
>
> Thanks,
> =Fen
> _______________________________________________
> scap-security-guide mailing list -- 
> [e-mail]
> To unsubscribe send an email to 
> [e-mail]