7

User A has two SSH private keys, and over time has used this public key on a number of servers He lost one of them, and has created a new pair.

How does User A inform me (the sysadmin), that he has lost his key, and how do I manage all the servers to which he had access (I do not have a list, of all servers that User A has access to). In other words, how do I recall the public key associated with this private key.

In LDAP based Authentication, all servers would communicate with a single server repository for authentication, and If I remove acess or modify the password on the server, all systems that use this LDAP for authentication are secured, when User A loses his password.

womble
  • 95,029
  • 29
  • 173
  • 228
Shree Mandadi
  • 181
  • 1
  • 6
  • 3
    http://security.stackexchange.com/questions/10963/whats-the-common-pragmatic-strategy-for-managing-key-pairs – Zoredache Mar 24 '12 at 15:32
  • If you don't know which machines may have the key, you cannot know all the machines you have to clean. – womble Mar 24 '12 at 20:01

5 Answers5

4

What version of sshd are you using? OpenSSH 5.4 apparently has a key revocation option:

* Add the ability to revoke keys in sshd(8) and ssh(1). User keys may
be revoked using a new sshd_config(5) option "RevokedKeys". Host keys 
are revoked through known_hosts (details in the sshd(8) man page).   
Revoked keys cannot be used for user or host authentication and will  
trigger a warning if used.

If you're using an earlier version, you probably have to run through all possible authorized_keys files on all your servers to look for and remove the suspect public key. This would include any account User-A could ssh into, including root. This assumes you are not using centralized authoried_key management.

cjc
  • 24,533
  • 2
  • 49
  • 69
  • To clarify the Question more, If that User-A's private key is compromised, How do you secure all the Servers and User accounts which had the associated Public key. I have a feeling, that the RevokedKeys, and Known_hosts is a Client side option. – Shree Mandadi Mar 24 '12 at 14:43
  • +1 for Centralized Authorized_key solution, I am searching for a better way to implement that – Shree Mandadi Mar 24 '12 at 14:46
  • RevokedKeys can be server-side (and it can be used on the client side to disallow connections to known bad servers). But that's OpenSSH 5.4, which doesn't ship with, say, RHEL6. I recall there being something in LDAP user account configuration where you store the authorized_keys for a give user, but you may not have that configured. Oh, looks like you have to patch the ssh server: http://code.google.com/p/openssh-lpk/wiki/Main – cjc Mar 24 '12 at 14:50
  • As an aside, we've been controlling the authorized_keys files from our configuration management system, chef. – cjc Mar 24 '12 at 14:55
  • Thanks cjc... I think this is the way to go... Wean off all the servers which hace individually controlled authorized files, and resort to the CMS systems... – Shree Mandadi Mar 25 '12 at 14:33
1

One possible short-term fix to this situation is to use some config management tool (ansible may be a good bet here).

You could notably use the authorized_key module (https://docs.ansible.com/ansible/authorized_key_module.html) to remove one (or more) specific public key fingerprint from a given user's authorized_key file.

An example is lacking for your needs, but something like this could work:

- name: Set authorized key took from url
  authorized_key:
    user: charlie
    state: absent
    key: https://github.com/charlie.keys

You can also (in ansible at least) run a command to create a list of all users on a system, by querying /etc/passwd.

You could also just create a fresh whitelist of keys and remove everything else, but that may not be practical in your situation.

The ansible docs give a rough example of how that could work:

- name: Set authorized key, removing all the authorized key already set
  authorized_key:
    user: root
    key: '{{ item }}'
    state: present
    exclusive: True
  with_file:
    - public_keys/doe-jane

In the long run, you may want to consider having jumphosts - I've found teleport to be rather good.

iwaseatenbyagrue
  • 3,588
  • 12
  • 22
0

In both OpenSSH and Putty you can regenrate the public key from the private key but not the other way round.

Use ssh-keygen -y -f filename

In PuttyGen, import the key and it will show you the public key.

TheVyom
  • 131
  • 1
  • That has nothing to do at all with the OPs question. – Sven Mar 24 '12 at 14:18
  • 1
    Lost as in lost control of the key and believes that somebody else may have a copy of it, or it is simply gone into the ether. Either way, it should not remain installed. This doesn't help that. – Jeff Ferland Mar 24 '12 at 16:57
  • @SvenW: After regenerating the public key, you can just run a script to search all machines lists of authorized keys for that public key. (Essentially a `grep` on the various `ssh` directories for a sequence of, say, 12 characters taken from it.) The question asks, "In other words, How do I recall, the public key associated with this Private key." and the first step in doing that is to figure out what that public key *is* so you can search for it. – David Schwartz Mar 24 '12 at 19:02
0

If this is a user key (as it appears it is), then it will be located in the authorized_keys file for userids that the user had access to. You will need to search the .ssh subdirectory of the home directories. (If you have automounted home directories, you only need to search the directory on one server; otherwise you need to search all servers they might have had access to.)

The problem will be finding the first copy of the old key. The user's home directory on commonly accessed systems will be a good place to start. Once you have the key you can grep for it on other systems and userids. Searching for the key value rather than the comment will be more likely to find all the keys.

BillThor
  • 27,354
  • 3
  • 35
  • 69
0

how do I recall the public key associated with this private key.

While revoking SSH keys is certainly not a bad idea, the better (or more scaleable) solution is to implement MFA (multi-factor authenticator, aka Two Factor Authentication). This has the effect of devaluing the key, because the user cannot login unless they satisfy (1) additional factor.

A couple open source solutions exist like Google Authenticator and Oath. Then a hybrid open source / commercial solution like Duo. With Duo, you can even geo fence logins and push notifications.

For a 100% functioning example implementation, checkout this bastion implemented as a Docker container: https://github.com/cloudposse/bastion