Comments on: The dilemma of ssh authorized_keys key files and its comments

By: Kiel

Kiel — Tue, 21 Jul 2009 23:17:49 +0000

You should utilize the fingerprint of the SSH key. The fingerprint IS the “checksum” you’re talking about. Changing the comment does NOT change the fingerprint.

Check the fingerprint of the keys and only remove keys with the matching fingerprint. Checking the fingerprint of ssh keys should be common practice anyway – since it is the best way to verify the owner of a key over the phone.

This is very basic public key verification practice.

By: Deserted

Deserted — Wed, 17 Dec 2008 23:00:36 +0000

actually just found this post, point three takes my process one step further by moving the file completely out of the users domain

http://it.toolbox.com/blogs/unix-sysadmin/playing-with-openssh-public-keys-28377

By: Deserted

Deserted — Wed, 17 Dec 2008 22:57:03 +0000

I personally find that a combination of making authorized_keys read-only for all but root, and using properly configured sudo policies to be a good process here. It won’t catch issues 100% of the time, but it does give a reasonable level of security without wasting too much time on various methods of tracking – you could take this a step further and add either a COW or Versioning system to manage the updates to authorized_keys, that goes beyond my requirements though

As to syberghost’s comment, I agree that root is often the simplest way to manage a large deployment, however I don’t agree with flippant use of sudo or giving root out to anything but trusted senior admins.

Quite apart from potentially intentional harm, a simple slip on the commandline by an inexperienced user when running with open sudo privs/as root can do a LOT of harm

By: syberghost

syberghost — Mon, 14 Apr 2008 14:43:21 +0000

I love how people who administrate little environments glibly say everybody should use sudo 100% of the time.

Now try doing adhoc system administration tasks on 2000 servers under time constraints and tell me how “log on as yourself and use sudo” scales for you.

This problem doesn’t just exist for “root”, either. You may have other less-privileged accounts for which such remote administration is necessary, not to mention file transfer capabilities which may by necessity be exposed outside the firewall.

By: Level 1

Level 1 — Thu, 03 Jan 2008 20:39:19 +0000

After you delete the key, Keep a copy the key under your own personal home folder. If you delete the wrong key, you have a backup.

By: ccm

ccm — Thu, 03 Jan 2008 08:02:58 +0000

Thanks for your comments, guys. Let me add that I know, of course, there is no possibility to enforce a trusted situation when other people have root and even when they don’t – if they are smart enough. The point is how difficult it is to cause trouble, how techie you have to be to get an idea of how to change things for your own advantage. Theoretically, I agree, everybody can do everything, but as we know, every additional barrier is a good choice.

So what I’d really like to see is something in the ssh daemon that matches some of your suggestions. Registering ssh keys, signing them, and stuff. Of course there are alternatives like ldap but when you are an agency caring for dozens of live servers distributed about a couple of providers you cannot centralize and have to deal with a lot of isolated machines.

I think what comes quite close is the suggestion of Jim K – a packet management driven delivery of ssh keys. I also thought about a check script that greps all home dirs from a /etc/passwd, adds the authorized_keys path to it and checks if these files exist and what they contain – kind of current access summary. So in the end it is about writing your own scripts. As I don’t seem to be isolated in my task I hope there will come up some official stuff, soon that prevents us from inventing the wheel again and again.

Thank you, guys.

By: Jim K

Jim K — Thu, 03 Jan 2008 04:03:38 +0000

We manage key files via a package. We create a new install file (rpm or dpkg) with the updated key files. We place this in a repository and the patching process applies the changes to the key files. This also allows you to audit compliance and keep track of version history. You can use cvs/svn to track the changes to the key files…

By: Krzysztof Wyszynski

Krzysztof Wyszynski — Wed, 02 Jan 2008 22:52:25 +0000

Why don’t you manage SSH keys using some database backend? Every user can upload his key using some PHP frontend. The key is therefore stored in DB and authorized_keys files are refreshed daily using CRON job. You, as an administrator, have privileges to manage every key assigned to any person. Users can only upload/change their own keys.

By: Jon

Jon — Wed, 02 Jan 2008 21:52:33 +0000

If they had root and you don’t trust them, you’re basically screwed. There are a lot of schemes folks could come up with to ensure ssh authorized_keys are fair (require everyone to send their public key to you, store them on a secure machine, periodically run a script to check for non-matching keys in each user’s ~/.ssh, etc.), but that isn’t sufficient. For example, the attacker could have installed a kernel module that deceives you or circumvents any block you place against them.

When your admins leave, you do your best to close the doors behind them but you must simply accept that they might be smarter than you and still have a way in. Unless you’re willing to nuke all affected servers down to the ground and re-build them, you’re just kidding yourself.

By: JAB van Ree

JAB van Ree — Wed, 02 Jan 2008 21:43:00 +0000

The outside world should not be able to access said machine(s) directly over the internet anyway, besides default ports like 80, 443, 53, 25 and maybe 993/995?! Only allow certain machines to access the server(s) on other ports, easy to set up using IP tables.