Ask HN: Avoid Manipulation of .ssh/Authorized_keys | Hacker News Reader

Ask HN: Avoid Manipulation of .ssh/Authorized_keys

8 pointsmpaepper11 comments

Recently I asked the question how you handle ssh keys of your teams: https://news.ycombinator.com/item?id=24157180

I received many good ideas of how to do this, in particular to use signed certificates instead of public-private keys.

One big question remains for me: how do you avoid that users who get access via a certificate to a server, simply add a public key to .ssh/authorized_keys and then can access the server also without a certificate from then on?

If a user has root access via the certificate on a server, they could always manipulate that, right?

View on HN

“If a user has root access via the certificate on a server”

1. If at all possible, avoid giving anybody (even yourself) root access.

2. You can move the authorized keys files to a different location. See https://serverfault.com/questions/313465/is-a-central-locati.... That’s not hacker-proof against users having root access, but will prevent users of good will from doing the wrong thing.

3. Depending on OS/file system, you may be able to make .ssh/authorized_keys immutable, even for root, on the server. For example, FreeBSD has the “system immutable” flag. Files with that flag set can only be modified after booting in single-user mode (https://www.techrepublic.com/blog/it-security/freebsd-file-f...)

Also, AuthorizedKeysFile may also be set to none to skip checking for user keys in files altogether!

Or choose to disable keys based authentication if using certs.

Or customize keys so that they get served from a db or some such, the only requirement for this is to write a script or binary.

I linked to all of this in another reply and it was downvoted for some reason. Odd.

Are your users evil, or just careless?

If they're evil, then after giving them root access, you can never take it back again. They can do anything to persist their access, and you will never forsee what they could do, so you shouldn't try.

If your users are careless, a simple note at the top of authorized_keys saying "Don't add anything to this file plz without asking the security team" should be sufficient.

Thanks for your answer. Of course, in general, the users are not evil. However, I am thinking about the security concerns when someone is leaving the company. Maybe for some reason they turn evil and decide to place their key to still have access after they left.

If your main concern is just the keys file then maybe simply setting up a cron that would „echo "" > .ssh/authorized_keys” would do the trick. But like said - it's otheriwse an endless cat and mouse game. For examples you can look at King of the Hill CTF games on YouTube

This is a poor solution because I think most people just use ssh-copy-id and don’t actually look at the file. It ships with openssh. For the standard way that I copy my ssh keys to a new host, I’d never see that warning.

If you use openssh as your ssh server you may want to look at the AuthorizedKeysFile option

https://man.openbsd.org/sshd_config#AuthorizedKeysFile

Other useful options are AuthenticationMethods and AuthorizedKeysCommands.

Not sure why this is downvoted. Anyone care to explain ?

This isn't a good cross-platform option but on AWS I just use systems manager and don't actually allow direct SSH login. There are a few things you can't do like using SCP but in my world this is a feature, not a bug. It means that to send stuff in and out of the environment requires a S3 bucket which we can analyse.

I'm sure that you could either build your own using xterm.js [0] or by using one of the many projects that implements it. I'm not sure if systems manager uses this project but it certainly looks very similar.

[0] https://xtermjs.org/

If you want a really good solution, consider using an SSH CA.

See e.g. this thread: https://news.ycombinator.com/item?id=24157781

I am, but my question is how to control for people still adding keys in addition to having logged in with a certificate.

Reply on news.ycombinator.com