Mapping Authorized Keys Enrty to sshd process
 

When a user that has rsa public key set in ~/.ssh/authorized_keys file logs in via ssh an sshd process is started to handle the ssh session.

Periodically we audit the authorized keys and remove them from the system and authorized_keys file. This means the next log in attempt will fail, which is fine.

However we need to terminate current ssh sessions in progress that use the rsa key.

I have not been able to determine a way to map sshd processes with authorized_keys entries.

Any help would be appreciated.

What have you tried already?

I just tried to do this myself and unless there is some magic short cut that I don't see, this task isn't as simple as it may seem at first. It takes a little bit of manual log cross checking and few other commands but you may be able to tie them together. What I did and what I found are shown below:

I logged into my server via rsa key. Then on the server, I looked in /var/log/auth.log and saw the user name, the IP address, and the process ID, e.g. sshd[3878] with 3878 being the PID. Then using 'ps -aux' I found the following:
Indicating that this is the PS to kill. If this is enough information, your done. However, taking it a step further ...
Doing an nslookup of the IP address obtained in auth.log gave me the hostname of the machine I logged in from. Note, I use DDNS on my LAN with forward and reverse zones so I am able to resolve the host name and I am assuming you have a imilar mechanism to do this. Next, given the host name, it was trivial to find the line in authorized_keys. ** However, I have seen a lot of keys that do NOT have a hostname associated with them at the end of the line **. I am not sure how you would correlate them to a machine if you do not, unless you keep a list or log of the public keys and from which machine they are associated.

Mapping Authorized Keys Enrty to sshd process
 

Objective: given an rsa key (that exists in a users .ssh/authorized_keys) how can we determine which currently running ssh sessions belong to that user, so we can terminate the ssh sessions. I have looked at the following to try and find a mapping.

The sshd processes (lsof and environment)to see if any authorized rsa keys are stored. No such luck.

~.ssh/rc file. Here I can determine the shell pid and hence the parent being the sshd. However cannot get access to the rsa key being used.

Noticed /var/log/messages has the following finger print entry (so could hold mapping from rsa key to finger print via ssh-keygen) but no guarentee the messages file has not been aged hence not a good option to scan. So would need to set up monitor of messages file. Yuk.
sshd[18126]: Found matching RSA key: bd:35:de:0d:4e:bf:af:82:60:66:f2:f9:9f:2d:dc:4d

Mapping Authorized Keys Enrty to sshd process
 

Sorry Norway2 I missed your response.

If you start with an rsa/dsa key could you still track this to the sshd pid. Its this direction I need to map.

Note: In our environment many users can login from the same machine (they have their own PKI certificates of which teh rsa key is added to authorized_keys) so authorized-keys for user may have many keys with the same IP address. I agree the IP adresses(s) may also be missing.

Do you know the username? If so...

ps -u <username> | grep sshd

Will give you the pid of any open ssh connections to that user. I presume if your removing keys then the user is aware of this (as they'd have to start using a new key) and will understand when you kill their ssh session (If you wanted, you could 'write' something to their terminal to warn them first).

However I can't see any simple way of associating keys to users, other than the fact they are stored in the users authorized_keys folder...

And another question: why do you want to terminate these sessions? The ssh-keys are only used for authentication. You could scan the messages file though for entries of public key .

We have multiple users that log on to a single users X account. They are allowed to access the system provided their rsa key exists in the users X authorized_keys. They will not know they have been removed. We cannot kill all processes associated with user X since other valid users are still accessing the system.

We have a requirement that when a users certificate is revoked then any ssh sessions active by that user must be terminated.
So we can remove the rsa key from authorized keys (easily done)that stops the user logging in again, but user may be logged in already when certificate is revoked. Hence need to terminate these sessions

The only solution I came up with was marking each authorized_keys entry with a unique environment variable. This is passed to /etc/ssh/ssh_rc script that extracts teh pid of the shell and enters the pid plus the tag to a file. Hence when removing entries from authorized_keys you can use teh tag to look up the pid(s) and kill these sessions.

Great that you found a way.

BTW: I just recall a comment I read somewhere, that also someone else complained about a missing "revoke" feature for ssh-keys in SSH. I.e., you know a public keys is faulty, and you don't want to accept it at all (or in your case quit all active sessions with it). What I miss in addition is some option to see in the public keys on my server, whether their private counterparts are passphraseless and also don't allow them.

Thanks. Another way to see match the public key with the user is to look at the finger print.
Turn on sshd_config VERBOSE. You will see the fingerprint in /var/log/messages.
You can then have a script to read the rsa keys from ~user/.ssh/authorized_keys file and pass the information to the open ssl command. EG openssl -l -f <file with public key>.
This displays the fingerprint which you can match against the messages file.

Not sure if this helps, but to see the public keys I thought you could pass the a certificate.pen to openssl commands to extract the public key.

# generate public key part from private key
openssl rsa -in key.pem -pubout -out pubkey.pem

# displaying certificate fingerprint
openssl x509 -in key.pem -noout -fingerprint
SHA1 Fingerprint=7D:32:35:9F:1D:E7:7B:D0:AC:43:FA:85:56:44:1E:2E:F9:B5:40:AA