SSH multi factor authentication

[Ben Lindstrom]

Nico Kadel-Garcia wrote:
> On Sat, Jul 9, 2016 at 10:30 AM, Ben Lindstrom<mouring at eviladmin.org>  wrote:
>
>> You'd do this by either moving the authorized_keys to another a root owned
>> location using "AuthorizedKeysFile" (e.g. AuthorizedKeysFile
>> /etc/ssh/keys/authorized_keys.%u).  Or you use "AuthorizedKeysCommand" and
>> put the keys into a "database" to reference them via a simple root-owned
>> program.
>
> Yeah, that's doable. It's very rare, though. Many people prefer not to
> touch the default sshd_config if they can avoid it.

Many of us prefer not to mess with PAM, Systemd, apache, and other 
configuration files, and would love
to just install the system and use it without having to lift a finger to 
ever configure it.  But sadly, life doesn't
permit us all that luxury.  So it is a poor argument.  Besides, anyone 
maintaining a decent amount of
machines not using puppet, salt, ansible, or <insert new shiny 
management tool here> is doing themselves
and their company a disservice.

> And maintaining
> those keys as the root user to lock these credentials may not be work
> most admins want to take on.
My response was to your comment "And unless you can enforce use of a 
designated public key on
the server side, for example by breaking ownership checks and making the 
file and directories owned by
root with user groupo access, or by auto-replacing 
$HOME/.ssh/authorized_keys, well, the user can
replace the key at whim with their own insecure key."

So if the admin doesn't care about the restrictions you stated.  Then they don't
have to change the sshd_config.  However, if they do then they are stepping out
from the defaults.  Just like how those that want chroot sftp enabled need to
step out from the defaults.  Just like those that need root access via authorizes
keys need to step out from the defaults.


>> Personally I'd use the AuthorizedKeysCommand for this setup as it would
>> provide for a better programmatic way of managing keys.
>>
>> - Ben
>
> Then you have to write, or activate and maintain, yet another tool.
> Feasible, but not many folks consider it worth the work. I've *done*
> things like that, way back with some "one-time password" tools I used
> back in the remote 9600 baud modem era.
We've all written horrible stuff to satisfy business requirements.  Our 
universe, as admins,
is  scattered with many "yet another tool"  or "yet another set of 
packages" to maintain for
security or for our users to do their jobs.

So if the above is a requirement for your fictional admin then a tool 
will need to be written.
And OpenSSH has already provided the means today by which it can easily 
integrate in.
However, I would hope that it is a well written tool, and it can be 
shared with the community
so it doesn't become a one-off burden.



Anyways, the question still boils down to is Google Authenticator + 
Authorized Keys (with or
without password) 2FA.  And honestly I'm going to have to state it is 
2FA in both cases.

The argument is simple.  If I use a password management tool (that 
requires me to unlock
it with a different password) that auto fills in my Blizzard Battle.net 
login/password then I use
the Blizzard's authenticator and type in the random code do I have 2FA?

Clearly, I've not typed my password.  I may NOT EVEN KNOW my password 
(which is true
in this case as it is a nasty auto-generated beast =).  So it is 
basically the same as the
2048bit RSA authorized key I use in SSH.   I use a password to decrypt 
access,
but I only really possess both as I don't have them memorized.

To complete the comparison I can write myself a password manager that 
doesn't require
me to unlock (e.g. most "remember my password" crap in browsers).   So 
the fact it is if
my password is protected or not doesn't change my knowledge (or lack of) 
of the
password.

The same goes for RSA keys.  Someone can steal my password manager, hack 
it, and
gain access.  Just like they could steal steal my RSA keys off my laptop.


Ben