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. And maintaining those keys as the root user to lock these credentials may not be work most admins want to take on.> Personally I'd use the AuthorizedKeysCommand for this setup as it would > provide for a better programmatic way of managing keys. > > - BenThen 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.
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
On Sat, Jul 9, 2016 at 12:00 PM, Ben Lindstrom <mouring at eviladmin.org> wrote:> 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.Ben, I'm not trying to say it's not wise and sensible to go write a non-standard, unsupported, and potentially root access destabilizing non-standard workaround to shove user keys in a separate, locked, down, root owned repository managed by someone other than the individual user. Actually, come to to think of it, I am saying it's an idea that many admins do reject and should reject.. It's easy to do at first glance. But taking manual control of sshd_config can be fragile, and can breadk restarts of sshd. I don't recommend it for the faint-hearted and those without test environments with local console access.> 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.Yes, you can hand modify or plug in a wrapper to modify sshd_config and try to keep it consistent with OpenSSH release changes. It's sometimes proven a finicky task.> 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.Me, too. I haven't noticed any good ones. Even the chef "openssh" cookbook doesn't have good default options for the different OpenSSH variants, and tends to screw up SFTP settings if you use the cookbook.> 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?I agree with this argument.> 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.This is the kind of thing I really, really don't recommend for the faint of heart or the wise of maintenance. This sort of trick quickly leds to the infamous XKCD "automation" chart, shown at https://xkcd.com/1319/ .> 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. > > > BenPeople *do* steal private SSH keys and other keys off computers, both laptops and servers, all the time. I've certainly done it as a proof of concept. The last time, it was a "Linux architect" who erected an SSH tunnel between servers at work and his home machine, with unencrypted SSH private keys stored in his home direcotry on ech end, and published on NFS shares. I was pretty shocked, but that kind of thing is not that unusual. Keys get stolen by this kind of silliness *all the time*.