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 <[email protected]> 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)" < > [email protected]> 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:[email protected]] >> Sent: Thursday, June 08, 2017 10:28 PM >> To: [email protected] >> 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 -- [email protected] >> 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 > >
_______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected]
