Kommentare zu: The dilemma of ssh authorized_keys key files and its comments

Von: Matts

Matts — Thu, 22 Oct 2015 19:35:44 +0000

This is where configuration management (Chef, Puppet, Ansible, etc) comes in handy.
In Chef, you store the keys in encrypted databags and if you need to remove a key, you remove it from the databag and run the recipe that updates authorized_keys. Problem solved.

Von: chetpot

chetpot — Tue, 25 Mar 2014 18:09:53 +0000

I know its been quite some time since this post, but another solution is to use certificate authentication. This will allow you to have one trusted CA server with strict access that will generate user certificates. By doing this you have the option to give different users specified certificate lifespans via cert expiration, and any users that need to be removed before the cert expiration can have their cert placed on revokation list. For more info check out the CERTIFICATES section of ssh-keygen(1).

Von: Richard

Richard — Tue, 09 Nov 2010 11:09:56 +0000

this of course only works ok when you fix security like DESERTED mentions. This should be ok then i guess, or do I overlook some security-issue here?

Von: Richard

Richard — Tue, 09 Nov 2010 11:06:51 +0000

You can just add a comment to the end of the key like this so you dont forget who the key belongs to:

ssh-rsa AAA…Gi4w== someone@blah WRITECOMMENTHERE

@manpage authorized_keys:
Each line in these files contains the following fields: hostnames, bits, exponent, modulus, comment. The fields are separated by spaces.

Cheers

Von: 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.

Von: 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

Von: 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

Von: 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.

Von: 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.

Von: 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.