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 <smalder73(a)gmail.com> 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.
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)" <
jmcintyre(a)nmic.navy.mil> 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:shawn@redhat.com]
> Sent: Thursday, June 08, 2017 10:28 PM
> To: scap-security-guide(a)lists.fedorahosted.org
> 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(a)lists.fedo
>
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