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:[email protected]] 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)" <[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] <mailto:[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] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected]
