What authentication you use should be based on your operational needs, your threat model, etc.
I've been at shops where it was deemed that SSH via public key was sufficient for human accounts, but that for escalating to administrative access, two-factor was required. I've seen shops that used local password only, and some stuff between. The difference each time was the acceptable risk factor, and that's a decision that is typically made much higher up the management tree, especially when Sarbanes-Oxley is involved. Other factors that could go into the decision include what level of host security is involved, network security, level of access of the accounts, etc. For example, if you require two-factor to go from a regular account to any kind of administrative access, then maybe regular public key is sufficient for that environment. For scripted logins, I often recommend public key with command="..." strings in the keys to restrict each key to a single task. I've done that successfully at more than one shop, even fairly paranoid ones. For break-glass situations, I've seen several options, including the root account on the console with passwords that are changed every time they are used, accounts that trigger log alerts every time they are used, etc. Your emergency local account likely needs to work even if the network is broken. On 2014 Sep 16, at 18:06 , Ray Van Dolson <rvandol...@esri.com> wrote: > Looking at revisiting our authentication model and curious what sort of > baselines you all use. Am mostly focused on Linux, but concepts could > apply to Windows as well. > > AD is "key" in our environment, so envision Kerberos playing a big role > in this. My preference: > > - Administrators need some sort of two-factor authentication to obtain > a valid Kerberos ticket (when they log in to Windows for example). > - Linux boxen are set up to accept remote logins only via Kerberos > tickets. No password auth allowed (Kerberized PuTTY works fine for > this). > - Emergency local accounts would need to be in place, but perhaps would > tie into a two-factor PAM module (e.g. Google Authenticator). > > Perhaps this isn't "enough" and I should look to have two-factor even > at the SSH level? I do want to be able to potentially accommodate > scripted logins via SSH keys in certain situations. > > How are some of you doing this currently? > > Thanks, > Ray > _______________________________________________ > Tech mailing list > Tech@lists.lopsa.org > https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech > This list provided by the League of Professional System Administrators > http://lopsa.org/ _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
