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) <[email protected]> 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:[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]> > > > > > _______________________________________________ > 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]
